Zum Inhalt springen
Avanet

Microsoft Entra ID SSO für Sophos Firewall WebAdmin einrichten

Sophos Firewall

Für Microsoft Entra ID SSO am WebAdmin braucht es vier zusammenpassende Einstellungen: eine Entra-Gruppe oder App-Rolle, ein lokales Device-Access-Profil, die exakte Web admin console URL als Redirect URI und den Entra-Server unter Administrator authentication methods. Erst diese Kette macht aus einem erfolgreich angemeldeten Entra-Benutzer einen Firewall-Administrator mit den vorgesehenen Rechten.

Wenn die Umgebung statt OAuth bereits eine zentrale Device-Administration über TACACS+ verwendet, passt der getrennte Ablauf TACACS+ für Sophos Firewall Administratoren. Anders als Entra Role Mapping erzeugt TACACS+ dabei keine automatische lokale Profilzuweisung.

⚠️ Vor der Aktivierung: Eine bestehende lokale Admin-Sitzung offen lassen, den lokalen admin aus dem Managementnetz testen und den Konsolen- beziehungsweise Device-Console-Zugang kennen. SSO und Entra-MFA sind kein Grund, WebAdmin breit aus der WAN-Zone freizugeben. Wenn Pilotlogin, Rechte oder lokaler Rückweg nicht funktionieren, wird Entra noch nicht produktiv priorisiert.

WebAdmin SSO in acht Schritten

SFOS 22

  1. WebAdmin-FQDN, DNS, Zertifikat, Systemzeit und enge Erreichbarkeit aus dem Managementnetz prüfen.
  2. Unter Profiles > Device access die benötigten Administratorprofile vorbereiten.
  3. In Microsoft Entra ID eine eigene Single-Tenant-App mit Pilotadministrator, App-Rolle oder Security-Gruppe und überwachtem Client Secret anlegen.
  4. Unter Authentication > Servers einen Server vom Typ Microsoft Entra ID SSO anlegen oder den vorhandenen Server erweitern.
  5. User type auf Administrator setzen und die Entra-Rollen oder -Gruppen in der richtigen Reihenfolge auf die lokalen Profile mappen.
  6. Die von der Firewall angezeigte Web admin console URL exakt als Redirect URI der Entra-App eintragen und Test connection erfolgreich ausführen.
  7. Den Entra-Server unter Authentication > Services > Administrator authentication methods aktivieren, nach oben verschieben und Apply wählen.
  8. In einem privaten Browserfenster einen Pilotadmin, einen nicht gemappten Benutzer, die tatsächlichen Berechtigungen und den lokalen Fallback separat testen.

Die bisherigen Klickpfade, User type-/Role-Mapping-Felder und dienstspezifischen Logs in diesem Artikel beziehen sich auf SFOS 22. Für SFOS 23.0 gilt der folgende OIDC-Zweig. Die sicheren Managementpfade, lokalen Profile, App-Zuweisungen, MFA-, Positiv-, Negativ- und Fallback-Tests bleiben erforderlich. Die SFOS-23-Hilfe ist kein Nachweis für einen GA-Termin.

SFOS 23.0: OIDC-Server und Administrator-Mapping

  1. Unter Authentication > Servers > Add den Server type: OpenID Connect und IdP vendor: Microsoft Entra ID wählen. Ein bestehendes Entra-Objekt wird vor Änderungen mit Dienstzuweisungen und Redirect URIs dokumentiert; allein wegen der neuen Maske wird keine zweite Entra-App angelegt.
  2. Server name, Client ID mit der Application (client) ID und Client secret mit dem Secret-Value der App setzen. Unter OpenID Connect URLs > Issuer URL wird laut Entra-Konfiguration die Directory (tenant) ID eingetragen, nicht eine selbst konstruierte URL. Die anderen URL-Einstellungen gelten für diesen Anbieter nicht.
  3. Unter Redirect URIs zwischen Use firewall URL und Enter manually wählen. Bei Konfiguration einer einzelnen Firewall über Sophos Fusion den Appliance-Hostnamen manuell setzen, nicht die Reverse-SSO-URL übernehmen. Show URLs öffnen und die exakte Web admin console URL als Web-Redirect-URI in der Entra-App hinterlegen. DNS und Zertifikat müssen zu diesem Namen passen.
  4. Unter User attributes die Vorgaben Display name: name, Username: upn und Email address: email beibehalten, solange kein nachweislich anders aufgebautes und unterstütztes Token verwendet wird. Die Fallback group für Benutzerdienste ersetzt weiterhin kein Administratorprofil.
  5. IdP authentication for firewall administrators einschalten. Dieser Schalter ist für reine Benutzerdienste standardmässig ausgeschaltet und ersetzt in SFOS 23 die bisherige Auswahl User type: Administrator.
  6. Unter IdP attribute zwischen Roles und Groups wählen, unter IdP value den exakten konfigurierten Rollen- beziehungsweise Gruppenwert und unter Device access profile das lokale Profil setzen. Für das bestehende Beispiel wird sfosAdminReadOnly auf Entra-WebAdmin-ReadOnly gemappt. Weitere Mappings hinzufügen und die Reihenfolge prüfen: Der erste passende Eintrag bestimmt das Profil.
  7. Test connection erfolgreich abschliessen, speichern und den Server unter Authentication > Services > Administrator authentication methods auswählen. Pro Methode ist unter SFOS 23 nur ein OpenID-Connect-IdP-Server möglich, nicht je einer pro Anbieter. Reihenfolge dokumentieren, lokalen Fallback behalten und Apply wählen.
  8. Mit einer neuen WebAdmin-Anmeldung die Pilotrolle, echte Menürechte, Nichtberechtigte und den lokalen Notzugang prüfen. Ein VPN- oder Captive-Portal-Login authentifiziert zwar den Benutzer, erzeugt oder aktualisiert aber kein Administratorobjekt. Änderungen an Entra-Rollen, -Gruppen oder Profilzuweisungen werden über einen WebAdmin-Login synchronisiert.

Beim Rechteentzug bleibt die unten beschriebene Besonderheit wichtig: Ein bestehendes lokales Administratorobjekt wird nicht allein durch Herabstufung in Entra zum normalen Benutzer. Die kontrollierte Entfernung auf der Firewall und der negative WebAdmin-Test bleiben nötig. Nach einem Upgrade werden OIDC-Felder, Callback, Dienstzuweisung und diese Rechteprüfung erneut abgenommen, bevor die offene lokale Sitzung geschlossen wird.

Nur API-Automation: Antwortprüfung beim Wechsel von SFOS 22 auf 23

Wer den Microsoft-Entra-ID-SSO-Server per API hinzufügt oder bearbeitet, muss die Ergebnisauswertung getrennt vom obigen UI-/OIDC-Ablauf prüfen. Die API-Referenz dokumentiert folgende Statuszeilen für diese Operationen:

  • SFOS 22, Add und Edit: 200/500/502/503.
  • SFOS 23, Add: 200/400/401/403/409/500.
  • SFOS 23, Edit: 200/400/401/403/404/500.

Damit steht 409 nur bei Add und 404 nur bei Edit; die bisherigen Zeilen 502/503 entfallen in der SFOS-23-Referenz. Das ist eine Dokumentationsänderung, kein hier getestetes Laufzeitverhalten: Die Referenzzeilen belegen weder die tatsächlich gelieferten HTTP-Transportstatus noch XML-Ergebniscodes oder exakte Laufzeitmeldungen. Daraus folgt auch keine Retry-Regel. Vor der Abnahme eines autorisierten Schreibvorgangs oder der Anpassung einer automatischen Ergebnisklassifizierung wird die API help des installierten Builds geprüft; anschliessend werden die Operationsantwort und der beabsichtigte Zustand des Zielobjekts validiert. Für sichere Requests, Secrets und Antwortprüfungen gilt der bestehende Leitfaden API-Zugriff sicher steuern.

Das unveränderte XML-Beispiel der Referenz ist kein bestätigtes SFOS-23-OIDC-Schema. AzureADSSO wird nicht allein wegen der neuen UI in OIDC umbenannt; die breiten Beispielwahlen Administrator und Open Group werden nicht ungeprüft produktiv übernommen. Die Management-, Least-Privilege-, Negativtest- und Recovery-Vorgaben dieses Artikels bleiben bestehen.

Add/Edit: Widersprüche vor einem API-Schreibzugriff klären. In beiden API-Referenzen für SFOS 22 und 23 nennt die Beschreibung von identifiertype die Werte roles und groups; das XML-Beispiel verwendet roles. Die Liste erlaubter Werte nennt dagegen $IDENTITY{IDENTIFIERGROUPS} und $IDENTITY{IDENTIFIERROLE}. Zudem heisst das Profilfeld in der Parametertabelle profileidentifier, im XML-Beispiel aber profileid mit dem Wert Administrator. Weder die Makros und Klartextwerte noch die beiden Feldnamen sind als austauschbare Aliasse bestätigt. Vor einem autorisierten Schreibzugriff muss die API help des installierten Builds die unterstützte Request-Darstellung klären. Man errät weder XML-Felder noch eine OIDC-Ersetzung; diese dokumentarische Einordnung verlangt keinen obligatorischen Labortest.

Dokumentierte Add/Edit-Limits, nur für die API: Beide Referenzen beschreiben ServerName als Typ SCALAR, Datentyp STRING, ohne Komma, mit höchstens 50 Zeichen und erlaubten UTF-8-Zeichen. ApplicationID, TenantID und ClientSecret sind jeweils ebenfalls SCALAR/STRING mit höchstens 50 Zeichen. Für RedirectURI stehen SCALAR/STRING, höchstens 200 Zeichen und die Beschreibung FQDN oder IP-Adresse der Firewall. Diese Referenzangaben sind keine bestätigte UI-/OIDC- oder Laufzeitvalidierung. Bei einer Abweichung werden weder IDs oder Secrets gekürzt noch Redirects still geändert; die unterstützte Darstellung wird zuerst geklärt. Die unaufgelöste Kennzeichnung ADSSOAPPANDTENANTID bei den beiden IDs belegt keinen regulären Ausdruck und wird nicht als solcher interpretiert.

API-Attribute und Zuordnungen: Für DisplayName dokumentieren beide Add/Edit-Tabellen den Typ SCALAR und die erlaubten Werte upn und name: Die Beschreibung empfiehlt name, das XML-Beispiel verwendet upn. Daraus folgt keine Gleichsetzung mit dem UI-Feld Username. EmailAddress ist als SCALAR mit dem einzigen erlaubten Wert email aufgeführt, UserType als SCALAR mit User oder Administrator. Die Zuordnungsfelder identifiervalue und profileidentifier sowie FallbackUserGroup sind jeweils SCALAR/STRING; zusätzliche Längenlimits nennt die Tabelle dafür nicht. Sie beschreibt den konfigurierten Entra-App-Rollenwert, das Administratorprofil für die passende Rolle oder Gruppe und die Benutzergruppe bei fehlender lokaler Gruppenzuordnung. Die oben genannten Feldnamenskonflikte bleiben dabei offen.

Alle zwölf genannten Parameterzeilen von ServerName bis FallbackUserGroup, einschliesslich identifiertype, sind in beiden Add/Edit-Tabellen als obligatorisch markiert; ihre Default-Spalten sind leer. Leere Zellen bestätigen weder einen Standardwert noch die Zulässigkeit des Weglassens. Aus der Tabelle werden auch keine undokumentierten Bedingungen für die Anwendbarkeit, Feldaliase oder ein vollständiger Request-Vertrag abgeleitet. Die API-Angaben bleiben vom UI-Ablauf und dessen Vorgaben getrennt.

Serverobjekt per API löschen (Delete): Die API-Referenzen für SFOS 22 und 23 verlangen ServerName als einzelnen Zeichenkettenwert (Typ SCALAR, Datentyp STRING): kein Komma, höchstens 50 Zeichen; UTF-8-Zeichen sind erlaubt. Man verwendet den exakten Namen des bestehenden, zur Löschung freigegebenen Serverobjekts, nicht eine Entra-Rolle, Gruppe oder ein Benutzerkonto. Vorher werden dessen tatsächliche Einstellungen und Dienstzuweisungen sicher gesichert und ein unabhängiger lokaler Management- und Recoveryweg bestätigt; bei einem gemeinsam verwendeten Server werden auch VPN- und Portaldienste in die Änderungsplanung einbezogen.

Beide Delete-Referenzen führen die Statuszeilen 200/500 auf. Sie sind nur Referenzangaben: Die Meldungszellen verweisen auf externen JavaScript-Text, und die Seiten liefern kein Lösch-XML. Daraus werden weder Meldungstexte noch tatsächliche HTTP-Status, XML-Ergebnisse oder Retry-Regeln abgeleitet. Vor einer autorisierten Löschung prüft man die API help des installierten Builds auf den passenden Request; nachher werden die Operationsantwort und durch erneutes Auslesen genau dieses Zielobjekts dessen beabsichtigte Entfernung geprüft. Anschliessend werden der lokale Zugang und die vorgesehenen Positiv-/Negativtests der betroffenen Dienste separat validiert. Eine Referenzzeile allein beweist keinen erfolgreichen Betriebsablauf.

Die Löschung des Serverobjekts ist nicht dasselbe wie das Entfernen seiner Zuweisung unter Administrator authentication methods oder das Löschen eines lokalen Administratorobjekts unter Authentication > Users. Bei einem fehlgeschlagenen Pilot bleibt der unten beschriebene nicht destruktive Rollback massgeblich: Dienstzuweisung zurücknehmen, lokalen Zugang prüfen und das Serverobjekt für die Fehleranalyse behalten.

Was die einzelnen Ebenen steuern

WebAdmin SSO verbindet mehrere Kontrollen, die leicht verwechselt werden:

  • Device Access und Local Service ACL bestimmen, aus welchen Netzen die WebAdmin-Konsole erreichbar ist.
  • Microsoft Entra ID authentifiziert den Benutzer und liefert Rollen- oder Gruppeninformationen im Token.
  • Role mapping auf der Firewall ordnet den ersten passenden Token-Wert einem lokalen Administratorprofil zu.
  • Device-Access-Profil bestimmt, welche Menüs der Administrator nicht, lesend oder schreibend verwenden darf.
  • Administrator authentication methods aktiviert den Entra-Server für den WebAdmin-Login.

Eine normale Firewall-Regel schaltet WebAdmin nicht frei. Umgekehrt gibt eine erreichbare Loginseite noch keine Administratorrechte. Die sichere Netzfreigabe erklärt Device Access und Local Service ACL auf Sophos Firewall.

Fehlt ein passendes Role mapping, kann die Anmeldung bei Entra ID erfolgreich sein. SFOS legt das Konto dann aber nur als normalen Benutzer an und verweigert den WebAdmin-Zugang. Das ist kein Browserfehler, sondern eine fehlende Zuordnung administrativer Rechte.

Entra-Gruppen oder App-Rollen

SFOS unterstützt beide Varianten:

  • Security-Gruppen sind einfach, wenn die Organisation Berechtigungen bereits über klar benannte Gruppen verwaltet. Im Mapping muss der Gruppenname exakt stimmen.
  • App-Rollen gelten gezielt für die Firewall-Anwendung. Im Mapping wird der exakte Value der Rolle verwendet, nicht nur ihr Anzeigename.

Für neue Admin-Integrationen sind app-spezifische Rollen gut nachvollziehbar. Security-Gruppen bleiben eine passende Alternative, wenn Gruppenmitgliedschaften bereits sauber freigegeben, geprüft und dokumentiert werden. Beide Modelle sollten nicht unkontrolliert gemischt werden.

SFOS wertet die Mappings von oben nach unten aus und verwendet den ersten Treffer. Full-Access- und Read-only-Zuordnungen müssen deshalb gegenseitig ausschliessend sein. Wird eine Überschneidung erkannt, werden zuerst die Entra-Zuweisungen korrigiert und danach beide Rollen erneut getestet; die Mapping-Reihenfolge dient nicht als Berechtigungsmodell.

Beispiel und Voraussetzungen planen

Das folgende Beispiel verwendet Dokumentationswerte. Sie werden durch die eigene Umgebung ersetzt:

  • WebAdmin-FQDN: fw01.example.com
  • Entra-App: Sophos Firewall - FW01 - WebAdmin
  • Full-Access-App-Rolle: sfosAdminFull
  • Read-only-App-Rolle: sfosAdminReadOnly
  • Lokales Full-Access-Profil: Administrator
  • Lokales Read-only-Profil: Entra-WebAdmin-ReadOnly

example.com ist eine reservierte Beispieldomain. Der produktive FQDN muss aus dem Managementnetz zur richtigen Firewall auflösen und zum verwendeten WebAdmin-Zertifikat passen. Für getrennte Berechtigungs- und Änderungszyklen ist eine eigene Entra-App mit eigenem Firewall-Serverobjekt pro WebAdmin-Integration am klarsten. Eine gemeinsam verwendete App ist möglich, koppelt aber Administratoren, VPN- und Portalbenutzer an dieselben App-Zuweisungen.

Vor dem Umbau sollten ausserdem feststehen:

  • Ein zweiter lokaler Administrator oder der lokale admin funktioniert unabhängig von Entra ID.
  • Passwort, Recoveryweg und Konsolenzugang des Notfallkontos sind dokumentiert. Falls dieser Weg noch nicht geprüft ist, hilft Sophos Firewall Admin-Passwort wiederherstellen bei der sicheren Vorbereitung.
  • Die bestehende Admin-Sitzung bleibt während der Umstellung geöffnet.
  • Die Firewall hat korrekte Uhrzeit und erreicht die benötigten Microsoft-Endpunkte über DNS und HTTPS.
  • Firewall und Admin-Browser erreichen die für den SSO-Flow benötigten Microsoft-Ziele. Die vollständige FQDN-Liste und die Direct-Web-Proxy-Ausnahmen stehen unter Allowlist für Microsoft-Entra-Anmeldungen.
  • Der WebAdmin-FQDN verwendet ein vertrauenswürdiges Zertifikat mit vollständiger Kette.
  • WebAdmin ist nur aus Managementnetzen, über VPN oder aus gezielt erlaubten Quellen erreichbar.
  • Owner und Ablaufdatum des Client Secrets sind dokumentiert.
  • Benutzer derselben Domain werden nicht gleichzeitig über Active Directory und Microsoft Entra ID synchronisiert. Beide Server dürfen vorhanden sein, aber vor der Umstellung muss feststehen, welches Verzeichnis diese Benutzer auf der Firewall verwaltet.
  • SFOS 22: Der Tenant ist kein Microsoft 365 Government Community Cloud High (GCC High), da diese SSO-Integration dafür nicht unterstützt wird. Die SFOS-23-Hilfe nennt die Einschränkung nicht mehr; das ist kein bestätigter Unterstützungsnachweis. GCC High muss vor einer SFOS-23-Einführung separat geklärt werden.

Für Uhrzeit und Zertifikate helfen Systemzeit und NTP konfigurieren sowie Zertifikate importieren und zuweisen.

Device-Access-Profile vorbereiten

Die Profile werden vor der SSO-Umschaltung erstellt, damit jeder Entra-Wert sofort auf definierte Rechte zeigt. Den allgemeinen Aufbau und die sichere Abnahme lokaler Administratorprofile erklärt Sophos Firewall Administratoren und Profile sicher einrichten; hier folgt nur das Entra-spezifische Mapping.

Für vollen Zugriff kann das integrierte Profil Administrator verwendet werden. Es gehört nur zum kleinsten notwendigen Personenkreis. Für Betrieb, Audit oder Helpdesk ist ein eigenes Profil meist besser:

  1. Profiles > Device access öffnen.
  2. Add wählen.
  3. Als Namen beispielsweise Entra-WebAdmin-ReadOnly eintragen.
  4. Für jedes benötigte Menü Read-only setzen.
  5. Nicht benötigte Bereiche auf None lassen.
  6. Schreibrechte nur dort als Read-write vergeben, wo die Aufgabe sie wirklich benötigt.
  7. Speichern und das Profil nochmals gegen die tatsächliche Rolle des Teams prüfen.

Ein Read-only-Name allein macht das Profil nicht schreibgeschützt. Entscheidend sind die Einstellungen None, Read-only und Read-write in der Berechtigungsmatrix. Untermenüs lassen sich über die Aufklappfunktion enger konfigurieren.

Entra-App und Administratorrollen vorbereiten

Existiert bereits eine sauber dokumentierte Entra-App für VPN oder Captive Portal, kann derselbe Entra-ID-Server auch für WebAdmin verwendet werden. Redirect URI, Administratorrollen und Tests bleiben trotzdem dienstspezifisch. Die vollständige gemeinsame App- und Serverbasis erklärt Entra ID SSO für Sophos Connect und VPN Portal; für lokale Browserbenutzer gilt der eigene Ablauf Entra ID SSO für Captive Portal.

Bei einer gemeinsam verwendeten App müssen vor Assignment required alle berechtigten Administrator-, VPN- und Portalgruppen zugewiesen und anschliessend alle verwendeten Dienste getestet werden. Für unabhängige Adminberechtigungen, Secret-Wechsel und Rollouts ist eine dedizierte WebAdmin-App mit einem eigenen Entra-Serverobjekt übersichtlicher.

Für eine neue Integration umfasst die aktuelle Sophos-Konfiguration:

  1. Unter Microsoft Entra ID > App registrations eine eigene Single-Tenant-Anwendung für die Firewall anlegen.
  2. Die delegierten Microsoft-Graph-Berechtigungen User.Read.All und Group.Read.All hinzufügen.
  3. Für Gruppenimport zusätzlich Group.Read.All als Application Permission setzen.
  4. Für die Berechtigungen Admin Consent erteilen.
  5. Unter Certificates & secrets ein Client Secret erzeugen, den Value sofort sicher speichern und das Ablaufdatum überwachen.
  6. Unter App roles beispielsweise sfosAdminReadOnly und nur bei Bedarf sfosAdminFull anlegen.
  7. In der zugehörigen Enterprise Application unter Users and groups den Pilotadministrator oder eine kontrollierte Pilotgruppe der passenden Rolle zuweisen.
  8. Bei einer dedizierten WebAdmin-App Assignment required als zusätzliche Zugriffskontrolle aktivieren und nur die vorgesehenen Pilotadministratoren oder Admin-Gruppen zuweisen. Das ist eine Avanet-Sicherheitsempfehlung, keine technische SFOS-Pflicht.

Statt App-Rollen können dedizierte Security-Gruppen wie SFOS-FW01-WebAdmin-Full und SFOS-FW01-WebAdmin-ReadOnly verwendet werden. Allgemeine IT- oder Microsoft-365-Gruppen sind für Firewall-Administratorrechte zu breit und erschweren spätere Reviews.

MFA wird bei diesem Login im Identity Provider durchgesetzt. Die Sophos-Firewall-MFA lässt sich nicht zusätzlich auf denselben Entra-SSO-Flow legen. Conditional Access sollte deshalb gezielt für die Firewall-Anwendung getestet werden, nicht nur allgemein für Microsoft 365. Die Unterschiede zu Sophos OTP erklärt MFA für Sophos Firewall.

SFOS 22: Entra-ID-Server auf der Firewall konfigurieren

Unter Authentication > Servers wird ein bestehender Microsoft-Entra-ID-Server geöffnet oder mit Add > Microsoft Entra ID SSO neu angelegt.

Server und Redirect URI einrichten

  1. Einen eindeutigen Server name eintragen.
  2. Application (client) ID aus der App Registration einfügen.
  3. Directory (tenant) ID einfügen.
  4. Den zuvor gesicherten Client secret Value eintragen.
  5. Fallback user group bewusst wählen. Sie steuert Benutzerdienste und ersetzt kein Administratorprofil.
  6. Unter Redirect URI den WebAdmin-FQDN prüfen oder manuell setzen.
  7. Die angezeigte Web admin console URL vollständig kopieren.

Die Redirect URI wird nicht aus Hostname, Port und einem vermuteten Callback-Pfad selbst zusammengesetzt. In der Entra-App öffnet man App registrations > Anwendung > Authentication > Add a platform > Web und fügt exakt die von SFOS angezeigte URL ein.

Wird eine einzelne Firewall über Sophos Fusion (ehemals Sophos Central) bearbeitet, muss der Firewall-Hostname manuell gesetzt werden. Die automatisch angezeigte Central-Reverse-SSO-URL ist nicht die WebAdmin-Redirect-URI der Appliance.

Danach Test connection ausführen. Der Test prüft Netzwerkverbindung, App-Berechtigungen und TLS-Zertifikatsvalidierung. Solange er fehlschlägt, wird die Administrator-Authentifizierung nicht umgestellt.

Rollen oder Gruppen auf Profile abbilden

  1. User type auf Administrator setzen. Die Einstellung User aktiviert nur Benutzerdienste und reicht für WebAdmin nicht.
  2. Unter Role mapping den Identifier type wählen:
    • Roles für den exakten App-Role-Value, beispielsweise sfosAdminReadOnly;
    • Groups für den exakten Entra-Gruppennamen.
  3. Unter Value den unveränderten Rollenwert oder Gruppennamen eintragen.
  4. Unter Profile das lokale Profil auswählen, beispielsweise Entra-WebAdmin-ReadOnly.
  5. Weitere Mappings hinzufügen und die Reihenfolge bewusst prüfen.
  6. Speichern.

Die Zuordnungen werden von oben nach unten ausgewertet; der erste Treffer gilt. sfosAdminFull und sfosAdminReadOnly müssen deshalb gegenseitig ausschliessende Mitgliedschaften besitzen. Bei einer Doppelmitgliedschaft wird zuerst die Entra-Zuweisung korrigiert und der Pilot erneut getestet, statt die Reihenfolge als Berechtigungsregel zu verwenden. Die Listenreihenfolge bleibt trotzdem zu dokumentieren, weil sie bei jedem unerwarteten Mehrfachtreffer das wirksame Profil bestimmt.

Entra SSO für Administratoren aktivieren

Der Entra-ID-Server ist erst dann eine WebAdmin-Anmeldemethode, wenn er dem Administrator-Dienst zugeordnet wurde:

  1. Authentication > Services öffnen.
  2. Zu Administrator authentication methods wechseln.
  3. Den Microsoft-Entra-ID-Server auswählen.
  4. Den Server in der Liste nach oben verschieben.
  5. Die bestehende lokale Authentifizierung als bewussten Fallback für lokale Administratoren beibehalten.
  6. Apply wählen.

Pro Authentifizierungsmethode kann nur ein Microsoft-Entra-ID-Server ausgewählt werden. Die Einstellungen unter Administrator authentication methods gelten nicht für den Default-Super-Administrator admin. Dieses Konto bleibt daher ein lokaler Notzugang und wird nicht durch ein Entra-Rollenmapping ersetzt.

Lockout-sicher zurückrollen

Schlägt der Pilotlogin, der Profiltest oder der lokale Fallback fehl, wird nicht weiter ausgerollt:

  1. Die bereits offene lokale Admin-Sitzung verwenden; nicht abmelden und nicht auf die fehlerhafte SSO-Sitzung wechseln.
  2. Unter Authentication > Services > Administrator authentication methods den Entra-Server wieder entfernen.
  3. Apply wählen und den lokalen admin in einem neuen privaten Browserfenster aus dem Managementnetz testen.
  4. Erst wenn dieser Login und die erwarteten Rechte funktionieren, die alte Sitzung schliessen. Das Entra-Serverobjekt bleibt für die Fehleranalyse erhalten und wird nicht unter Zeitdruck gelöscht.

Anmelden und Rechte sicher testen

Ein erfolgreicher Entra-Dialog allein ist noch kein bestandener Test. Die Firewall muss das richtige Profil anwenden, einen nicht berechtigten Benutzer ablehnen und weiterhin einen lokalen Rückweg bieten.

Positivtest mit Pilotadministratoren

  1. Die bisherige lokale Admin-Sitzung geöffnet lassen.
  2. In einem privaten Browserfenster den dokumentierten WebAdmin-FQDN aufrufen.
  3. Mit dem Read-only-Pilotadministrator über Entra ID anmelden.
  4. Entra-MFA und Conditional Access wie geplant durchlaufen.
  5. Prüfen, ob nur die freigegebenen Menüs sichtbar sind und Schreibaktionen tatsächlich fehlen.
  6. Unter Authentication > Users kontrollieren, ob das Konto als Administrator mit dem erwarteten Profil angelegt wurde.
  7. Falls Full Access benötigt wird, einen getrennten Pilotadmin mit der Full-Access-Rolle testen.

Der Full-Access-Test wird nicht mit demselben Konto durchgeführt, das gleichzeitig Read-only erhalten soll. Zwei eindeutige Testkonten machen sichtbar, ob Rollen, Mapping-Reihenfolge und lokale Profile wirklich getrennt funktionieren.

Negativ- und Fallback-Test

  • Bei aktiviertem Assignment required darf ein der Enterprise Application nicht zugewiesener Benutzer den SSO-Flow nicht erfolgreich abschliessen.
  • Ein zugewiesener, aber nicht gemappter Benutzer darf keinen WebAdmin-Zugang erhalten.
  • Ein Read-only-Administrator darf keine Konfigurationsänderung speichern.
  • Der lokale admin muss aus dem vorgesehenen Managementnetz weiterhin funktionieren.
  • Ein Zugriff aus einem nicht erlaubten Netz muss bereits an Device Access oder Local Service ACL scheitern.

Erhält der Negativtest Zugriff, stimmt die Zuweisung, Gruppenmitgliedschaft oder Mapping-Reihenfolge nicht. Dann bleibt die Pilotphase gestoppt; die Berechtigung wird nicht durch eine noch breitere Rolle oder WAN-Freigabe umgangen.

Betrieb, Rechteentzug und HA

Entra SSO verlagert Identität und MFA in den Identity Provider. Die lokal wirksamen Administratorrechte müssen trotzdem auf der Firewall kontrolliert werden.

Rollenänderungen bewusst abschliessen

Wird ein Entra-Benutzer neu zum Firewall-Administrator, übernimmt SFOS die Änderung beim nächsten Login. Die Gegenrichtung funktioniert nicht automatisch: Wird ein Administrator in Entra zum normalen Benutzer herabgestuft, bleibt das lokale Administratorobjekt auf der Firewall zunächst bestehen.

Sicherer Ablauf für eine Herabstufung:

  1. Einen zweiten lokalen Administrator und den Rückweg bestätigen.
  2. Admin-Rolle oder Admin-Gruppe in Entra entfernen beziehungsweise die App-Zuweisung anpassen.
  3. Unter Authentication > Users das betroffene lokale Administratorobjekt kontrolliert löschen.
  4. Nur wenn der Benutzer weiterhin Benutzerdienste verwenden soll, einen neuen Login zulassen. SFOS legt das Konto anhand des aktuellen Tokens als Benutzer neu an.
  5. Neue WebAdmin-Anmeldung negativ testen und bestehende Sitzungen nicht als automatisch beendet voraussetzen.

Soll das Konto gar keinen Firewall-Dienst mehr verwenden, wird es nicht erneut zugewiesen. Gruppenentzug allein sollte nicht als sofortiger Entzug bereits wirksamer lokaler Adminrechte dokumentiert werden.

Secret, Logs und Änderungen überwachen

SFOS 23.0: Der OIDC-Flow wird in /log/oauth_sso_svc.log geprüft, ein TLS-Fehler bei Test connection in /log/sfos-macro-cfg.log. Im Log Viewer verwendet WebAdmin das Admin-Modul. Die folgenden oauth_sso_webadmin.log-Verweise und der lesende Beispielbefehl beziehen sich auf SFOS 22.

  • Client-Secret-Ablaufdatum mit Owner und Vorlauf überwachen.
  • Entra Sign-in Logs nach Anwendung, Benutzer, MFA und Conditional Access prüfen.
  • Auf der Firewall oauth_sso_webadmin.log für den WebAdmin-SSO-Flow verwenden.
  • Administrator-, Profil- und Authentifizierungsänderungen über den Audit Trail nachvollziehen.
  • Admin-Gruppen, App-Rollen und Device-Access-Profile regelmässig gemeinsam reviewen.

In der Advanced Shell zeigt der folgende lesende Befehl die letzten Einträge des WebAdmin-SSO-Dienstes:

tail -n 200 /log/oauth_sso_webadmin.log

Die allgemeine Zuordnung von Logdateien und sicheren Lesewegen steht unter Sophos Firewall Services und Logs.

HA-Grenze einplanen

In einem HA-Cluster funktioniert Entra ID SSO aktuell nicht für den WebAdmin des Auxiliary-Geräts. Direkter Peerzugriff, Recovery und Wartung brauchen deshalb ein lokales Verfahren. Ein Entra-Mapping auf HAProfile hebt diese Produktgrenze nicht auf.

Vor einem HA-Test werden beide Managementpfade, lokale Zugangsdaten und Rollen dokumentiert. Nach einem Rollenwechsel werden Primary-Zugriff, lokale Peer-Verwaltung und SSO erneut getrennt geprüft.

Troubleshooting

Entra-Login funktioniert, WebAdmin verweigert den Zugriff

Dann fehlt meist ein passendes Administrator-Mapping. User type: Administrator, Identifier-Typ, exakten Rollenwert beziehungsweise Gruppennamen und das zugeordnete Profil prüfen. Unter Authentication > Users zeigt ein als normaler Benutzer angelegtes Konto, dass kein Administrator-Mapping getroffen hat.

Administrator erhält das falsche Profil

Role mapping wird von oben nach unten ausgewertet. Gruppenmitgliedschaften und App-Rollen des Kontos kontrollieren, Doppelzuweisungen entfernen und die Reihenfolge mit einem neuen Login erneut testen. Nicht einfach das restriktive Profil breiter berechtigen.

Redirect endet auf einer Fehlerseite

Die Web admin console URL aus der Firewall mit der Redirect URI unter App registrations > Authentication > Web Zeichen für Zeichen vergleichen. FQDN, Port, Pfad, DNS und WebAdmin-Zertifikat gehören zum selben Test. Bei Konfiguration über Central darf die Reverse-SSO-URL nicht verwendet werden.

Test connection scheitert

SFOS 23.0: Nach DNS-, Zeit-, Berechtigungs- und Zertifikatsprüfung zuerst Test connection wiederholen. Nur wenn der Test nach einer korrigierten CA-Kette weiter fehlschlägt und die Unterbrechung der genutzten OIDC-Anmeldedienste akzeptiert ist, wird im Wartungsfenster in der Advanced Shell der gemeinsame Dienst neu gestartet:

service oauth_sso_svc:restart -ds nosync

Danach Test connection, einen neuen WebAdmin-Pilotlogin und alle weiteren verwendeten OIDC-Dienste separat testen. Der gemeinsame Dienst ist nicht auf WebAdmin begrenzt. Der nachfolgende Befehl service oauth_sso_webadmin:restart -ds nosync und die zugehörige dienstspezifische Logdatei gelten für SFOS 22.

Erreichbarkeit von login.microsoftonline.com und graph.microsoft.com, DNS, Systemzeit, Tenant ID, Client ID, Client Secret, Microsoft-Graph-Berechtigungen und Admin Consent prüfen. Ein abgelaufenes Secret wird durch eine neue Redirect URI nicht repariert.

Zeigt oauth_sso_webadmin.log x509: certificate signed by unknown authority, fehlt möglicherweise eine Root- oder Intermediate-CA für die tatsächlich präsentierte Microsoft-Zertifikatskette. Für die reale Sicht der Firewall wird die Kette in deren Advanced Shell gelesen:

openssl s_client -connect login.microsoftonline.com:443 -showcerts

Ein Prüfcomputer kann zum Vergleich dienen, beweist aber nicht, welche Kette die Firewall selbst sieht. Nur eine nachweislich fehlende CA aus vertrauenswürdiger Quelle importieren. Kein Serverzertifikat als CA verwenden und keinen SSO-Dienst als ersten Troubleshooting-Schritt neu starten.

Bleibt Test connection nach der korrigierten CA-Kette erfolglos, ist der von Sophos dokumentierte, node-lokale Neustart des WebAdmin-SSO-Dienstes ein optionaler letzter Schritt im Wartungsfenster:

service oauth_sso_webadmin:restart -ds nosync

Danach werden Test connection und eine neue SSO-Anmeldung wiederholt. Der Neustart ist kein Ersatz für DNS, Uhrzeit, App-Berechtigungen, Admin Consent oder eine vollständige Zertifikatskette.

SSO funktioniert am Primary, aber nicht am Auxiliary

Das ist eine dokumentierte HA-Grenze. Für den Auxiliary-WebAdmin wird ein lokaler, getesteter Zugriff benötigt. Eine neue Entra-Rolle, breitere Device-Access-Freigabe oder andere Redirect URI behebt diese Einschränkung nicht.

Checkliste

  • Lokaler admin, zweiter Administrator und Konsolenzugang funktionieren.
  • WebAdmin ist nur aus vorgesehenen Managementnetzen oder Quellen erreichbar.
  • FQDN, DNS, Zertifikat und Systemzeit passen.
  • App Registration, Berechtigungen, Admin Consent und Secret-Ablauf sind dokumentiert.
  • Bei einer dedizierten WebAdmin-App ist Assignment required aktiviert und nur die Pilot-Admin-Gruppe zugewiesen; bei einer gemeinsam verwendeten App sind alle berechtigten Admin-, VPN- und Portalgruppen erfasst und getestet.
  • Device-Access-Profile enthalten die beabsichtigten Rechte.
  • SFOS 22: User type: Administrator und Role mapping sind korrekt geordnet. SFOS 23: IdP authentication for firewall administrators ist aktiv und IdP attribute, IdP value sowie Device access profile sind geprüft.
  • Exakte Web admin console URL ist als Entra-Redirect-URI eingetragen.
  • Test connection ist erfolgreich.
  • Entra ist unter Administrator authentication methods aktiviert.
  • Read-only-, Full-Access-, Negativ- und lokaler Fallback-Test sind bestanden.
  • Entra Sign-in Logs und die passende Firmware-Logdatei sind geprüft: SFOS 22 oauth_sso_webadmin.log, SFOS 23 oauth_sso_svc.log; im Log Viewer das Admin-Modul.
  • Rollenentzug, Secret-Wechsel und HA-Grenze sind betrieblich dokumentiert.