Sophos Protected Browser: problemen met toegang en aanmelden oplossen

Dit runbook helpt bij het afbakenen van toegangsproblemen met Protected Browser en agentloze ZTNA-RDP-/SSH-resources. Open in Sophos Central Meine Produkte > Protected Browser en begin bij het zichtbare symptoom. Los alleen de oorzaak op die tijdens de controles is bevestigd. Brede wijzigingen in DNS, de gebruikersdirectory of ZTNA bemoeilijken de diagnose.

Snelle aanpak: Als het toevoegen of bewerken van een resource al mislukt, controleer dan de e-mailadressen van alle leden van de gebruikte gebruikersgroep. Als een bestaande resource zonder concrete foutmelding onbereikbaar is, test dan eerst de ZTNA-gebruikersportal en vervolgens de DNS-resolutie van de FQDN van de ZTNA-gateway. Vergelijk bij ‘Netzwerk nicht erreichbar’ of ‘Verbindung konnte nicht hergestellt werden’ rechtstreeks de in ZTNA geconfigureerde identiteitsprovider met de aanmeldmethode van de Protected Browser-sessie. Als aanmelden bij Protected Browser mislukt, controleer dan de toegang tot Self Service Portal en of het e-mailadres uniek is voor alle tenants. Behandel de melding ‘Hostschlüsselüberprüfung fehlgeschlagen’ afzonderlijk.

Vereisten en veilige werklimieten

Voor deze controles zijn een reeds ingerichte Protected Browser- en ZTNA-omgeving en een duidelijk afgebakende getroffen gebruiker vereist. Uit ontbrekende menu’s of machtigingen kan geen specifieke oorzaak op het gebied van licenties of rollen worden afgeleid. Draag de controle in dat geval over aan de verantwoordelijke Sophos Central-beheerder.

Voor de gebruikerscontrole in Sophos Central is toegang tot Meine Umgebung > Benutzer und Gruppen > Benutzer vereist. Voor de bereikbaarheidstest moeten de daadwerkelijk geconfigureerde FQDN van de ZTNA-gateway en het gatewaytype bekend zijn: Sophos Cloud Gateway of lokale gateway. Vervang in de opdracht de tijdelijke aanduiding door de FQDN van de ZTNA-gateway, niet door de naam van een RDP-/SSH-doelresource.

Wijzig tijdens de diagnose telkens slechts één waarde en test daarna opnieuw met dezelfde gebruiker en hetzelfde apparaat. Als een vereiste onduidelijk is of toegang tot gebruikersbeheer ontbreekt, stop dan de diagnose en draag de case over aan de verantwoordelijke beheerder van Sophos Central, de directoryservice of ZTNA.

Problemen oplossen per symptoom

Toevoegen of bewerken van een agentloze RDP-/SSH-resource mislukt

Waarschijnlijke oorzaak: Minstens één lid van de gebruikte gebruikersgroep heeft geen geldig e-mailadres. Dit kan zowel een ZTNA-resource als een RDP-/SSH-resource in een Protected Browser-toepassingsgroep treffen.

Controle:

1. Open Meine Umgebung > Benutzer und Gruppen > Benutzer.
2. Controleer in de kolom E-Mail alle gebruikers van de groep die aan de resource of toepassingsgroep moet worden toegewezen.

Verwachte waarneming: Elke gebruiker in de getroffen groep heeft een geldig e-mailadres. Een lege vermelding bevestigt de fouttoestand.

Veilige maatregel: Voeg het ontbrekende adres toe in de leidende directoryservice. Voeg het alleen rechtstreeks in Sophos Central toe voor gebruikers die handmatig in Sophos Central zijn aangemaakt. Wijzig bestaande adressen niet op basis van vermoedens.

Opnieuw valideren: Probeer dezelfde resource opnieuw toe te voegen of te bewerken zonder de groep te wijzigen. Als dit ondanks een volledig ingevulde kolom E-Mail nog steeds mislukt, is deze oorzaak niet bevestigd. Wijzig geen verdere identiteitsgegevens, maar noteer het resourcetype, de groep, het tijdstip en de zichtbare melding en escaleer de case.

Agentloze RDP-/SSH-resource is niet bereikbaar via Protected Browser

Waarschijnlijke oorzaak: Het apparaat kan de FQDN van de ZTNA-gateway niet correct omzetten. Het eerste scheidingspunt is echter de ZTNA-gebruikersportal: als die al niet bereikbaar is via Protected Browser, bevindt het probleem zich vóór de afzonderlijke RDP-/SSH-resource.

Controle:

1. Probeer op hetzelfde apparaat en als dezelfde gebruiker de ZTNA-gebruikersportal via Protected Browser te openen.
2. Voer op het getroffen apparaat een DNS-query uit als de portal niet bereikbaar is:

nslookup <ZTNA-Gateway-FQDN>

Vervang <ZTNA-Gateway-FQDN> door de daadwerkelijk geconfigureerde gatewaynaam. nslookup is een alleen-lezen test en wijzigt geen configuratie.

Verwachte waarneming: Bij een Sophos Cloud Gateway wordt de gatewaynaam omgezet naar het adres van de gatewayproxy. Bij een lokale gateway wordt deze omgezet naar het adres van de ZTNA-gateway dat op de eigen DNS-server is geconfigureerd. Vergelijk het antwoord met het daadwerkelijk geconfigureerde doel voor het betreffende gatewaymodel. Als de omzetting mislukt, moet de DNS-configuratie worden gecontroleerd. Een afwijkend antwoord bevestigt pas een fout als het niet overeenkomt met het geconfigureerde doel. Als het beoogde doel onbekend is, wijzig DNS dan niet maar draag de controle over aan de DNS-/ZTNA-verantwoordelijke.

Veilige maatregel: Corrigeer de DNS-configuratie volgens de daarvoor bestemde DNS-/ZTNA-procedure. De juiste zone en het juiste doel zijn afhankelijk van het gatewaymodel; voer hier daarom geen algemene DNS-wijzigingen uit.

Opnieuw valideren: Voer dezelfde nslookup-query opnieuw uit nadat de DNS-/ZTNA-verantwoordelijke heeft bevestigd dat een correctie volgens de daarvoor bestemde procedure is uitgevoerd. Open vervolgens de ZTNA-gebruikersportal en test pas daarna de oorspronkelijke RDP-/SSH-resource. Als het DNS-antwoord aan de verwachting voldoet en de portal bereikbaar is, maar de resource nog steeds niet, documenteer dan deze twee geslaagde controles en escaleer het resourcespecifieke ZTNA-onderzoek.

‘Netzwerk nicht erreichbar’ of ‘Verbindung konnte nicht hergestellt werden’

Waarschijnlijke oorzaak: ZTNA gebruikt een identiteitsprovider zoals Okta of Entra ID, maar de gebruiker is bij Protected Browser aangemeld met de Sophos ID of als lokale gebruiker. Bij toegang tot een SSH- of RDP-toepassing achter de ZTNA-gateway kunnen dan de genoemde meldingen verschijnen.

Controle: Bepaal welke identiteitsprovider in ZTNA is geconfigureerd en vergelijk deze met de aanmeldmethode van de huidige Protected Browser-sessie.

Verwachte waarneming: De oorzaak is bevestigd als ZTNA een identiteitsprovider gebruikt, maar de Protected Browser-sessie niet via deze provider is geverifieerd.

Veilige maatregel: Beëindig de getroffen sessie en meld de gebruiker bij Protected Browser aan via de identiteitsprovider die in ZTNA is geconfigureerd. Wijzig de ZTNA-identiteitsprovider niet om één aanmeldfout te omzeilen.

Opnieuw valideren: Open in de nieuw geverifieerde sessie dezelfde SSH- of RDP-toepassing. Als de melding ondanks overeenkomende aanmeldmethoden blijft bestaan, noteer dan de identiteitsprovider, gebruiker, resource en het tijdstip en draag de case over aan de ZTNA-verantwoordelijke.

Gebruiker kan zich niet aanmelden bij Protected Browser

Controleer hier twee onafhankelijke oorzaken. Los ze niet tegelijkertijd op, zodat duidelijk blijft welke oorzaak van toepassing was.

Toegang tot Self Service Portal ontbreekt

Controle: Open Meine Umgebung > Benutzer und Gruppen > Benutzer en controleer bij de getroffen gebruiker de kolom Rolle. U kunt ook de gebruikersnaam selecteren en de tekst onder de profielfoto controleren.

Verwachte waarneming: Als toegang tot Sophos Central Self Service Portal beschikbaar is, wordt SelfService weergegeven in de kolom Rolle of onder de profielfoto.

Veilige maatregel: Als SelfService ontbreekt, draag dan het toewijzen van toegang tot Self Service Portal over aan de verantwoordelijke Sophos Central-beheerder.

Opnieuw valideren: Bevestig eerst dat SelfService wordt weergegeven en herhaal daarna de aanmelding met precies deze gebruiker.

E-mailadres is aan meerdere Sophos Central-accounts gekoppeld

Controle: Stel vast of het e-mailadres van de getroffen gebruiker aan meerdere Sophos Central-accounts is toegewezen.

Verwachte waarneming: Het adres mag niet aan meerdere Sophos Central-accounts zijn gekoppeld.

Veilige maatregel: Laat de verantwoordelijke tenant- of identiteitsbeheerder de toewijzing corrigeren. Verwijder zonder bevestigde doeltenant geen gebruiker en wijzig geen productieadres.

Opnieuw valideren: Herhaal de aanmelding bij Protected Browser nadat de unieke toewijzing is bevestigd. Als die nog steeds mislukt, documenteer dan SelfService, de e-mailtoewijzing, het tijdstip en de zichtbare melding voor escalatie.

SSH meldt ‘Hostschlüsselüberprüfung fehlgeschlagen’

Waarschijnlijke oorzaak: De sleutel die in de SSH-client is opgeslagen, komt niet meer overeen met de sleutel van de host. Dit kan gebeuren na een legitieme wijziging, zoals een herinstallatie, maar dezelfde melding kan ook op een onverwachte wijziging wijzen.

Controle: Vraag de verwachte vingerafdruk van de hostsleutel via een onafhankelijk, vertrouwd kanaal op bij de systeemverantwoordelijke en vergelijk deze met de vingerafdruk van de juiste doelhost. Vertrouw daarbij niet op de mislukte SSH-verbinding of op de nieuwe sleutel die daarin wordt aangeboden. Als de verwachte vingerafdruk niet onafhankelijk is bevestigd, niet overeenkomt of de wijziging niet kan worden verklaard, stop dan hier en escaleer de gebeurtenis als beveiligingsincident.

Verwachte waarneming: De doelhost, legitieme sleutelwijziging en verwachte vingerafdruk zijn onafhankelijk en ondubbelzinnig bevestigd.

Veilige maatregel: Bepaal vóór het verwijderen welke vermeldingen door de aangeboden functie van de gebruikte SSH-client worden verwijderd. Sophos noemt Bekannte Hosts löschen als voorbeeld, maar bevestigt niet dat deze functie alleen de getroffen host verwijdert. Voer geen reset uit en escaleer als het verwijderingsbereik onbekend is of de verwachte vingerafdruk niet onafhankelijk kan worden bevestigd. Verwijder de opgeslagen sleutel pas wanneer het bereik duidelijk en de vingerafdruk bevestigd is. Accepteer bij de volgende verbinding alleen de sleutel waarvan de vingerafdruk overeenkomt met de onafhankelijke bevestiging.

Opnieuw valideren: Breng de verbinding opnieuw tot stand. De hostsleutelcontrole moet met de nieuw geaccepteerde sleutel slagen. Als de melding opnieuw verschijnt of de sleutel nogmaals onverwacht verandert, verwijder dan niet herhaaldelijk vermeldingen, maar escaleer met de hostnaam, het tijdstip en de SSH-client.

Terugkeer, escalatie en operationele grenzen

Voor deze problemen bestaat geen universele rollback. De veilige weg terug is om geen brede wijzigingen uit te voeren en de beginwaarde van een doelgericht gewijzigde gebruikerstoewijzing vast te leggen. Stop bij het betreffende escalatiepunt als de maatregel geen resultaat oplevert. Het verwijderen van bekende SSH-hostsleutels is geen algemene reset en is alleen verantwoord bij een onafhankelijk bevestigde vingerafdruk en een bekend verwijderingsbereik.

Leg voor een interne escalatie of escalatie naar support ten minste het symptoom, de gebruiker, het apparaat, het resourcetype, het gatewaymodel, de FQDN van de ZTNA-gateway, het tijdstip en het resultaat van de direct bijbehorende controle vast. Aanmeldgegevens, privésleutels en tokens horen niet in het ticket.

Herhaal alleen de controle die hoort bij de daadwerkelijk uitgevoerde maatregel of de bevestigde overdracht: de resource opnieuw toevoegen of bewerken na een e-mailcorrectie; aanmelden na bevestigde toegang tot Self Service Portal of een unieke accounttoewijzing; de resource openen na aanmelden via de geconfigureerde identiteitsprovider; of de SSH-verbinding tot stand brengen na de gecontroleerde reset van de hostsleutel. Test na overdracht aan de DNS-/ZTNA-verantwoordelijke nslookup, de gebruikersportal en de oorspronkelijke resource pas opnieuw wanneer deze een correctie volgens de eigen procedure heeft bevestigd.

Afbakening ten opzichte van verwante handleidingen

Dit runbook behandelt uitsluitend de hier beschreven symptomen van Protected Browser. De configuratie van Protected Browser of de extensie en algemene DNS- en ZTNA-configuratie horen in de betreffende installatiehandleidingen. Als een dergelijke configuratie nodig is, draag de case dan over aan de verantwoordelijke beheerder.