Microsoft Entra ID SSO für Sophos Firewall Captive Portal einrichten

Mit Microsoft Entra ID SSO für das Captive Portal kann die Sophos Firewall Benutzer per Browser gegen Microsoft Entra ID authentifizieren, bevor benutzerbasierte Firewall-Regeln greifen. Das ist besonders interessant für BYOD-Netze, Gast- oder Partnerzonen, Geräte ohne transparente AD-Erkennung oder Umgebungen, in denen STAS nicht für alle Clients passt.

Wichtig ist die Abgrenzung: Captive Portal ist kein VPN Portal und kein Remote Access. Der Benutzer befindet sich bereits im lokalen oder per WLAN angebundenen Netzwerk und meldet sich im Browser an, damit die Firewall den späteren Traffic einer Benutzeridentität zuordnen kann. Für Remote Access mit Sophos Connect passt der separate Artikel Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten.

Wenn Microsoft Entra ID SSO bereits für VPN Portal oder Sophos Connect eingerichtet ist, muss nicht automatisch ein komplett neues Entra-Design entstehen. Häufig kann dasselbe Microsoft-Entra-ID-Server-Objekt auf der Firewall wiederverwendet werden. Für Captive Portal braucht es aber die passende Captive portal URL als Redirect URI, die Zuordnung unter Authentication > Services und einen eigenen Test der späteren Benutzerregel.

Wann Captive Portal mit Entra ID SSO sinnvoll ist

Captive Portal mit Entra ID SSO ist sinnvoll, wenn Benutzer sich ohnehin mit Microsoft 365 anmelden und die Firewall für bestimmte Netze eine Benutzeridentität braucht.

Typische Einsatzfälle:

• BYOD- oder WLAN-Netze ohne Domänenbeitritt.
• Gäste oder externe Benutzer mit kontrolliertem Zugriff auf wenige Ziele.
• Benutzerbasierte Internetregeln ohne STAS oder SATC.
• Netze, in denen transparente Authentifizierung unzuverlässig ist.
• Übergangsszenarien, in denen lokale AD-Authentifizierung reduziert werden soll.

Für vollständig verwaltete Windows-Clients in einer klassischen Domäne ist Captive Portal nicht automatisch die beste Lösung. Dort können STAS, AD SSO oder andere transparente Verfahren ergonomischer sein, weil Benutzer nicht aktiv ein Browser-Login auslösen müssen. Captive Portal ist dann eher Fallback oder Sonderlösung für nicht verwaltete Geräte.

Captive Portal, VPN Portal und User Portal trennen

Bei Entra ID SSO werden Portalbegriffe schnell vermischt. Für die Konfiguration ist die Trennung entscheidend.

Die Portalrollen unterscheiden sich deutlich:

• Captive Portal: Benutzer im lokalen Netz melden sich per Browser an, damit Regeln mit Benutzeridentität greifen. Der typische Entra-Bezug ist SSO für Browser-Login und Benutzerzuordnung.
• VPN Portal: Remote-Access-Benutzer laden Sophos Connect oder VPN-Konfigurationen. Entra ID SSO ist hier für Remote Access und Portal-Login relevant.
• User Portal: Dieses Portal enthält Benutzerfunktionen wie OTP oder ältere persönliche Optionen. Je nach Umgebung bleibt es weiterhin für Token oder Benutzeroptionen relevant.

Eine allgemeine Portalübersicht steht in Sophos Portale: SophosID, Central, Support und Firewall-Zugänge. Für Captive Portal muss man vor allem prüfen, aus welcher Zone der lokale Firewall-Dienst erreichbar sein darf und welche Firewall-Regel danach den eigentlichen Nutztraffic verarbeitet. Die klassische Einrichtung ohne Microsoft-Sonderpfad erklärt Sophos Firewall Captive Portal einrichten und testen von Device Access und DNS bis zu Benutzerregel und Live users. Für Entra ID SSO kommen anschliessend die App Registration, Redirect URI und OAuth/OIDC-Prüfungen dieses Artikels hinzu.

Voraussetzungen

Vor der Einrichtung sollten diese Punkte geklärt sein:

• Sophos Firewall mit einer SFOS-Version, die Microsoft Entra ID SSO unterstützt.
• Ein kommerzieller Microsoft-Entra-Tenant. Microsoft 365 GCC High wird von Sophos Firewall für diese SSO-Integration nicht unterstützt.
• Microsoft Entra Tenant mit Berechtigung für App Registration, Redirect URIs, API Permissions, Admin Consent und Client Secret.
• FQDN und Zertifikat für das Captive Portal, damit Benutzer keine unnötigen Browserwarnungen sehen.
• Erreichbarkeit der Microsoft-Login-Endpunkte aus dem betroffenen Clientnetz.
• Captive Portal ist unter Administration > Device access für die richtige Zone erlaubt.
• Benutzer oder Gruppen sind in Microsoft Entra ID sauber gepflegt.
• Firewall-Regeln verwenden die erwarteten Benutzer oder Gruppen.
• Ein Testbenutzer und ein Fallback-Zugang sind vorhanden.
• Uhrzeit und NTP auf Firewall und Clients stimmen, weil OAuth/OIDC zeitabhängig ist.
• Wenn in Microsoft Entra ID Assignment required aktiv ist, sind die benötigten Benutzer oder Gruppen der Enterprise Application zugewiesen.

⚠️ Captive Portal ist eine Loginfläche auf der Firewall. Es sollte nur in den Zonen erreichbar sein, in denen es wirklich gebraucht wird. Device Access und Local Service ACL sind hier Sicherheitskontrollen, nicht nur Verbindungseinstellungen.

Für die Härtung lokaler Firewall-Dienste passt Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.

MFA wird bei diesem Design in Microsoft Entra ID umgesetzt, zum Beispiel über Conditional Access. Die lokale MFA der Sophos Firewall ersetzt bei Entra ID SSO nicht den Microsoft-Login-Faktor. Das ist aus Benutzersicht meist besser, weil dieselbe MFA wie bei Microsoft 365 verwendet wird, muss aber im Tenant sauber geplant und getestet werden.

Architektur vor der Einrichtung planen

Vor der technischen Konfiguration sollte man entscheiden, welche Aufgabe Captive Portal konkret lösen soll. Sonst entsteht schnell ein Login, der zwar funktioniert, aber keine passende Firewall-Regel triggert.

Wichtige Designfragen:

• Welche Zone nutzt Captive Portal? Device Access und Regelquelle hängen an der Zone.
• Welche Benutzergruppe darf sich anmelden? Die Entra-Gruppe muss zur späteren Firewall-Regel passen.
• Welche Ziele dürfen nach dem Login erreicht werden? Captive Portal ersetzt keine saubere Segmentierung.
• Wie lange sollen Sessions gültig sein? Zu lange Sessions verwässern Benutzerzuordnung, zu kurze Sessions stören den Betrieb.
• Was passiert bei Entra- oder Internetstörung? Es braucht einen klaren Fallback für kritische Arbeitsplätze.
• Wie wird der Login ausgelöst? Benutzer brauchen eine erreichbare Captive-Portal-URL oder eine saubere Weiterleitung.

Captive Portal sollte nicht als Ersatz für VLANs, Zonen oder minimale Firewall-Regeln verwendet werden. Die Firewall kennt nach dem Login den Benutzer besser, aber die Netzarchitektur muss trotzdem sauber bleiben. Für die Grundlogik von Zonen passt Sophos Firewall Zonen und Interfaces konfigurieren.

Microsoft Entra ID Server anlegen

Die Einrichtung besteht aus zwei Teilen: Zuerst wird in Microsoft Entra ID eine App Registration vorbereitet oder eine bereits bewusst für die Firewall erstellte App erweitert. Danach wird die App auf der Sophos Firewall als Authentication Server eingetragen beziehungsweise ein bestehender Microsoft-Entra-ID-Server um die Captive-Portal-Nutzung ergänzt.

App Registration in Microsoft Entra ID vorbereiten

In Microsoft Entra ID sollte eine eigene App Registration für die Firewall verwendet werden. Dadurch bleiben Redirect URIs, Berechtigungen und Client Secret sauber getrennt von anderen Applikationen. Diese App muss nicht pro Firewall-Dienst neu erstellt werden; sie kann mehrere Service-URLs derselben Firewall enthalten, wenn VPN Portal, Captive Portal oder WebAdmin gemeinsam über Entra ID SSO laufen sollen.

Typischer Ablauf:

1. Microsoft Entra admin center öffnen.
2. App registrations > New registration öffnen.
3. Einen sprechenden Namen vergeben, zum Beispiel Sophos-Firewall-SSO.
4. Als Supported account type in der Regel den eigenen Tenant auswählen.
5. Platform Web verwenden.
6. Application (client) ID und Directory (tenant) ID notieren.
7. Unter Certificates & secrets ein Client Secret erstellen und den Secret Value sofort sicher speichern.
8. Unter API permissions > Microsoft Graph > Delegated permissions User.Read.All und Group.Read.All hinzufügen.
9. Nur wenn Gruppen mit dem Import-Assistenten auf die Firewall übernommen werden sollen, unter Application permissions zusätzlich Group.Read.All hinzufügen.
10. Für diese Berechtigungen Grant admin consent ausführen.
11. Unter Enterprise applications > [Firewall-App] > Properties möglichst Assignment required? auf Yes setzen und danach unter Users and groups nur die erlaubten Benutzer oder Gruppen zuweisen.

Ohne passende API Permissions und Admin Consent kann die Anmeldung zwar bis zum Microsoft-Login kommen, die Firewall kann danach aber Benutzer- oder Gruppendaten nicht korrekt auswerten. In der Praxis wirkt das dann oft wie ein Captive-Portal-Problem, obwohl die Ursache in Microsoft Entra ID liegt. Bleibt Assignment required? auf No, können grundsätzlich alle Tenant-Benutzer eine Anmeldung an den Firewall-Benutzerdiensten versuchen; die eigentliche Autorisierung erfolgt weiterhin über Gruppen, Policies und Regeln auf der Firewall. Die verpflichtende App-Zuweisung verkleinert daher die Loginfläche, ersetzt aber keine restriktive Firewall-Regel.

Die gruppenbasierte App-Zuweisung setzt laut Microsoft Entra ID P1 oder P2 voraus und berücksichtigt keine verschachtelten Gruppen. Wer eine Gruppe zuweist, prüft deshalb mit einem direkten Mitglied und nicht nur mit einem Benutzer aus einer Untergruppe.

Entra-ID-Server auf der Sophos Firewall anlegen oder wiederverwenden

Microsoft beschreibt die Details separat für App Registration, Redirect URIs, App-Zuweisungen und Conditional Access. Diese Seiten sind massgeblich, wenn sich Bezeichnungen oder Tenant-Voraussetzungen im Entra-Portal ändern.

Conditional Access wird gezielt auf die Enterprise Application angewendet und zuerst im Report-only-Modus mit einem Pilotbenutzer ausgewertet. Vor dem Aktivieren prüft man das Ergebnis mit What If und den Entra-Anmeldeprotokollen und schliesst die dokumentierten Emergency-Access-Konten aus. Eine bestehende Firewall-Admin-Sitzung und der bisherige Authentifizierungsweg bleiben offen, bis erlaubter Benutzer, abgewiesener Benutzer und MFA erfolgreich getestet sind; so führt eine falsche Policy nicht zum Lockout.

Der Menüpfad auf der Sophos Firewall lautet:

Authentication > Servers

Grundablauf:

1. Add öffnen.
2. Als Server type die Option Microsoft Entra ID SSO auswählen.
3. Sprechenden Namen vergeben, zum Beispiel Entra-SSO-Firewall.
4. Application (client) ID aus der Entra-App eintragen.
5. Directory (tenant) ID eintragen.
6. Client secret eintragen.
7. Unter Redirect URI den produktiven FQDN oder die IP-Adresse festlegen. Die Firewall erzeugt daraus die Service-URLs, die später unverändert nach Entra ID kopiert werden.
8. Fallback user group bewusst setzen und möglichst restriktiv halten.
9. Test connection ausführen. Der Test prüft Netzwerkerreichbarkeit, Application Permissions und TLS-Zertifikatsvalidierung.
10. Speichern.

Die Fallback-Gruppe greift, wenn die Entra-Gruppe eines Benutzers auf der Firewall nicht vorhanden ist. Sie sollte keine breite Internet- oder Netzwerkfreigabe erhalten und ist weder ein Ausfallzugang noch eine alternative Authentifizierung bei einer Entra-Störung.

⚠️ Client Secrets sind produktive Zugangsdaten. Ablaufdatum, Rotation und Zuständigkeit sollten dokumentiert sein. Ein abgelaufenes Secret wirkt aus Benutzersicht oft wie ein normales Loginproblem, ist aber ein Konfigurations- oder Betriebsproblem.

Für eine unterbrechungsarme Rotation erstellt man vor dem Ablauf ein neues Secret, trägt dessen Value auf der Firewall ein und führt Test connection sowie einen Captive-Portal-Login aus. Das bisherige Secret bleibt bis zu diesen erfolgreichen Prüfungen gültig und dient als Rückweg; erst danach wird es in Entra ID gelöscht. Secret Values gehören nicht in Screenshots, Tickets oder Konfigurationsexporte.

Redirect URIs richtig eintragen

In Microsoft Entra ID muss die von der Firewall ausgegebene Redirect URI unverändert in der App Registration eingetragen sein. Protokoll, Hostname, Port, Pfad und selbst ein abweichender Slash müssen exakt stimmen. Das Portalzertifikat ist kein Teil der URI, muss aber für denselben Hostnamen gültig und auf den Clients vertrauenswürdig sein.

Die Sophos Firewall zeigt die benötigten Service-URLs beim Entra-ID-Server an. Für diesen Artikel ist vor allem die Captive portal URL relevant. Wenn zusätzlich WebAdmin oder Remote Access mit Entra ID SSO verwendet werden, haben diese Dienste eigene URLs:

Die Service-URLs haben unterschiedliche Aufgaben:

• Web admin console URL: Entra ID SSO für die WebAdmin-Konsole.
• Captive portal URL: Entra ID SSO für Captive Portal im lokalen Netz.
• VPN portal and remote access URL: Entra ID SSO für VPN Portal und Sophos Connect.

Wenn derselbe Entra-ID-Server bereits für Remote Access verwendet wird, ergänzt man in der Entra-App die Captive portal URL zusätzlich zu den bestehenden Redirect URIs. Danach sollte Captive Portal trotzdem separat getestet werden, weil Loginpfad, Device Access, Gruppen-Matching und spätere Firewall-Regel andere Fehlerbilder haben als Sophos Connect oder VPN Portal.

Captive Portal Authentication Method setzen

Nach dem Anlegen des Entra-Servers muss die Authentifizierungsmethode für Captive Portal auf den richtigen Server zeigen.

Der relevante Bereich liegt unter:

Authentication > Services

Zu prüfen:

1. Bereich Firewall authentication methods öffnen.
2. Microsoft-Entra-ID-Server hinzufügen oder an die richtige Position ziehen.
3. Andere Authentifizierungsserver nur behalten, wenn sie als bewusstes Fallback dienen.
4. Änderung mit Apply übernehmen.
5. Testlogin mit einem einzelnen Benutzer durchführen.

Sophos Firewall erlaubt pro Authentication Method nur einen Microsoft-Entra-ID-Server. Wer mehrere Tenants oder Entra-Apps parallel betreiben will, kann sie deshalb nicht einfach in derselben Firewall authentication methods-Liste stapeln.

Wenn mehrere Authentifizierungsmethoden parallel aktiv sind, muss klar sein, welcher Server für welche Benutzergruppe zuständig ist. Für denselben Benutzer sollte möglichst nur eine Authentifizierungsquelle verwendet werden. Auf einem von NC-167128 betroffenen Firmwarestand kann die Firewall die Sitzung mit no permission ablehnen, wenn ein Benutzer von Entra ID SSO zur lokalen AD-Anmeldung wechselt und danach einen früheren Entra-Token erneut verwendet. Ein solcher Mischbetrieb ist schwerer zu testen und sollte nur bewusst eingesetzt und dokumentiert werden.

Zusätzlich sollte man unter Authentication > Web authentication prüfen, wie das Captive Portal im Browser geöffnet wird. Für Entra ID SSO ist HTTPS wichtig. Die Option Use insecure HTTP instead of HTTPS sollte nicht aktiviert werden, weil der Entra-OAuth-Ablauf über HTTP nicht sauber unterstützt wird und unnötig unsicher wäre.

Für den Betrieb ist hilfreich:

1. Captive Portal in einem neuen Browserfenster öffnen lassen.
2. Das Captive-Portal-Fenster während der Sitzung geöffnet lassen.
3. Benutzer bewusst über das Captive Portal abmelden lassen, wenn die Zuordnung beendet werden soll.
4. Nach dem Login unter Current activities > Live users prüfen, ob der Benutzer sichtbar ist.

Die automatischen Abmeldeoptionen bei Inaktivität oder beim Schliessen des Browser-Tabs gelten derzeit nicht für Microsoft Entra ID SSO. Auf gemeinsam genutzten Geräten bleibt das Portalfenster deshalb geöffnet, bis sich der Benutzer dort ausdrücklich abgemeldet hat; ein geschlossener Tab wird nicht als belastbarer Sitzungsabschluss gewertet.

Zum Testen kann je nach Interface und Zertifikat auch die Standard-URL https://<Firewall-IP>:8090 helfen. Für den produktiven Betrieb ist ein sauberer FQDN mit passendem Zertifikat deutlich angenehmer.

Device Access und Portal-Erreichbarkeit prüfen

Captive Portal ist ein lokaler Dienst der Firewall. Eine normale Firewall-Regel erlaubt diesen Zugriff nicht allein. Die Erreichbarkeit wird unter Administration > Device access für die jeweilige Zone gesteuert.

Prüfen sollte man:

• Captive Portal ist nur in den benötigten Zonen erlaubt.
• WebAdmin und SSH sind dadurch nicht versehentlich ebenfalls breit erreichbar.
• Zertifikat und FQDN passen zur Benutzer-URL.
• DNS im Clientnetz löst den Portalnamen korrekt auf.
• Local Service ACL Exception Rules sind nur gesetzt, wenn sie wirklich nötig sind.

Wenn Captive Portal aus einem Netz nicht erreichbar ist, sollte man nicht zuerst eine normale Allow-Regel erstellen. Häufig liegt die Ursache bei Device Access, Local Service ACL, DNS, Zertifikat oder falschem Zone-Mapping.

Microsoft-Login und Webfilter berücksichtigen

Der Client muss während des Logins Microsoft-Loginseiten und zugehörige Ressourcen erreichen. In restriktiven Netzen kann der SSO-Flow sonst an einer Stelle abbrechen, die für Benutzer wie ein Firewall- oder Browserfehler aussieht.

Zu prüfen:

• DNS-Auflösung für Microsoft-Login-Domains funktioniert.
• HTTPS zu Microsoft-Login-Endpunkten ist erlaubt.
• Webfilter, TLS Inspection oder Proxy blockieren die Anmeldeseite nicht.
• Uhrzeit auf Firewall und Client ist plausibel.
• Browser-Cookies werden nicht durch eine strenge Richtlinie unbrauchbar gemacht.

In restriktiven Umgebungen sollte man die von Sophos für SFOS 22 dokumentierte Liste vollständig als FQDN-Hosts pflegen und nicht aus einzelnen beobachteten Login-Aufrufen ableiten:

• *.aadcdn.microsoftonline-p.com
• *.login.live.com
• login.microsoftonline.com
• *.login.microsoftonline.com
• *.logincdn.msftauth.net
• *.microsoftonline-p.com
• *.microsoftonline.com
• *.msauth.net
• aadcdn.msftauth.net
• login.microsoft.com
• account.activedirectory.windowsazure.com
• *.aadcdn.msauthimages.net
• *.aadcdn.msftauthimages.net
• *.aadcdn.msftauth.net

Erstellen Sie die Objekte und die Regel in SFOS ausdrücklich wie folgt:

1. Öffnen Sie Hosts and services > FQDN host und wählen Sie Add. Tragen Sie für jeden Eintrag oben einen eindeutigen Name und den aufgeführten Wert unter FQDN ein und speichern Sie ihn.
2. Öffnen Sie Hosts and services > FQDN host group und wählen Sie Add. Tragen Sie einen Name ein, wählen Sie Add new item, nehmen Sie alle in Schritt 1 erstellten FQDN-Hosts als Mitglieder auf und speichern Sie die Gruppe.
3. Öffnen Sie Rules and policies > Firewall rules > IPv4, wählen Sie Add firewall rule > New firewall rule und setzen Sie Action auf Accept. Begrenzen Sie Source zones und Source networks and devices auf das betroffene Clientsegment, setzen Sie Destination zones auf WAN, wählen Sie unter Destination networks die FQDN-Hostgruppe und unter Services ausschließlich DNS und HTTPS. Ordnen Sie die Regel an der erforderlichen Position ein, aktivieren Sie Log firewall traffic und begrenzen Sie Benutzer, Zeitplan, Quelle und Ziel so eng, wie es der Anmeldeablauf zulässt.

Prüfen Sie nach dem Speichern, ob jeder FQDN-Host aktuelle Adressen auflöst und die Gruppe alle 14 Objekte enthält. Starten Sie eine Testanmeldung aus dem eingegrenzten Clientnetz und prüfen Sie, ob der Trefferzähler dieser Regel steigt und ihre Rule ID sowie die Aktion Accept im Log Viewer erscheinen. Bleibt der Zähler bei 0, prüfen Sie Objektauflösung und Mitgliedschaft, Quellzone/-netzwerk, Zielzone, Dienste und Regelreihenfolge, bevor Sie die Regel erweitern. Bei Direct Web Proxy braucht es zusätzlich URL-Regex-Ausnahmen; die FQDN-Liste allein ersetzt diese Proxy-Ausnahmen nicht.

Wenn der Webfilter, ein Proxy oder TLS Inspection vor dem Login greift, sollten diese Ziele nicht unnötig entschlüsselt oder blockiert werden.

Ausnahme für Direct Web Proxy anlegen

Für Direct Web Proxy legt man die passende Ausnahme wie unter Web Exceptions beschrieben an:

1. Web > Exceptions öffnen und Add wählen.
2. Einen aussagekräftigen Namen eintragen und URL pattern matches wählen.
3. Für jedes der folgenden 14 exakten Regex-Muster Search und Add verwenden:

• login\.microsoftonline\.com\.?/
• ^([A-Za-z0-9.-]*\.)?login.live.com\.?/
• aadcdn\.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn\.microsoftonline-p\.com\.?/
• ^([A-Za-z0-9.-]*\.)?login.microsoftonline.com\.?/
• ^([A-Za-z0-9.-]*\.)?logincdn.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msauthimages.net\.?/
• ^([A-Za-z0-9.-]*\.)?msauth\.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msftauthimages.net\.?/
• ^([A-Za-z0-9.-]*\.)?microsoftonline\.com\.?/
• ^([A-Za-z0-9.-]*\.)?microsoftonline-p.com\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?account.activedirectory.windowsazure.com\.?/
• login\.microsoft\.com\.?/

4. Für diese Muster alle Checks und Actions auswählen.
5. Die Ausnahme speichern.

Vergewissern Sie sich, dass die gespeicherte Web Exception aktiviert ist. Prüfen Sie während einer Testanmeldung in den Web-/Proxy-Protokollen, ob die angeforderte Microsoft-URL auf das vorgesehene Muster passt und die Ausnahme angewendet wird. Falls nicht, vergleichen Sie protokollierten Hostnamen und Pfad Zeichen für Zeichen mit dem Regex mit einfachem Backslash und prüfen Sie Geltungsbereich und Reihenfolge der Ausnahme.

Die Ausnahme wird so eng auf die betroffenen Clientnetze und den Entra-Anmeldefluss begrenzt, wie es die Umgebung erlaubt; sie darf keine pauschale Ausnahme für Microsoft-Dienste werden. Beide Richtungen testen: Eine erlaubte Entra-Anmeldung muss funktionieren, während eine nicht passende Microsoft-URL weiterhin die normale Web- und TLS-Policy durchläuft. Wird auch dieser Negativtest ausgenommen, muss der Geltungsbereich vor dem Rollout verkleinert werden.

Wenn Web Protection oder TLS Inspection aktiv ist, sollte der Login mit einem Testbenutzer im Log Viewer beobachtet werden. Manchmal ist nicht Captive Portal selbst das Problem, sondern eine Web-Policy, eine TLS-Ausnahme oder ein Clientnetz, das Microsoft-Endpunkte nicht vollständig erreicht.

Benutzergruppen und Firewall-Regeln testen

Nach erfolgreichem Captive-Portal-Login muss die eigentliche Firewall-Regel den Benutzer oder die Gruppe im Traffic sehen. Das ist der wichtigste Praxistest.

Typischer Ablauf:

1. Benutzer in Microsoft Entra ID prüfen.
2. UPN, E-Mail-Adresse und Gruppenmitgliedschaft vergleichen.
3. Entra-Gruppe auf der Sophos Firewall prüfen.
4. In der Benutzerregel Match known users und Use web authentication for unknown users aktivieren.
5. Captive-Portal-Login mit Testbenutzer durchführen.
6. Danach echten Nutztraffic auslösen, zum Beispiel HTTPS zu einem erlaubten Ziel.
7. Im Log Viewer prüfen, ob Benutzer, Gruppe, Source zone, Source network und Rule ID zur erwarteten Regel passen.

Ein erfolgreicher Browser-Login beweist nur die Authentifizierung. Er beweist nicht, dass die spätere Benutzerregel greift. Wenn der Regelzähler auf 0 bleibt oder im Log Viewer kein Benutzer sichtbar ist, sollte man den Ablauf aus Sophos Firewall Regel greift nicht: Ursachen prüfen verwenden.

Gruppen-Matching und ältere Primary-Group-Einschränkung

Für Benutzerregeln muss die beabsichtigte Entra-Gruppe auf der Firewall vorhanden sein. Nach dem Login sollte man unter Current activities > Live users und im Log Viewer prüfen, welcher Gruppe der Benutzer zugeordnet wurde und welche Rule ID den Traffic verarbeitet.

Auf SFOS 20.0 GA Build 222 gab es dabei eine bekannte Einschränkung: Bei NC-167130 funktionierte der Internetzugriff über eine sekundäre Entra-Gruppe nicht; die Regel musste die Primary Group oder den einzelnen Benutzer enthalten. Sophos führt den Fehler für SFOS 21.5 MR2 Build 323 und SFOS 22.0 MR1 Build 490 als behoben. Auf aktuellen Builds ist die Primary Group deshalb keine allgemeine Designvorgabe mehr.

Vor einem Rollout sollten diese Punkte pro Testbenutzer festgehalten werden:

• Entra-Gruppe: Zielgruppe und Mitgliedschaft sind bekannt.
• Gruppe auf der Sophos Firewall: Die gleiche Gruppe ist importiert oder korrekt gemappt.
• Firewall-Regel: Die beabsichtigte Gruppe ist in der Benutzer- oder Gruppenbedingung enthalten.
• Testtraffic nach Login: Log Viewer zeigt Benutzer, Gruppe, Rule ID und erwartete Aktion.
• Alter betroffener Build: Primary Group oder eine benutzerspezifische Testregel verwenden und das Update einplanen.

Das betrifft Sophos Connect VPN mit Microsoft Entra ID SSO nicht. Für Remote Access sollte deshalb der separate Ablauf für Microsoft Entra ID SSO für Sophos Connect und VPN Portal geprüft werden.

Validierung nach dem Rollout

Für die Abnahme sollte man nicht nur prüfen, ob die Microsoft-Anmeldeseite erscheint.

Für die Abnahme sind diese Tests sinnvoll:

• Captive-Portal-URL aus Clientnetz öffnen: Browser zeigt den erwarteten Entra-Login oder die Sophos-Weiterleitung.
• Login mit erlaubtem Benutzer: Anmeldung ist erfolgreich und der Benutzer erscheint auf der Firewall.
• Login mit nicht erlaubtem Benutzer: Zugriff wird nachvollziehbar verweigert.
• Gruppen-Regeltest: Testbenutzer trifft die erwartete Benutzerregel.
• Nutztraffic nach Login: Die richtige Firewall-Regel greift mit Benutzerbezug.
• Session-Ablauf: Nach Timeout ist eine erneute Anmeldung nötig.
• Microsoft-Login blockiert: Log Viewer oder Web-Logs zeigen einen nachvollziehbaren Grund.
• Fallback-Szenario: Der dokumentierte bisherige Authentifizierungsweg wird getestet; die Fallback user group allein ermöglicht keine Anmeldung bei einer Entra-Störung.

Gerade bei BYOD-Netzen sollte man mit mehreren Browsern und Geräten testen. Private Browsermodi, blockierte Drittanbieter-Cookies, alte gespeicherte Logins oder mehrere Microsoft-Konten auf demselben Gerät können unterschiedliche Ergebnisse liefern.

Sicherer Rückweg

Vor der Umstellung sollte man die Reihenfolge unter Authentication > Services > Firewall authentication methods, die Einstellungen unter Authentication > Web authentication und die betroffenen Firewall-Regeln dokumentieren. Ein Screenshot oder Konfigurationsexport verhindert, dass beim Rückweg ein bereits funktionierender Zustand geraten werden muss.

Wenn der Entra-Login den Betrieb stört, stellt man zuerst die bisherige Authentication Method samt ursprünglicher Position wieder her und setzt nur die beim Rollout geänderten Optionen Match known users und Use web authentication for unknown users auf ihren dokumentierten Ausgangswert zurück. Danach werden ein Login über die bisherige Methode, Current activities > Live users und ein echter Regelmatch geprüft.

Die Entra-App, das Serverobjekt, importierte Gruppen und das Client Secret werden dabei nicht vorschnell gelöscht: Sie können auch von WebAdmin, VPN Portal oder Remote Access genutzt werden. Die Captive portal URL entfernt man aus der App Registration erst, wenn nachweislich kein Dienst und kein weiterer Firewall-Knoten sie verwendet. So bleibt der alte Zustand wiederherstellbar und gemeinsam genutzte SSO-Dienste bleiben intakt.

Troubleshooting

Captive Portal ist nicht erreichbar

Zuerst Administration > Device access für die betroffene Zone prüfen. Danach DNS, Zertifikat, Portal-FQDN, Local Service ACL und Zone-Mapping kontrollieren. Wenn der Zugriff zur Firewall selbst geht, ist eine normale Firewall-Regel nicht der erste Prüfpunkt.

Microsoft-Login startet, kommt aber nicht zurück

Redirect URI, FQDN, Zertifikat und Port vergleichen. In Microsoft Entra ID muss exakt die URL hinterlegt sein, die die Sophos Firewall für Captive Portal verwendet. Auch Proxy- oder TLS-Inspection-Regeln können den Rücksprung stören.

Wenn Microsoft den Fehler AADSTS50011 zeigt, passt die Redirect URI in der App Registration meistens nicht zur URL, welche die Firewall verwendet. Dann müssen Protokoll, FQDN, Port und Pfad exakt verglichen werden.

Nach dem Microsoft-Login erscheint ein interner Fehler

Ein 500 Internal Server Error oder ein ähnlich generischer Fehler nach erfolgreichem Microsoft-Login deutet häufig auf fehlende Microsoft Graph Berechtigungen, fehlenden Admin Consent oder ein Problem mit dem Client Secret hin. Dann sollte man in Microsoft Entra ID die API Permissions, Admin Consent, Secret-Gültigkeit und Enterprise-App-Zuweisung prüfen.

Zeigt oauth_sso_captive.log stattdessen x509: certificate signed by unknown authority, wird zuerst die von der Firewall erreichte Microsoft-Zertifikatskette gelesen und eine nachweislich fehlende Root- oder Intermediate-CA aus vertrauenswürdiger Quelle importiert:

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

Danach wird Test connection erneut ausgeführt. Nur wenn die CA-Kette bereits korrigiert ist und der Fehler bestehen bleibt, ist der von Sophos dokumentierte, node-lokale Neustart des Captive-SSO-Dienstes ein optionaler letzter Schritt im Wartungsfenster:

service oauth_sso_captive:restart -ds nosync

Anschliessend werden Test connection und ein neuer Captive-Portal-Login wiederholt. Ein Dienstneustart ersetzt weder die Zertifikatsprüfung noch einen fehlenden Admin Consent.

Benutzername und Passwort funktionieren nicht direkt

Entra ID SSO ist ein Browser- und OAuth/OIDC-Flow. Benutzer melden sich nicht mit klassischen Credentials direkt an der Firewall an, sondern werden zu Microsoft umgeleitet. Wenn ein Client oder ein Ablauf nur Benutzername und Passwort ohne Browser-Redirect unterstützt, passt diese Methode nicht.

MFA erscheint nicht oder anders als erwartet

Bei Entra ID SSO wird MFA in Microsoft Entra ID gesteuert. Die lokale Firewall-MFA ist für diesen SSO-Flow nicht der richtige Kontrollpunkt. Wenn MFA gefordert ist, sollte man Conditional Access, Benutzergruppen, Ausschlüsse und Testbenutzer in Microsoft Entra ID prüfen.

Benutzer sieht no permission oder wird nach längerem Betrieb abgewiesen

Dieses Fehlerbild passt zu NC-167128 auf SFOS 21.0 GA Build 169: Verwendet derselbe Benutzer zuerst Entra ID SSO, danach im lokalen Netz On-Prem-AD und anschliessend wieder den alten Entra-Token, kann no permission erscheinen. Behoben ist das Problem ab SFOS 21.5 MR2 Build 323 beziehungsweise SFOS 22.0 MR1 Build 490.

Auf dem betroffenen Stand zuerst die Browser-Cookies löschen. Tritt das Problem in Sophos Connect auf, dort Force SSO re-login ausführen; der Bedienpfad steht unter Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten. Dauerhaft ist es sauberer, für denselben Benutzer durchgängig Entra ID oder On-Prem-AD zu verwenden und auf einen behobenen Firmwarestand zu aktualisieren.

Login funktioniert, aber die Benutzerregel greift nicht

Dann ist Captive Portal wahrscheinlich nicht mehr das einzige Problem. Source zone, Source network, Benutzergruppe, Regelposition und Log Viewer prüfen. Häufig liegt eine allgemeinere Regel oberhalb der Benutzerregel oder der Traffic kommt aus einem anderen Netz als erwartet.

Zusätzlich prüfen, ob die beabsichtigte Entra-Gruppe importiert ist und der Benutzer ihr auf der Firewall zugeordnet wurde. Nur auf dem von NC-167130 betroffenen SFOS 20.0 GA Build 222 muss für diesen Fehler die Primary Group oder der einzelne Benutzer in der Regel stehen.

Nur einzelne Benutzer sind betroffen

UPN, E-Mail-Adresse, Anzeigename, Gruppenmitgliedschaft und importierte Gruppe vergleichen. Bei Entra ID SSO sollte man nicht davon ausgehen, dass sichtbarer Name und technische Kennung identisch sind. Wenn E-Mail-Adresse und UPN historisch auseinanderlaufen, entstehen leicht Zuordnungsfehler.

Welche Logs helfen?

Für Captive Portal mit Entra ID SSO ist vor allem oauth_sso_captive.log relevant. Zusätzlich helfen Log Viewer mit dem Modul Authentication, access_server.log und je nach Folgeproblem Web-, Firewall- oder Authentication-Logs. Die Zuordnung der wichtigsten Dateien steht in Sophos Firewall Troubleshooting: Services und Logs.

Checkliste

• Captive-Portal-Anwendungsfall ist klar: BYOD, Gäste, nicht verwaltete Geräte oder Fallback.
• FQDN und Zertifikat für das Captive Portal sind sauber.
• Microsoft-Entra-ID-App mit Redirect URI, Client ID, Tenant ID und Client Secret ist dokumentiert.
• Microsoft Graph API Permissions und Admin Consent sind gesetzt.
• Enterprise-App-Zuweisungen sind geprüft, falls Assignment required aktiv ist.
• Client Secret hat Ablaufdatum, Verantwortlichen und Rotationsprozess.
• Captive-Portal-Redirect-URI wurde von der Firewall übernommen und exakt in Entra ID eingetragen.
• Authentication > Services nutzt für Captive Portal den richtigen Entra-Server.
• Authentication > Web authentication verwendet HTTPS und passende Browserfenster-Einstellungen.
• Administration > Device access erlaubt Captive Portal nur in benötigten Zonen.
• Microsoft-Login-Endpunkte sind aus dem Clientnetz erreichbar.
• Webfilter und TLS Inspection blockieren den SSO-Flow nicht.
• MFA und Conditional Access sind in Microsoft Entra ID geplant und getestet.
• Entra-Gruppe und Firewall-Gruppe passen zusammen.
• Die beabsichtigte Entra-Gruppe ist importiert und wird beim Testbenutzer tatsächlich ausgewertet.
• Testbenutzer kann sich anmelden und danach die erwartete Firewall-Regel treffen.
• Log Viewer zeigt Benutzer, Rule ID und Aktion.
• oauth_sso_captive.log und access_server.log sind für Supportfälle bekannt.
• Fallback für Entra- oder Portalstörung ist dokumentiert.

Häufige Fragen