Sophos Protected Browser: Benutzer und Anmeldung einrichten

Für Sophos Protected Browser braucht jeder Benutzer drei Dinge: ein Benutzerobjekt in Sophos Central, eine passende Anmeldemethode und Zugriff auf das Sophos Self Service Portal (SSP). Der sichere Ablauf ist deshalb: Benutzerquelle festlegen, Benutzer bereitstellen, bei einem Cloud-Identitätsanbieter die Verbundanmeldung konfigurieren, die Sophos-Anmeldemethode wählen und erst danach den SSP-Zugriff freigeben.

Voraussetzungen, Lizenz und Rollen

Vor der ersten Änderung prüft man:

Produktzugriff: Unter My Products > Protected Browser muss Protected Browser im vorgesehenen Tenant verfügbar sein. Eine separate SKU oder ein Verfahren für eine Testlizenz ist hier nicht dokumentiert. Fehlt der Menüpunkt, stoppt man und lässt die Berechtigung des Tenants klären, statt eine Lizenzannahme zu treffen.
SSP: Alle Protected-Browser-Benutzer benötigen Zugriff auf das Sophos Self Service Portal.
Benutzerquelle: Manuell verwaltete Benutzer können einen verzeichnisgestützten Benutzerbestand ergänzen, etwa für Personen, die nicht im Verzeichnisdienst vorhanden sind. Benutzer derselben Domäne dürfen jedoch nicht gleichzeitig aus AD und Entra ID synchronisiert werden.
Rolle: Zum Verifizieren einer Verbunddomäne und zum Einrichten eines Identitätsanbieters ist ein Super Admin erforderlich. Verzeichnisquellen richtet ein Administrator der Sophos-Central-Verwaltungskonsole ein. Wenn beim manuellen Anlegen eine Administratorrolle vergeben werden soll, ist dafür ebenfalls ein Super Admin erforderlich. Für reine Protected-Browser-Nutzer genügt die Rolle User; sie gewährt nur Zugang zum SSP. Die Abgrenzung der administrativen Rollen erklärt Sophos Fusion Administrationsrollen richtig zuweisen.
Pilot: Man hält einen einzelnen Testbenutzer mit erreichbarer E-Mail-Adresse bereit. Bei Entra ID müssen Email und User principal name übereinstimmen. Der Protected Browser unterstützt Google Directory nicht.

Verwendet man Okta, synchronisiert man die Okta-Benutzer zuerst mit Active Directory und danach AD mit Sophos Central. Die allgemeinen Identitäts- und ZTNA-Abhängigkeiten bleiben in der Anleitung Sophos ZTNA einrichten: Überblick und Reihenfolge; hier geht es nur um die für Protected Browser nötige Benutzer- und Anmeldekette.

Benutzerquelle wählen und Benutzer bereitstellen

Variante A: Einzelne Benutzer manuell anlegen

Diese Variante passt für einen kleinen Pilot oder für Personen, die nicht im Verzeichnisdienst vorhanden sind.

Man öffnet My Environment > Users & Groups.
Man klickt auf Add user.
Unter First and last name trägt man den Namen ohne Domänennamen ein.
Unter Role wählt man für einen normalen Protected-Browser-Benutzer User. Eine administrative Rolle ist nur dann passend, wenn die Person tatsächlich Central administrieren soll.
Bei Bedarf trägt man den Manager ein.
Man ergänzt die E-Mail-Adresse und speichert den Benutzer mit Save.

Der frei wählbare Name des Pilotbenutzers ist kein technischer Schlüssel. Entscheidend für Einladung und Anmeldung ist eine korrekte, erreichbare E-Mail-Adresse.

Variante B: Active Directory synchronisieren

Die vollständige AD-Synchronisierung ist eine gemeinsam genutzte Identitätsaufgabe und wird nicht nochmals als zweites Verfahren in diesem Artikel aufgebaut. Für den Protected-Browser-Entscheid sind jedoch diese Grenzen wichtig:

Auf dem Synchronisierungscomputer muss .NET Framework 4.6.2 installiert sein.
Man benötigt Sophos-API-Anmeldeinformationen mit der API-Rolle Service Principal Active Directory Sync. Der Zugriff bleibt so eng wie möglich.
Alle zu synchronisierenden Benutzer benötigen eine E-Mail-Adresse. Firewall oder Proxy müssen die von Sophos geforderten Domänen zulassen.
Benutzer und E-Mail-Adressen müssen je Sophos-Central-Konto eindeutig sein. Mehrere AD-Clients aus derselben Domäne oder Subdomäne werden nicht unterstützt.
Benutzer und Benutzergruppen werden gemeinsam synchronisiert; nur eine der beiden Objektarten zu synchronisieren ist nicht möglich.

Hinweis zum Betrieb: Sophos empfiehlt, inaktive Benutzer und Geräte in AD zu entfernen. Ein AD-Filter kann zwar verhindern, dass inaktive Benutzer synchronisiert werden, beseitigt aber nicht das Sicherheitsrisiko des weiterhin vorhandenen AD-Kontos. Änderungen an Suchbasen oder Filtern können ausserdem zuvor angelegte Central-Benutzer und -Gruppen aus dem Suchbereich nehmen und dadurch aus Sophos Central entfernen. Deshalb prüft man den geplanten Umfang vor der Änderung.

Variante C: Microsoft Entra ID hinzufügen

Für Entra ID benötigt man einen Administrator der Sophos-Central-Verwaltungskonsole, ein Microsoft-Azure-Abonnement mit Entra ID, die Berechtigung Directory.Read.All sowie eine Azure-Anwendung. Man notiert Tenant domain, Application ID, den Value des geheimen Clientschlüssels und dessen Ablaufdatum.

Wichtige Grenzen vor dem Start:

Office 365 GCC High wird für diese Synchronisierung nicht unterstützt.
Pro Domäne ist nur eine Entra-ID-Quelle möglich.
Benutzer oder E-Mail-Adressen dürfen nicht mit mehreren Sophos-Central-Konten synchronisiert werden.
Für dieselbe Domäne darf die Benutzersynchronisierung nicht parallel aus AD und Entra ID erfolgen.
Vorhandene Central-Benutzer und -Gruppen ohne Entra-ID-Entsprechung müssen manuell verwaltet werden.

So legt man die Quelle an:

Man öffnet Global Settings > Platform > Directory service.
Man klickt auf Add Microsoft Entra ID.
Man gibt Name und Description der Quelle sowie deren Domain ein.
Man klickt auf Next.

Die weitere Verzeichnissynchronisierung bleibt in der Verantwortung der zentralen Identitätsverwaltung. Dort verwendet man die zuvor geprüften Azure-Werte. Falls eine bestehende Azure-Anwendung nur die ältere Berechtigung Microsoft Entra ID Graph Directory.Read.All besitzt, muss für Änderungen an der Synchronisierung die Berechtigung Microsoft Graph Directory.Read.All ergänzt werden.

Verbundanmeldung konfigurieren

Diesen Abschnitt benötigt man, wenn sich Benutzer über einen Cloud-Identitätsanbieter anmelden. Die Schritte führt man mit einem Super Admin aus. Vor einer Umstellung stellt man sicher, dass alle Administratoren und Benutzer einer Domäne zugewiesen sind und einen Identitätsanbieter haben. Andernfalls darf die Verbundanmeldung noch nicht zur Anmeldeoption werden.

1. Verbunddomäne verifizieren

Man öffnet Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in.
Man klickt auf Verify domains.
Unter Federated domains wählt man Add domain.
Man trägt Domain name und Description ein und klickt auf Save.
Im Dialog Verify domain ownership kopiert man mit Copy den angezeigten TXT record und wählt danach Cancel.
Man veröffentlicht den TXT-Eintrag im DNS. Die Übernahme kann bis zu 24 Stunden dauern.
Anschliessend kehrt man zu Sign-in and Identity > Sophos Sign-in > Verify domains zurück. Beim betreffenden Verification Status klickt man auf Verify domain ownership, prüft die Details und wählt Verify.

Erfolgreich ist dieser Schritt, wenn die Domäne unter Federated domains mit einem Verifizierungsdatum erscheint. Die Verifizierung gilt ein Jahr und kann innerhalb dieses Jahres wiederholt werden.

2. Identitätsanbieter hinzufügen

Man öffnet Global Settings > Access Control > Sign-in and Identity > Federated identity providers und klickt auf Add identity provider. Man vergibt einen Namen ohne Sonderzeichen wie ., @ oder #; mit solchen Zeichen lässt sich die Konfiguration nicht speichern.

Danach wählt man die passende Variante:

Microsoft Entra ID: Unter Type und Vendor wählt man jeweils Microsoft Entra ID, trägt unter Configure Entra ID settings die Tenant ID ein und wählt unter Configure domains die verifizierte Domäne.
OpenID Connect, beispielsweise Okta: Man wählt OpenID Connect und den Anbieter. Unter Configure OpenID Connect settings hinterlegt man Client ID, Issuer, Authz endpoint und JWKS URL. Danach wählt man die verifizierte Domäne.
Microsoft AD FS: Man wählt Microsoft AD FS, den Anbieter und die AD FS metadata URL. Dann wählt man die Domäne, speichert mit Save und übernimmt die danach angezeigte Entity ID und Callback URL in die AD-FS-Konfiguration.

Mehrere Domänen dürfen einem Anbieter hinzugefügt werden, jeder Benutzer kann aber nur einer Domäne zugeordnet sein. Ausserdem legt man fest, wer MFA durchsetzt:

IdP enforced MFA: Der Identitätsanbieter erzwingt MFA.
No IdP enforced MFA: Sophos Central erzwingt MFA nach erfolgreicher IdP-Authentifizierung.

Man klickt auf Save, wählt den Anbieter in der Liste aus und klickt auf Turn on. Central erlaubt die Aktivierung erst, wenn die Einrichtung vollständig und die Angaben gültig sind.

3. Sophos-Anmeldemethode wählen

Man öffnet Global Settings > Access Control > Sign-in and Identity > Sophos sign-in settings.
Man wählt genau eine Option:
- Federated credentials only, wenn ausschliesslich ein Cloud-Identitätsanbieter verwendet wird und keine Benutzer manuell in Sophos Central angelegt wurden.
- Sophos Fusion Admin or Federated credentials, wenn neben dem Cloud-Identitätsanbieter auch manuell angelegte Benutzer vorhanden sind.
Man klickt auf Save.

Die zweite Option ist kein pauschal „sichererer“ Modus, sondern die notwendige Wahl für einen gemischten Benutzerbestand. Vor der Umstellung weiterer Benutzer dokumentiert man den vorherigen Modus und prüft zuerst den Pilotbenutzer.

SSP-Zugriff freigeben

Die Freigabe wählt man passend zur Einführung. Wer allen synchronisierten Benutzern SSP-Zugriff geben will, aktiviert den allgemeinen Zugriff vor der Verzeichnissynchronisierung. Soll nur eine ausgewählte Gruppe starten, synchronisiert man zuerst und sendet danach gezielt die Einrichtungs-E-Mail.

Zugriff für alle Benutzer

Man öffnet Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in.
Unter User Access aktiviert man Sophos Fusion Self Service Portal access.

Damit erhalten alle Benutzer einschliesslich der aus einem Verzeichnisdienst synchronisierten Personen SSP-Zugriff und eine Begrüssungsmail mit Informationen zur Anmeldung.

Zugriff nur für bestimmte Benutzer

Man öffnet My Environment > Users & Groups > Users.
Man markiert die vorgesehenen Pilotbenutzer und klickt auf Email Setup Link.
Unter Other Emails wählt man Sophos Fusion Self Service Welcome/Setup Email.
Man klickt auf Save.

Auch in dieser Variante erhalten die ausgewählten Benutzer eine Begrüssungsmail mit Informationen zur Anmeldung.

Validierung mit einem Pilotbenutzer

Man prüft die Kette in derselben Reihenfolge, in der sie eingerichtet wurde:

Der Benutzer ist unter My Environment > Users & Groups > Users genau einmal vorhanden und besitzt die erwartete E-Mail-Adresse.
Bei Verbundanmeldung steht die Domäne unter Federated domains mit Verifizierungsdatum und der Identitätsanbieter ist aktiviert.
Unter Sophos sign-in settings ist der zum Benutzerbestand passende Modus gespeichert.
Der Pilotbenutzer erhält die SSP-Begrüssungsmail und kann den darin beschriebenen Anmeldeweg verwenden.
Erst nach diesem Erfolg wird dieselbe Methode für weitere Benutzer freigegeben.

Bleibt eines dieser Ergebnisse aus, weitet man die Einführung nicht aus. Zuerst prüft man den unmittelbar vorherigen Baustein; eine erfolgreiche Domänenverifizierung beweist beispielsweise noch nicht, dass der Identitätsanbieter aktiv oder der SSP-Zugriff vergeben ist.

Fehlersuche nach Symptom

Die Verbunddomäne lässt sich noch nicht verifizieren

Man kontrolliert, ob der kopierte TXT-Eintrag exakt in der richtigen DNS-Zone veröffentlicht wurde. Dann wartet man die dokumentierte Übernahmezeit von bis zu 24 Stunden ab und startet Verify domain ownership erneut. Ein noch fehlendes Verifizierungsdatum ist kein Grund, mit der IdP-Aktivierung fortzufahren.

Der Identitätsanbieter lässt sich nicht speichern oder aktivieren

Scheitert bereits das Speichern, entfernt man Sonderzeichen wie ., @ oder # aus dem Namen. Ist Turn on nicht möglich, ist die Einrichtung unvollständig oder enthält ungültige Angaben. Je nach Typ prüft man Tenant ID, OIDC-Endpunkte beziehungsweise AD FS metadata URL und die gewählte Domäne.

Der Entra-Verbindungstest meldet eine ungültige Client-ID

Man prüft, ob als Client ID wirklich die Application ID der Azure-Anwendung eingetragen wurde. Sophos nennt ausserdem eine im Microsoft Entra ID Admin Center deaktivierte Benutzeranmeldung als mögliche Ursache. Zuerst korrigiert man diese beiden Punkte; eine zweite Quelle für dieselbe Domäne legt man nicht vorsorglich an.

Benutzer fehlen oder erscheinen doppelt

Bei AD prüft man zuerst, ob das Konto aktiv ist, eine E-Mail-Adresse besitzt und innerhalb der gewählten Suchbasis beziehungsweise Filter liegt. Bei Entra ID müssen vorhandene Central-Objekte eine passende Entra-ID-Entsprechung haben. Doppelte Benutzer können entstehen, wenn der von Entra ID synchronisierte UPN nicht mit der Benutzeranmeldung am Endpoint übereinstimmt. Deshalb bereinigt man zuerst Quelle, UPN und E-Mail-Zuordnung, statt beide Objekte für den SSP-Zugriff freizugeben.

Der Benutzer erhält keine SSP-Begrüssungsmail

Man prüft, welche der beiden Freigabevarianten verwendet wurde. Beim allgemeinen Zugriff muss Sophos Fusion Self Service Portal access aktiv sein; beim gezielten Pilot muss Sophos Fusion Self Service Welcome/Setup Email für genau diesen Benutzer gespeichert worden sein. Danach kontrolliert man die beim Benutzer hinterlegte E-Mail-Adresse. Stimmen diese Zustände und trifft weiterhin keine Mail ein, endet der verifizierte Diagnoseweg hier; man eskaliert die Zustellung, statt Anmelde- oder Rollenwerte auf Verdacht zu ändern.

Sicherer Rückweg und Austritt

Ein allgemeines Verfahren zum Entfernen des Protected-Browser-Zugriffs und ein vollständiger Rückweg nach einer Verbundumstellung sind hier nicht dokumentiert. Deshalb geht man begrenzt und reversibel vor:

Vor der Änderung notiert man den bisherigen Wert unter Sophos sign-in settings und den Pilotumfang.
Kann der Pilot die Anmeldung nicht abschliessen, stoppt man die Ausweitung. Solange noch eine funktionierende Administratorsitzung besteht, stellt man im selben Dialog den dokumentierten vorherigen Anmeldemodus wieder her und speichert ihn.
Anschliessend prüft man erneut den bisherigen Anmeldeweg. Weder Verbunddomäne noch Identitätsanbieter werden entfernt, solange deren Abhängigkeiten nicht ausserhalb dieser Anleitung geprüft wurden.
Beim Austritt aus AD entfernt man inaktive Benutzer und Geräte im führenden Verzeichnis. Nur aus der Synchronisierung zu filtern reduziert zwar die übertragene Datenmenge, beseitigt das inaktive AD-Konto und dessen Sicherheitsrisiko aber nicht.
Für das Entziehen des SSP-Zugriffs einzelner oder aller Benutzer ist in diesem Verfahren kein verifizierter Rückweg verfügbar. An dieser Stelle stoppt man und klärt das aktuelle Verfahren im Tenant beziehungsweise mit Sophos Support, statt eine Lösch- oder Deaktivierungsaktion zu erraten.

Laufender Betrieb

Diese Punkte prüft man regelmässig:

Verbunddomäne: Verifizierungsdatum überwachen; die Verifizierung gilt ein Jahr und kann vorher erneuert werden.
Entra ID: Ablaufdatum des geheimen Clientschlüssels dokumentieren. Vor Änderungen sicherstellen, dass die Microsoft-Graph-Berechtigung Directory.Read.All vorhanden ist.
AD: Inaktive Konten und Geräte regelmässig im führenden Verzeichnis suchen und entfernen. Filteränderungen vorab auf unbeabsichtigte Entfernungen aus Sophos Central prüfen.
Identitätsabdeckung: Sicherstellen, dass jeder betroffene Administrator und Benutzer weiterhin genau einer Domäne und einem gültigen Identitätsanbieter zugeordnet ist.
SSP-Zugriff: Bei jedem Ein-, Über- oder Austritt prüfen, ob Benutzerquelle, Anmeldemodus und SSP-Freigabe weiterhin zusammenpassen.
Pilot vor Breitenänderung: Änderungen an Quelle, Domäne, IdP oder Anmeldemodus zuerst mit einem begrenzten Benutzer testen und erst nach dem erwarteten Ergebnis ausrollen.