Sophos Protected Browser: Troubleshooting für Zugriff und Anmeldung
Dieses Runbook hilft bei der Eingrenzung von Zugriffsproblemen mit Protected Browser und agentenlosen ZTNA-RDP-/SSH-Ressourcen. Man öffnet in Sophos Central Meine Produkte > Protected Browser und beginnt beim sichtbaren Symptom. Behoben wird nur die dabei bestätigte Ursache. Breite Änderungen an DNS, Benutzerverzeichnis oder ZTNA erschweren die Diagnose.
Schnellweg: Schlägt bereits das Hinzufügen oder Bearbeiten einer Ressource fehl, prüft man die E-Mail-Adressen aller Mitglieder der verwendeten Benutzergruppe. Ist eine vorhandene Ressource ohne konkrete Fehlermeldung nicht erreichbar, testet man zuerst das ZTNA-Benutzerportal und danach die DNS-Auflösung des ZTNA-Gateway-FQDN. Bei „Netzwerk nicht erreichbar“ oder „Verbindung konnte nicht hergestellt werden“ vergleicht man direkt den in ZTNA konfigurierten Identity Provider mit der Anmeldemethode der Protected-Browser-Sitzung. Schlägt die Protected-Browser-Anmeldung fehl, prüft man den Self-Service-Portal-Zugriff und eine tenantübergreifend eindeutige E-Mail-Adresse. Die Meldung „Hostschlüsselüberprüfung fehlgeschlagen“ wird separat behandelt.
Voraussetzungen und sichere Arbeitsgrenze
Für die beschriebenen Prüfungen sind eine bereits eingerichtete Protected-Browser- und ZTNA-Umgebung sowie ein klar abgegrenzter betroffener Benutzer erforderlich. Fehlen Menüs oder Berechtigungen, lässt sich daraus keine bestimmte Lizenz- oder Rollenursache ableiten. In diesem Fall übergibt man die Prüfung an den zuständigen Sophos-Central-Administrator.
Für die Benutzerprüfung benötigt man in Sophos Central Zugriff auf Meine Umgebung > Benutzer und Gruppen > Benutzer. Für den Erreichbarkeitstest müssen der tatsächlich konfigurierte ZTNA-Gateway-FQDN und die Gateway-Art bekannt sein: Sophos Cloud Gateway oder lokales Gateway. Im Befehl ersetzt man den Platzhalter durch den FQDN des ZTNA-Gateways, nicht durch den Namen einer RDP-/SSH-Zielressource.
Während der Diagnose ändert man jeweils nur einen Wert und testet danach erneut mit demselben Benutzer und demselben Gerät. Ist eine Voraussetzung nicht eindeutig oder fehlt der Zugriff auf die Benutzerverwaltung, stoppt man die Diagnose und übergibt den Fall an den zuständigen Sophos-Central-, Verzeichnisdienst- oder ZTNA-Administrator.
Troubleshooting nach Symptom
Hinzufügen oder Bearbeiten einer agentenlosen RDP-/SSH-Ressource schlägt fehl
Wahrscheinliche Ursache: Mindestens ein Mitglied der verwendeten Benutzergruppe hat keine gültige E-Mail-Adresse. Das kann sowohl eine ZTNA-Ressource als auch eine RDP-/SSH-Ressource in einer Protected-Browser-Anwendungsgruppe betreffen.
Prüfung:
- Man öffnet Meine Umgebung > Benutzer und Gruppen > Benutzer.
- In der Spalte E-Mail prüft man alle Benutzer der Gruppe, die der Ressource beziehungsweise Anwendungsgruppe zugeordnet werden soll.
Erwartete Beobachtung: Jeder Benutzer in der betroffenen Gruppe besitzt eine gültige E-Mail-Adresse. Ein leerer Eintrag bestätigt den Fehlerzustand.
Sichere Massnahme: Die fehlende Adresse wird im führenden Verzeichnisdienst ergänzt. Nur bei manuell in Sophos Central angelegten Benutzern ergänzt man sie direkt in Sophos Central. Bereits vorhandene Adressen ändert man nicht auf Verdacht.
Erneut validieren: Man wiederholt das Hinzufügen oder Bearbeiten derselben Ressource mit unveränderter Gruppe. Schlägt es trotz vollständig gepflegter Spalte E-Mail fehl, ist diese Ursache nicht bestätigt. Statt weitere Identitätsdaten zu ändern, erfasst man Ressourcentyp, Gruppe, Zeitpunkt und sichtbare Meldung und eskaliert den Fall.
Agentenlose RDP-/SSH-Ressource ist über Protected Browser nicht erreichbar
Wahrscheinliche Ursache: Das Gerät kann den ZTNA-Gateway-FQDN nicht korrekt auflösen. Der erste Trennpunkt ist jedoch das ZTNA-Benutzerportal: Ist bereits dieses über Protected Browser nicht erreichbar, liegt das Problem vor der einzelnen RDP-/SSH-Ressource.
Prüfung:
- Auf demselben Gerät und mit demselben Benutzer versucht man, das ZTNA-Benutzerportal über Protected Browser zu öffnen.
- Ist das Portal nicht erreichbar, führt man auf dem betroffenen Gerät eine DNS-Abfrage aus:
nslookup <ZTNA-Gateway-FQDN>
<ZTNA-Gateway-FQDN> wird durch den tatsächlich konfigurierten Gateway-Namen ersetzt. nslookup ist ein lesender Test und ändert keine Konfiguration.
Erwartete Beobachtung: Bei einem Sophos Cloud Gateway wird der Gateway-Name zur Adresse des Gateway-Proxys aufgelöst. Bei einem lokalen Gateway wird er zur Adresse des ZTNA-Gateways aufgelöst, die auf dem eigenen DNS-Server konfiguriert ist. Man vergleicht die Antwort mit dem tatsächlich konfigurierten Ziel des jeweiligen Gateway-Modells. Schlägt die Auflösung fehl, muss die DNS-Konfiguration geprüft werden. Eine andere Antwort bestätigt erst dann einen Fehler, wenn sie nicht dem konfigurierten Ziel entspricht. Ist das Sollziel unbekannt, ändert man DNS nicht, sondern übergibt die Prüfung an den DNS-/ZTNA-Verantwortlichen.
Sichere Massnahme: Die DNS-Konfiguration wird nach dem dafür vorgesehenen DNS-/ZTNA-Verfahren korrigiert. Die korrekte Zone und das Ziel hängen vom Gateway-Modell ab; deshalb nimmt man hier keine allgemeinen DNS-Änderungen vor.
Erneut validieren: Nachdem der DNS-/ZTNA-Verantwortliche eine Korrektur nach dem vorgesehenen Verfahren bestätigt hat, führt man dieselbe nslookup-Abfrage erneut aus. Danach öffnet man das ZTNA-Benutzerportal und testet erst dann die ursprüngliche RDP-/SSH-Ressource. Ist die DNS-Antwort wie erwartet und das Portal erreichbar, die Ressource aber weiterhin nicht, dokumentiert man diese beiden positiven Kontrollen und eskaliert die ressourcenspezifische ZTNA-Prüfung.
„Netzwerk nicht erreichbar“ oder „Verbindung konnte nicht hergestellt werden“
Wahrscheinliche Ursache: ZTNA verwendet einen Identity Provider wie Okta oder Entra ID, der Benutzer ist in Protected Browser aber mit seiner Sophos ID oder als lokaler Benutzer angemeldet. Beim Zugriff auf eine SSH- oder RDP-Anwendung hinter dem ZTNA-Gateway können dann die genannten Meldungen erscheinen.
Prüfung: Man ermittelt, welcher Identity Provider in ZTNA konfiguriert ist, und vergleicht ihn mit der Anmeldemethode der aktuellen Protected-Browser-Sitzung.
Erwartete Beobachtung: Die Ursache ist bestätigt, wenn ZTNA einen Identity Provider verwendet, die Protected-Browser-Sitzung aber nicht über diesen Provider authentifiziert wurde.
Sichere Massnahme: Man beendet die betroffene Sitzung und meldet den Benutzer in Protected Browser über den in ZTNA konfigurierten Identity Provider an. Den ZTNA-Identity-Provider ändert man nicht, um einen einzelnen Anmeldefehler zu umgehen.
Erneut validieren: Mit der neu authentifizierten Sitzung öffnet man dieselbe SSH- oder RDP-Anwendung. Bleibt die Meldung trotz übereinstimmender Anmeldemethode bestehen, erfasst man Identity Provider, Benutzer, Ressource und Zeitpunkt und übergibt den Fall an den ZTNA-Verantwortlichen.
Benutzer kann sich nicht in Protected Browser anmelden
Hier prüft man zwei voneinander unabhängige Ursachen. Man behebt sie nicht gleichzeitig, damit die wirksame Ursache nachvollziehbar bleibt.
Self-Service-Portal-Zugriff fehlt
Prüfung: Man öffnet Meine Umgebung > Benutzer und Gruppen > Benutzer und kontrolliert beim betroffenen Benutzer die Spalte Rolle. Alternativ wählt man den Benutzernamen aus und prüft den Text unter dem Profilfoto.
Erwartete Beobachtung: Bei vorhandenem Zugriff auf das Sophos Central Self Service Portal wird in der Spalte Rolle beziehungsweise unter dem Profilfoto SelfService angezeigt.
Sichere Massnahme: Fehlt SelfService, übergibt man die Vergabe des Self-Service-Portal-Zugriffs an den zuständigen Sophos-Central-Administrator.
Erneut validieren: Man bestätigt zuerst die Anzeige SelfService und wiederholt danach die Anmeldung mit genau diesem Benutzer.
E-Mail-Adresse ist mit mehreren Sophos-Central-Konten verknüpft
Prüfung: Man klärt, ob die E-Mail-Adresse des betroffenen Benutzers mehreren Sophos-Central-Konten zugeordnet ist.
Erwartete Beobachtung: Die Adresse darf nicht mit mehreren Sophos-Central-Konten verknüpft sein.
Sichere Massnahme: Die Zuordnung lässt man durch den zuständigen Tenant- beziehungsweise Identitätsadministrator bereinigen. Ohne bestätigten Ziel-Tenant löscht man keinen Benutzer und ändert keine produktive Adresse.
Erneut validieren: Nachdem die eindeutige Zuordnung bestätigt ist, wiederholt man die Protected-Browser-Anmeldung. Bleibt sie erfolglos, dokumentiert man SelfService, E-Mail-Zuordnung, Zeitpunkt und sichtbare Meldung für die Eskalation.
SSH meldet „Hostschlüsselüberprüfung fehlgeschlagen“
Wahrscheinliche Ursache: Der im SSH-Client gespeicherte Schlüssel stimmt nicht mehr mit dem Schlüssel des Hosts überein. Das kann nach einer legitimen Änderung wie einer Neuinstallation geschehen; dieselbe Meldung kann jedoch auch auf eine unerwartete Änderung hinweisen.
Prüfung: Den erwarteten Fingerabdruck des Hostschlüssels ermittelt man über einen unabhängigen, vertrauenswürdigen Kanal beim Systemverantwortlichen und vergleicht ihn mit dem Fingerabdruck des richtigen Zielhosts. Dabei verlässt man sich weder auf die fehlerhafte SSH-Verbindung noch auf den dort angebotenen neuen Schlüssel. Ist der erwartete Fingerabdruck nicht unabhängig bestätigt, passt er nicht oder ist die Änderung nicht erklärbar, stoppt man an dieser Stelle und eskaliert den Vorgang als Sicherheitsereignis.
Erwartete Beobachtung: Zielhost, legitime Schlüsseländerung und erwarteter Fingerabdruck sind unabhängig und eindeutig bestätigt.
Sichere Massnahme: Vor dem Löschen klärt man, welche Einträge der verwendete SSH-Client mit der angebotenen Funktion entfernt. Sophos nennt als Beispiel Bekannte Hosts löschen, bestätigt aber nicht, dass diese Funktion nur den betroffenen Host entfernt. Ist der Löschumfang unbekannt oder lässt sich der erwartete Fingerabdruck nicht unabhängig bestätigen, führt man keinen Reset aus und eskaliert. Den gespeicherten Schlüssel entfernt man erst bei geklärtem Umfang und bestätigtem Fingerabdruck. Bei der nächsten Verbindung akzeptiert man nur den Schlüssel, dessen Fingerabdruck mit der unabhängigen Bestätigung übereinstimmt.
Erneut validieren: Man baut die Verbindung erneut auf. Die Hostschlüsselprüfung soll mit dem neu akzeptierten Schlüssel erfolgreich sein. Tritt die Meldung erneut auf oder ändert sich der Schlüssel nochmals unerwartet, entfernt man nicht wiederholt Einträge, sondern eskaliert mit Hostname, Zeitpunkt und SSH-Client.
Rückweg, Eskalation und Betriebsgrenzen
Für diese Fehlerbilder gibt es keinen universellen Rollback. Als sicherer Rückweg nimmt man keine breiten Änderungen vor und dokumentiert den Ausgangswert einer gezielt geänderten Benutzerzuordnung. Bleibt der Erfolg aus, stoppt man am jeweiligen Eskalationspunkt. Das Löschen bekannter SSH-Hostschlüssel ist kein allgemeiner Reset und ist nur bei unabhängig bestätigtem Fingerabdruck und bekanntem Löschumfang vertretbar.
Für eine Support- oder interne Eskalation hält man mindestens Symptom, Benutzer, Gerät, Ressourcentyp, Gateway-Modell, ZTNA-Gateway-FQDN, Zeitpunkt und Ergebnis der unmittelbar zugehörigen Prüfung fest. Zugangsdaten, private Schlüssel und Tokens gehören nicht in das Ticket.
Man wiederholt nur die Prüfung, die zur tatsächlich ausgeführten Massnahme oder zur bestätigten Übergabe gehört: das erneute Hinzufügen oder Bearbeiten der Ressource nach einer E-Mail-Korrektur, die Anmeldung nach bestätigtem Self-Service-Portal-Zugriff oder eindeutiger Kontozuordnung, den Ressourcenaufruf nach der Anmeldung über den konfigurierten Identity Provider sowie die SSH-Verbindung nach dem kontrollierten Hostschlüssel-Reset. Nach einer Übergabe an den DNS-/ZTNA-Verantwortlichen prüft man nslookup, Benutzerportal und ursprüngliche Ressource erst erneut, wenn dieser eine Korrektur nach seinem Verfahren bestätigt hat.
Abgrenzung zu verwandten Anleitungen
Dieses Runbook behandelt ausschliesslich die hier beschriebenen Protected-Browser-Symptome. Die Einrichtung von Protected Browser oder der Erweiterung sowie allgemeine DNS- und ZTNA-Konfiguration gehören in die jeweiligen Einrichtungsanleitungen. Wo eine solche Konfiguration erforderlich ist, übergibt man den Fall an den zuständigen Administrator.