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.

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.

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.

Voraussetzungen

Vor der Einrichtung sollten diese Punkte geklärt sein:

• Sophos Firewall mit einer SFOS-Version, die Microsoft Entra ID SSO 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:

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. Danach wird diese App auf der Sophos Firewall als Authentication Server eingetragen.

App Registration in Microsoft Entra ID vorbereiten

In Microsoft Entra ID sollte eine eigene App Registration für die Firewall erstellt werden. Dadurch bleiben Redirect URIs, Berechtigungen und Client Secret sauber getrennt von anderen Applikationen.

Typischer Ablauf:

1. Microsoft Entra admin center öffnen.
2. App registrations > New registration öffnen.
3. Einen sprechenden Namen vergeben, zum Beispiel Sophos-Firewall-Captive-Portal.
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 die benötigten Microsoft Graph Berechtigungen ergänzen, typischerweise User.Read.All und Group.Read.All.
9. Für die Berechtigungen Admin consent erteilen.
10. Falls Assignment required verwendet wird, die erlaubten Benutzer oder Gruppen der Enterprise Application 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.

Entra-ID-Server auf der Sophos Firewall anlegen

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-Captive-Portal.
4. Application (client) ID aus der Entra-App eintragen.
5. Directory (tenant) ID eintragen.
6. Client secret eintragen.
7. Je nach Design Match known users aktivieren, wenn bestehende lokale Benutzer oder Gruppen gemappt werden sollen.
8. Use web authentication for unknown users nur verwenden, wenn unbekannte Benutzer bewusst über eine Fallback-Gruppe behandelt werden sollen.
9. Fallback-Gruppe bewusst setzen und möglichst restriktiv halten.
10. Verbindung testen.
11. Speichern.

Die Fallback-Gruppe sollte keine breite Internet- oder Netzwerkfreigabe erhalten. Sie ist vor allem ein Sicherheitsnetz, damit ein Benutzer nicht unkontrolliert mehr Zugriff erhält als geplant.

⚠️ 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.

Redirect URIs richtig eintragen

In Microsoft Entra ID muss die zur Firewall passende Redirect URI in der App Registration eingetragen sein. Entscheidend ist, dass FQDN, Zertifikat, Port und Pfad exakt zusammenpassen. Kleine Abweichungen bei Hostname, Port, Protokoll oder Slash reichen aus, damit der OAuth/OIDC-Ablauf scheitert.

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:

Für Captive Portal sollte nur die Captive-Portal-Redirect-URI in diesem Ablauf getestet werden. Die VPN-URL gehört zum Remote-Access-Design und wird im separaten Artikel zu Microsoft Entra ID SSO für Sophos Connect und VPN Portal behandelt.

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 für Captive portal 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.

Wenn mehrere Authentifizierungsmethoden parallel aktiv sind, muss klar sein, welcher Server für welche Benutzergruppe zuständig ist. Mischbetrieb aus Entra ID und lokaler AD-Authentifizierung kann funktionieren, erhöht aber den Troubleshooting-Aufwand deutlich. In der Sophos Known Issues List sind Entra-SSO-Fälle dokumentiert, bei denen gemischte Entra- und On-Prem-AD-Sessions zu no permission-ähnlichen Fehlern führen können.

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.

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 Microsoft-Login- und Entra-Endpunkte explizit prüfen. Je nach Tenant, Browser und Microsoft-Loginpfad sind unter anderem diese Domains relevant:

• login.microsoftonline.com
• *.login.microsoftonline.com
• *.microsoftonline.com
• *.msauth.net
• *.msftauth.net
• aadcdn.msauth.net
• aadcdn.msftauth.net
• aadcdn.msftauthimages.net
• graph.microsoft.com

Wenn der Webfilter, ein Proxy oder TLS Inspection vor dem Login greift, sollten diese Ziele nicht unnötig entschlüsselt oder blockiert werden. Die Allow-URL-Sektion der Entra-ID-Dokumentation sollte man bei sehr restriktiven Policies gegenprüfen.

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. Captive-Portal-Login mit Testbenutzer durchführen.
5. Danach echten Nutztraffic auslösen, zum Beispiel HTTPS zu einem erlaubten Ziel.
6. 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.

Primary Group bei Entra Captive Portal beachten

Bei Captive Portal mit Microsoft Entra ID SSO sollte man besonders prüfen, welche Gruppe die Firewall für die spätere Benutzerregel tatsächlich auswertet. Bei Entra-ID-SSO-Benutzern kann Internetzugriff über Captive Portal nur dann funktionieren, wenn die Primary Group des Benutzers in der Firewall-Regel verwendet wird. Sekundäre Gruppen verhalten sich dabei nicht gleich wie bei klassischen On-Prem-AD-Benutzern.

Für die Praxis heisst das: Ein Benutzer kann sich erfolgreich am Captive Portal anmelden und trotzdem nicht die erwartete Regel treffen, wenn die Regel nur auf eine sekundäre Entra-Gruppe zeigt. Dieses Fehlerbild sieht schnell nach Captive-Portal-, OAuth- oder Browserproblem aus, obwohl der Login selbst korrekt war.

Vor einem Rollout sollte man deshalb pro Testbenutzer festhalten:

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.

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.

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.

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

Browser-Cookies löschen und prüfen, ob derselbe Benutzer parallel über Entra ID SSO und lokale AD-Authentifizierung verwendet wird. Wenn Entra und On-Prem-AD für denselben Benutzer gemischt werden, sollte das Authentifizierungsdesign vereinfacht oder zumindest sauber dokumentiert werden.

Login funktioniert, aber die Benutzerregel matched 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.

Bei Entra ID SSO über Captive Portal sollte zusätzlich geprüft werden, ob die Firewall-Regel die Primary Group des Benutzers verwendet. Wenn nur eine sekundäre Gruppe in der Regel steht, kann der Login erfolgreich sein, während der eigentliche Internet- oder Zielzugriff nicht über die erwartete Benutzerregel läuft.

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, Owner 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.
• Bei Captive-Portal-Regeln mit Entra ID SSO ist die Primary Group des Testbenutzers berücksichtigt.
• 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