Entra-ID-Anmeldung an der Sophos XGS: SSO per SAML für Admin- und Benutzerportal

Sophos, Entra ID und SAML-SSO — wer danach sucht, will meistens ein sehr konkretes Ärgernis loswerden: lokale Konten auf der Firewall, die niemand im Blick hat. Die Kurzantwort vorab: Ja, die XGS lässt sich an Entra ID anbinden — per App-Registrierung im Tenant und SSO-Konfiguration auf der Firewall, sodass die Anmeldung an WebAdmin und Benutzerportal über login.microsoftonline.com läuft. Damit gelten MFA und Conditional Access automatisch auch fürs Firewall-Portal, die Rollenzuordnung läuft über Entra-Gruppen, und das Offboarding eines Mitarbeiters wirkt in dem Moment, in dem sein Konto deaktiviert wird — auf der Firewall genauso wie überall sonst. Ein lokales Break-Glass-Konto bleibt trotzdem Pflicht, dazu später mehr. Dieser Artikel erklärt, warum lokale Firewall-Konten ein echtes Risiko sind, wie die Föderation technisch funktioniert, und führt dann Schritt für Schritt durch Entra-Konfiguration, XGS-Einrichtung, Rollen-Mapping und Notfallkonzept.

Warum lokale Firewall-Konten ein Risiko sind

Lokale Konten auf der Firewall sind das Sicherheitsäquivalent zum Schlüssel unter der Fußmatte: bequem, historisch gewachsen — und außerhalb jeder zentralen Kontrolle. Die Probleme im Einzelnen: Erstens das Offboarding. Verlässt ein Administrator das Unternehmen, wird sein Entra-Konto deaktiviert, sein Notebook eingezogen, seine Postfach-Weiterleitung eingerichtet — und sein lokales Firewall-Konto? Das überlebt still und leise, weil es in keinem Offboarding-Prozess auftaucht. Zweitens die MFA-Lücke: Während der M365-Zugang längst mehrfaktorgesichert ist, hängt am WebAdmin — dem mächtigsten Verwaltungszugang im ganzen Netz — oft nur ein Kennwort, im schlimmsten Fall eines, das seit der Erstinstallation gilt und in drei Dokumentationen steht. Drittens die Nachvollziehbarkeit: Ein Sammelkonto namens admin sagt im Log exakt nichts darüber, wer die Regel um 23:40 Uhr geändert hat.

Und viertens die Prüfungsrealität: Wer schon einmal ein ISO-27001-Audit oder eine NIS2-Betroffenheitsprüfung begleitet hat, kennt die Standardfragen — sind alle administrativen Zugänge personalisiert, mehrfaktorgesichert und im zentralen Berechtigungsprozess? Lokale Firewall-Konten beantworten alle drei mit Nein und sind damit ein verlässlicher Findings-Lieferant. Die Anbindung an Entra ID dreht das Bild komplett: Anmeldungen tauchen in den Entra-Sign-in-Logs auf, MFA und Richtlinien greifen zentral, und der Nachweis für den Prüfer ist ein Export statt einer Ausrede. Wie sich Firewall- und M365-Ereignisse dann zu belastbaren Nachweisketten verbinden lassen, vertieft der Artikel zur Audit-Korrelation [LINK: C4].

SAML-Grundlagen in fünf Minuten — und was die XGS wirklich spricht

Bevor wir konfigurieren, das Prinzip — es ist einfacher, als die Abkürzungen klingen. Föderierte Anmeldung heißt: Die Anwendung (hier die XGS) prüft Kennwörter nicht mehr selbst, sondern delegiert die Identitätsfrage an einen zentralen Identitätsdienst (hier Entra ID). Der Ablauf ist immer derselbe Dreisprung: Die Anwendung schickt den Benutzer per Browser-Umleitung zum Identitätsdienst; der prüft Kennwort, MFA und Richtlinien; und stellt bei Erfolg ein signiertes Ticket aus — mit Identität und Gruppenmitgliedschaften als sogenannten Claims —, das der Browser zur Anwendung zurückträgt. Die Anwendung prüft nur noch die Signatur des Tickets und ordnet anhand der Claims die Rechte zu. Kennwörter sieht sie nie.

Jetzt zur Ehrlichkeit im Detail, denn hier stolpert die Begriffswelt gern: SAML ist das klassische Protokoll für diesen Dreisprung, OpenID Connect (OIDC auf OAuth-2.0-Basis) sein modernerer Geschwisterbruder — gleiche Idee, jüngere Technik, Token statt XML-Assertion. Im Sprachgebrauch (und im Suchfeld) läuft beides unter »SAML-SSO«, und praktisch ist der Unterschied für dich als Admin gering: Die XGS bindet sich an Entra ID über die App-Registrierungs-Schiene an, also die OIDC-/OAuth-Welt mit Client-ID, Client Secret und Redirect-URI. Der Dreisprung, die Gruppen-Claims und alle Vorteile — MFA, Conditional Access, sofortiges Offboarding — sind identisch. Das Sequenzdiagramm zeigt den kompletten Anmeldefluss; wer die drei Pfeile verstanden hat, versteht auch jede Fehlermeldung, die später kommt.

Skizze 1: Der Anmelde-Dreisprung — die Firewall delegiert die Identitätsfrage und bekommt ein signiertes Ticket samt Gruppen zurück.

Enterprise-App in Entra ID anlegen

Die Entra-Seite ist in einer Viertelstunde erledigt — wenn man weiß, welche vier Stellschrauben zählen. Du legst im Entra-Portal unter App-Registrierungen eine neue Anwendung an (die zugehörige Enterprise-Anwendung entsteht dabei automatisch); ein sprechender Name wie »Sophos XGS WebAdmin« erspart späteres Rätselraten. Stellschraube eins ist die Redirect-URI: Sie muss exakt der Adresse entsprechen, unter der die XGS erreichbar ist — samt HTTPS, FQDN und WebAdmin-Port. Die XGS zeigt dir die erwartete URI in ihrer SSO-Konfiguration an; kopieren statt abtippen ist hier die halbe Fehlervermeidung, denn die Redirect-URI ist mit Abstand die häufigste Ursache gescheiterter erster Anmeldeversuche. Wichtig auch: Die Firewall künftig immer über genau diesen FQDN aufrufen, nicht über die IP — sonst passt die Rücksprungadresse nicht.

Stellschraube zwei ist das Client Secret: erzeugen, sofort sicher ablegen (es wird nur einmal angezeigt) — und den Ablauf ernst nehmen. Secrets laufen ab; wähle eine bewusste Laufzeit und trage die Erneuerung mit Vorlauf in den Kalender oder ins Monitoring, sonst endet das SSO eines Tages kommentarlos. Stellschraube drei sind die API-Berechtigungen: Microsoft Graph mit User.Read sowie der Berechtigung zum Lesen der Gruppenmitgliedschaften, jeweils mit Admin-Zustimmung für den Tenant. Und Stellschraube vier ist die Token-Konfiguration: Gruppen-Claims aktivieren, und zwar als Sicherheitsgruppen mit ihrer Objekt-ID — denn genau diese IDs wird die XGS später auf Rollen mappen. Notiere dir dabei gleich die Objekt-IDs deiner Firewall-Gruppen; du brauchst sie im übernächsten Kapitel.

Sophos-XGS-Konfiguration Schritt für Schritt: Entra-ID-SSO aktivieren

Auf der Firewall-Seite führt der Weg über die Authentifizierungs-Einstellungen: Dort legst du einen neuen Server vom Typ Entra-ID-SSO an und trägst das Quartett aus der App-Registrierung ein — Verzeichnis-ID (Tenant), Anwendungs-ID (Client), Client Secret und die Redirect-URI, die exakt zur Entra-Seite passen muss. Dazu kommt die Fallback-Benutzergruppe: Sie bestimmt, in welcher lokalen Gruppe Benutzer landen, deren Token keinen gemappten Gruppen-Claim enthält. Wähle hier bewusst eine Gruppe ohne nennenswerte Rechte — die Fallback-Gruppe ist ein Auffangbecken, kein Beförderungsprogramm. Anschließend aktivierst du den neuen Server für die gewünschten Dienste: zuerst für die WebAdmin-Anmeldung, auf Wunsch später auch für Benutzer- und Captive Portal.

Dann der Moment der Wahrheit, und hier bitte diszipliniert vorgehen: Teste die erste Entra-Anmeldung in einem zweiten Browser oder Inkognito-Fenster, während die bestehende Admin-Sitzung offen bleibt — so sperrst du dich bei einem Tippfehler in der Redirect-URI nicht selbst aus. Funktioniert die Anmeldung, siehst du im Login-Dialog der XGS fortan die Entra-Option; die lokale Anmeldung bleibt parallel bestehen. Prüfe im Anschluss dreierlei: Die Anmeldung erscheint in den Entra-Sign-in-Logs (samt MFA-Nachweis), die XGS protokolliert den personalisierten Benutzernamen statt eines Sammelkontos, und die zugewiesene Rolle entspricht der Gruppenmitgliedschaft. Erst wenn alle drei Häkchen sitzen, geht es an den Rückbau der lokalen Konten — und zwar an alle bis auf zwei, dazu gleich mehr im Break-Glass-Kapitel.

Rollenzuordnung über Gruppen-Claims

Jetzt wird aus Anmeldung Berechtigungssteuerung. Die XGS kennt Geräteprofile — vordefinierte wie Administrator und den lesenden Audit Admin, plus beliebige eigene Profile mit maßgeschneiderten Teilrechten. Das Mapping verbindet Entra-Gruppen (über ihre Objekt-ID aus dem Token) mit genau diesen Profilen: Mitglied in SG-FW-Admins wird Administrator, SG-FW-Auditors bekommt das Nur-Lesen-Profil, und für den First-Level-Support lohnt ein eigenes Helpdesk-Profil, das Benutzer entsperren und Live-Logs sehen darf — und sonst nichts. Damit wandert die komplette Berechtigungsverwaltung dorthin, wo sie hingehört: in die Gruppenpflege von Entra ID. Eintritt, Austritt, Rollenwechsel, Rezertifizierung — alles ein Gruppenthema, nichts mehr davon ein Firewall-Thema.

Drei Praxisregeln machen das Mapping wartbar. Erstens: sprechende, dedizierte Gruppen nur für diesen Zweck (SG-FW-…) statt Wiederverwendung irgendeiner Abteilungsgruppe — sonst hat der neue IT-Kollege versehentlich Vollzugriff, weil die Gruppe noch drei andere Jobs erledigt. Zweitens: die Admin-Gruppe radikal klein halten und für die großen Rechte über Privileged Identity Management nachdenken — zeitlich begrenzte Aktivierung statt Dauer-Admin. Drittens: die Fallback-Rolle regelmäßig hinterfragen. Die Skizze zeigt ein bewährtes Drei-Gruppen-Modell samt Fallback, die Claim-Tabelle danach ist deine Abhak-Liste für die Konfiguration.

Skizze 2: Drei dedizierte Gruppen, drei Profile, ein bewusst rechtloser Fallback — mehr Rollenmodell braucht der Mittelstand selten.

Break-Glass-Konzept für den Notfall

So elegant die zentrale Anmeldung ist — sie hat eine Achillesferse, und die heißt Abhängigkeit. Wenn Entra ID nicht erreichbar ist, hilft das schönste SSO nichts: bei einer Cloud-Störung, bei einem abgelaufenen Client Secret, bei einem Tenant-Problem — oder im bittersten Fall ausgerechnet dann, wenn die Internetanbindung tot ist und du auf die Firewall musst, um genau das zu reparieren. Deshalb bleibt ein lokales Break-Glass-Konto Pflicht: ein einziges, personunabhängiges Notfallkonto mit langem Zufallskennwort, das offline verwahrt wird — klassisch im versiegelten Umschlag im Tresor oder in einem vom Entra-SSO unabhängigen Kennwort-Speicher. Dazu gehört Alarmierung: Jede Anmeldung dieses Kontos löst eine Benachrichtigung aus, denn im Normalbetrieb hat es schlicht nicht vorzukommen.

Der Ablauf im Ernstfall gehört genauso definiert wie der danach: Kennwort im Vier-Augen-Prinzip entnehmen, lokal aus der Management-Zone anmelden, Problem beheben — und anschließend das Kennwort rotieren, den Einsatz dokumentieren und die Ursache abstellen (das abgelaufene Secret gehört dann eben ins Monitoring). Und wie jeder Feuerlöscher will auch dieser geprüft sein: Einmal pro Quartal eine Testanmeldung, damit der Notausgang nicht erst im Brandfall als zugestellt auffällt. Die dritte Skizze fasst den Ablauf zusammen. Übrigens der Grund, warum vorhin von zwei verbleibenden lokalen Konten die Rede war: das Break-Glass-Konto — und für Umgebungen mit Sophos-Central-Verwaltung gegebenenfalls ein dokumentiertes technisches Konto; alles andere Lokale darf und soll weg.

Skizze 3: Der geordnete Notausgang — Tresor, Anmeldung mit Alarm, danach Rotation und Ursachenanalyse. Und quartalsweise üben.

Bleibt die Werkstatt: Wenn die SSO-Anmeldung hakt, ist die Ursache fast immer eine aus dieser Tabelle — in absteigender Häufigkeit sortiert:

FAQ — häufige Fragen zur Entra-ID-Anmeldung an der Sophos XGS

Unterstützt die Sophos XGS Entra-ID-Anmeldung?

Ja. Seit SFOS 19.5 lässt sich die WebAdmin-Anmeldung über Entra ID führen, seit SFOS 20 zusätzlich Benutzer- und Captive Portal. Technisch läuft die Anbindung über eine App-Registrierung im Entra-Tenant — Client-ID, Client Secret, Redirect-URI — also über die OIDC-/OAuth-Schiene, die umgangssprachlich meist unter SAML-SSO firmiert; das Prinzip föderierter Anmeldung ist dasselbe. Auf der XGS wird dazu ein Authentifizierungsserver vom Typ Entra-ID-SSO angelegt und für die gewünschten Dienste aktiviert. Der Effekt: Die Anmeldung läuft über login.microsoftonline.com, damit greifen MFA und Conditional Access, die Rollenzuweisung erfolgt über Gruppen-Claims, und jede Anmeldung erscheint personalisiert in den Entra-Sign-in-Logs. Voraussetzung wie immer: aktuelle Firmware und ein kurzer Blick in die Release Notes der eingesetzten Version.

Greift Conditional Access beim Firewall-Login?

Ja — und das ist der eigentliche Hebel der ganzen Übung. Weil die Anmeldung über Entra ID läuft, ist sie für Conditional Access eine Anmeldung wie jede andere: Du kannst für die Firewall-App eine eigene Richtlinie bauen, die phishing-resistente MFA erzwingt, den Zugriff auf die IT-Gruppe beschränkt, konforme Geräte verlangt oder Anmeldungen außerhalb definierter Standorte blockt. Empfehlenswert ist genau das: eine dedizierte, strenge Policy für die Firewall-Verwaltung statt der Firmen-Standardrichtlinie — der WebAdmin darf strenger behandelt werden als das Intranet. Zwei Praxishinweise: Neue Richtlinien zuerst im Report-only-Modus testen, und daran denken, dass das lokale Break-Glass-Konto bewusst außerhalb dieser Welt lebt — es ist der Notausgang, wenn eine Richtlinie oder die Cloud selbst klemmt.

Wie ordne ich Entra-Gruppen XGS-Rollen zu?

Über das Rollen-Mapping der SSO-Konfiguration: Die XGS verknüpft die Objekt-ID einer Entra-Sicherheitsgruppe mit einem Geräteprofil — Administrator, der lesende Audit Admin oder ein selbst gebautes Profil mit Teilrechten. Damit das funktioniert, müssen zwei Dinge stimmen: In der Token-Konfiguration der App-Registrierung sind Gruppen-Claims aktiviert (Sicherheitsgruppen, ausgegeben als Objekt-ID), und auf der XGS ist je Gruppe ein Mapping-Eintrag mit exakt dieser ID hinterlegt. Bewährt hat sich ein Drei-Gruppen-Modell: SG-FW-Admins auf Administrator (klein halten!), SG-FW-Auditors auf das Nur-Lesen-Profil, SG-FW-Helpdesk auf ein eigenes Profil mit Entsperr- und Log-Rechten. Dazu die Fallback-Gruppe bewusst rechtearm wählen — sie fängt alle Token ohne gemappten Claim auf und darf niemals versehentlich das Admin-Auffangbecken sein.

Was passiert, wenn Entra ID nicht erreichbar ist?

Dann scheitert die föderierte Anmeldung — folgerichtig, denn die Identitätsprüfung lebt ja in der Cloud. Die Firewall selbst arbeitet davon unbeeindruckt weiter: Regelwerk, VPN-Tunnel, Filterung — alles läuft; betroffen ist ausschließlich die Anmeldung neuer Verwaltungssitzungen über den Entra-Weg. Genau für diesen Fall existiert das Break-Glass-Konzept: ein lokales Notfallkonto mit offline verwahrtem Kennwort, alarmüberwacht und quartalsweise getestet, mit dem du dich aus der Management-Zone anmeldest, das Problem behebst und anschließend das Kennwort rotierst. Die vier üblichen Auslöser kennst du damit gleich mit: Cloud-Störung, tote Internetanbindung, abgelaufenes Client Secret, Tenant-Problem. Drei davon verhindert gutes Monitoring nicht — aber das Secret-Ablaufdatum gehört zwingend hinein, denn das ist der einzige der vier, der sich exakt terminieren lässt.

Funktioniert SSO auch fürs User-Portal?

Ja, seit SFOS 20 lässt sich neben dem WebAdmin auch die Anmeldung an Benutzer- und Captive Portal über Entra ID führen — derselbe Authentifizierungsserver, nur für zusätzliche Dienste aktiviert. Das ist mehr als Kosmetik: Benutzer melden sich am Portal mit ihrer gewohnten Firmenidentität samt MFA an, etwa um VPN-Konfigurationen zu laden oder Quarantäne-Mails zu verwalten, und das Offboarding wirkt auch hier sofort. Zwei Dinge gehören mitgedacht: Erstens brauchen Portal und WebAdmin saubere Zertifikate auf dem verwendeten FQDN, sonst kollidiert die schöne SSO-Welt mit Browserwarnungen. Zweitens ist die Portal-Anmeldung nicht dasselbe wie die VPN-Authentifizierung selbst — wie du den eigentlichen Remote-Access-Anmeldeweg mit Entra-MFA absicherst, ist ein eigenes Thema mit eigenem Artikel, siehe den Beitrag zum SSL-VPN mit Entra-MFA.

Kann ich lokale Konten komplett abschalten?

Fast — und das »fast« ist wichtig. Ziel ist: keine personengebundenen lokalen Konten mehr; jeder meldet sich über Entra ID an, personalisiert und mehrfaktorgesichert. Was bleibt, sind genau zwei begründete Ausnahmen: das Break-Glass-Notfallkonto — offline verwahrt, alarmiert, getestet — und gegebenenfalls ein dokumentiertes technisches Konto für Sonderfälle wie die Ersteinrichtung. Alles andere darf weg, mit System: erst die Entra-Anmeldung für alle Beteiligten samt Rollen verifizieren, dann Altkonten deaktivieren statt löschen, zwei Wochen auf Nebenwirkungen lauschen, dann endgültig entfernen. Der Lohn: »Zwei lokale Konten, beide begründet, der Rest läuft zentral« ist eine sehr entspannte Audit-Antwort.

Fazit: Die Firewall gehört in die zentrale Identität — mit Notausgang

Lokale Firewall-Konten sind ein Relikt, das weder Sicherheits- noch Prüfungsansprüchen standhält: kein MFA, kein Offboarding, keine Personalisierung. Die Entra-Anbindung der XGS räumt das mit überschaubarem Aufwand auf — eine App-Registrierung, ein SSO-Server, drei Gruppen mit Rollen-Mapping, und plötzlich gelten für den mächtigsten Zugang im Netz dieselben Regeln wie für den Rest der Identitätslandschaft: MFA, Conditional Access, sofort wirksames Offboarding, lückenlose Sign-in-Protokolle. Die beiden Disziplinen, die den Unterschied zwischen Hochglanz und Betriebsreife machen: das Client Secret mit Ablaufdatum im Monitoring — und das Break-Glass-Konto als geprüfter Notausgang. Wer beides ernst nimmt, hat eine Firewall-Verwaltung, die Auditoren freut und Angreifern die einfachste Tür zusperrt: das vergessene Konto von vorgestern.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Wie Entra ID, Conditional Access und die Identitätslandschaft insgesamt zusammenspielen, vertieft der Entra-ID-Pillar [LINK: Entra-ID-Pillar]. Der logische nächste Schritt nach dem Portal-SSO — Remote Access mit Entra-MFA absichern — steht im Artikel zum SSL-VPN [LINK: B2]. Und wie aus den neuen personalisierten Anmeldeprotokollen belastbare Audit-Nachweise über Systemgrenzen hinweg werden, zeigt [LINK: C4].