Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten

Mit Microsoft Entra ID SSO kann die Sophos Firewall Benutzer für das VPN Portal sowie für Remote Access über Sophos Connect gegen Microsoft Entra ID authentifizieren. Für viele Microsoft-365-Umgebungen ist das sinnvoller als getrennte lokale Firewall-Passwörter, weil Identität, Conditional Access und MFA zentral im Identity Provider gesteuert werden.

Der Vorteil ist aber nur dann real, wenn die gesamte Kette sauber geplant ist: Entra-App, Redirect URIs, VPN Portal, Sophos Connect, Authentifizierungsmethoden, Gruppen, Device Access und Clientprofile müssen zusammenpassen. Dieser Artikel beschreibt den praktischen Ablauf für VPN Portal, SSL VPN und IPsec Remote Access mit Sophos Connect.

Für die allgemeine Sophos-Connect-Konfiguration passt zuerst Sophos Connect auf Sophos Firewall konfigurieren. Dieser Artikel ergänzt die Identity- und SSO-spezifischen Schritte.

Was Entra ID SSO auf der Firewall macht

Sophos Firewall integriert Microsoft Entra ID SSO über OAuth 2.0 und OpenID Connect. Die Firewall verwendet Entra ID als Authentifizierungsserver und kann Benutzer für mehrere Dienste anmelden.

Für Remote Access sind vor allem diese Dienste relevant:

• VPN Portal
• SSL VPN über Sophos Connect
• IPsec Remote Access über Sophos Connect

Für Captive Portal gilt ein anderer Ablauf: Dort meldet sich ein Benutzer bereits im lokalen Netz per Browser an, damit benutzerbasierte Regeln greifen. Dieser Fall ist in Microsoft Entra ID SSO für Sophos Firewall Captive Portal einrichten getrennt beschrieben.

Wichtig ist die Abgrenzung: Die Firewall übernimmt weiterhin VPN, Policies, Benutzergruppen-Matching und Zugriff über Firewall-Regeln. Entra ID übernimmt die Identitätsprüfung, SSO und Entra-basierte MFA.

Wann Entra ID SSO sinnvoll ist

Entra ID SSO passt gut, wenn Benutzer ohnehin mit Microsoft 365 arbeiten und die Organisation Conditional Access oder Entra-MFA als zentrale Sicherheitskontrolle nutzt.

Typische Gründe:

• Benutzer sollen keine separaten Firewall-Passwörter pflegen.
• MFA soll über Entra ID statt über Sophos OTP laufen.
• Remote Access soll stärker an Benutzerstatus, Gruppen und Conditional Access gebunden werden.
• Helpdesk und Security-Team sollen Identitätsprozesse zentral in Entra ID betreiben.
• Lokale Firewall-Benutzer sollen reduziert werden.

Nicht jede Umgebung sollte sofort umstellen. Bei kleinen Installationen ohne sauberes Entra-Gruppenmodell kann Sophos-eigene MFA einfacher sein. Für die klassische OTP-Variante passt MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren.

Voraussetzungen und Grenzen

Vor der Einrichtung sollten diese Punkte erfüllt sein:

• Sophos Firewall mit unterstützter SFOS-Version.
• Microsoft Entra Tenant mit Berechtigung, eine App Registration zu erstellen.
• Öffentlicher FQDN für das VPN Portal beziehungsweise den Remote-Access-Zugang.
• Gültiges Zertifikat für den öffentlichen Namen.
• VPN Portal ist über die benötigte Zone erreichbar.
• Sophos Connect 2.4 oder neuer auf Windows, wenn SSO im Client genutzt werden soll.
• Benutzer oder Gruppen sind in Entra ID sauber vorhanden.
• Firewall und Entra ID haben korrekte Uhrzeit.
• Microsoft-Login-URLs sind von den Clients und, je nach Trafficpfad, von der Firewall erreichbar.

Wichtige Einschränkungen:

• Für Sophos Connect SSO nennt Sophos Windows-Endpunkte mit Sophos Connect 2.4 oder neuer.
• Wenn Microsoft Entra ID SSO verwendet wird, nutzt man MFA im Identity Provider. Die Sophos-Firewall-eigene MFA kann für diese Authentifizierungsmethode nicht zusätzlich verwendet werden.
• Pro Authentifizierungsmethode kann nur ein Microsoft-Entra-ID-Server ausgewählt werden.
• Benutzer aus derselben Domain sollten nicht gleichzeitig über AD und Microsoft Entra ID synchronisiert werden.
• In HA-Clustern sollte man aktuell nicht davon ausgehen, dass Microsoft Entra ID SSO für den WebAdmin der Auxiliary Firewall funktioniert.

Architektur planen

Vor der technischen Einrichtung sollte man festlegen, welche Dienste SSO verwenden.

Wenn eine Provisioning-Datei verwendet wird, muss der darin gesetzte gateway-Wert zum FQDN oder zur IP passen, die in der Microsoft-Entra-ID-Konfiguration der Firewall als Redirect URI verwendet wird. Nach Änderungen an Entra ID oder an der Firewall-Konfiguration müssen Benutzer die aktualisierte Konfiguration erneut importieren.

Microsoft Entra ID Server auf der Firewall anlegen

Der Menüpfad lautet:

Authentication > Servers

Vorgehen auf der Firewall:

1. Add öffnen.
2. Als Server type die Option Microsoft Entra ID SSO auswählen.
3. Einen sprechenden Servernamen vergeben.
4. Application (client) ID aus der Entra-App eintragen.
5. Directory (tenant) ID eintragen.
6. Client secret eintragen.
7. Redirect-URI-FQDN prüfen oder manuell setzen.
8. Fallback-Gruppe festlegen.
9. Falls WebAdmin-SSO benötigt wird, Rollen- oder Gruppenmapping auf Administratorprofile planen.
10. Test connection ausführen.
11. Speichern.

Für reine VPN-SSO-Szenarien braucht man kein Administrator-Role-Mapping. Dann sollte der Server als Benutzerdienst geplant werden, nicht als pauschaler Admin-Zugang.

⚠️ Client Secrets sind produktive Zugangsdaten. Ablaufdatum, Rotation, Verantwortlichkeit und Dokumentation sollten vor dem Rollout geklärt sein.

Authentifizierungsmethoden setzen

Nach dem Anlegen des Microsoft-Entra-ID-Servers muss er unter Authentication > Services den passenden Diensten zugeordnet werden.

Für Remote Access sind diese Bereiche relevant:

• VPN portal authentication methods
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods
• SSL VPN authentication methods

Wenn eine Provisioning-Datei verwendet wird, sollte für VPN Portal, IPsec und SSL VPN derselbe Microsoft-Entra-ID-Server verwendet werden. Bei Provisioning-Dateien ist dieselbe Serverauswahl für die Authentifizierungsmethoden wichtig, damit Clientprofil, Portal und Remote-Access-Methode zusammenpassen.

Nach jeder Änderung:

1. Server in der jeweiligen Methode auswählen.
2. Server an die richtige Position ziehen, falls mehrere Server vorhanden sind.
3. Apply pro geändertem Dienst ausführen.
4. Testbenutzer verwenden, bevor die Änderung breit ausgerollt wird.

Redirect URIs in Microsoft Entra ID eintragen

Damit SSO funktioniert, müssen die Firewall-URLs in der Entra-App als Redirect URIs hinterlegt werden.

Vorgehen:

1. Auf der Firewall Authentication > Servers öffnen.
2. Den Microsoft-Entra-ID-Server öffnen.
3. Die benötigten URLs kopieren:
   • Web admin console URL, falls WebAdmin-SSO genutzt wird
   • Captive portal URL, falls Captive Portal genutzt wird
   • VPN portal and remote access URL für VPN Portal, Remote Access IPsec und SSL VPN
4. Im Azure Portal zu Microsoft Entra ID > App registrations wechseln.
5. Die Anwendung für die Sophos Firewall öffnen.
6. Unter Manage > Authentication eine Web-Plattform hinzufügen oder die vorhandene Web-Plattform bearbeiten.
7. Die kopierten Redirect URIs einfügen.
8. Speichern.

Ein häufiger Fehler ist ein anderer Hostname in Clientprofil, Redirect URI, Zertifikat und öffentlichem DNS. Diese Werte sollten vor dem Rollout bewusst abgeglichen werden.

Wenn nicht Remote Access, sondern Captive Portal geschützt wird, sollte zusätzlich der Captive-Portal-spezifische Ablauf geprüft werden: Device Access für die Clientzone, Captive-Portal-Authentifizierungsmethode, Benutzergruppe und späteres Firewall-Regel-Matching.

VPN Portal über Device Access freigeben

Microsoft Entra ID SSO für Remote Access verwendet den Port des VPN Portals zur Kommunikation mit der Firewall. Deshalb muss das VPN Portal unter Administration > Device access für die benötigte Zone erlaubt sein.

Das heisst nicht, dass man das VPN Portal weltweit unüberlegt öffnen sollte. Remote Access ist eine öffentlich erreichbare Angriffsfläche. Für produktive Umgebungen sollte man zusätzlich prüfen:

• gültiges öffentliches Zertifikat
• MFA und Conditional Access in Entra ID
• möglichst enge Länder- oder Quellbegrenzung, wenn realistisch
• Logging und Review der Loginversuche
• klare Deaktivierung nicht mehr benötigter Benutzer

Die Härtung von lokalen Firewall-Diensten ist in Device Access und Local Service ACL auf Sophos Firewall beschrieben.

Microsoft-Login-URLs erlauben

Clients und betroffene Firewall-Pfade müssen Microsoft-Entra-ID-Endpunkte erreichen können. Dazu gehören mehrere Microsoft-Login- und CDN-URLs, zum Beispiel login.microsoftonline.com, login.microsoft.com, *.login.live.com, *.msauth.net und weitere Azure-/Microsoft-Online-Domains.

In restriktiven Umgebungen sollte man nicht erst beim Rollout feststellen, dass Loginseiten, JavaScript oder Token-Endpunkte blockiert werden. Sinnvoll ist:

• Microsoft-URL-Liste aus der aktuellen Sophos- und Microsoft-Dokumentation prüfen.
• FQDN Hosts oder FQDN Host Groups sauber benennen.
• Firewall-Regel für DNS und HTTPS bewusst setzen.
• Bei direktem Web Proxy zusätzlich Web Exceptions prüfen.
• Logging aktivieren, bis die SSO-Anmeldung stabil läuft.

Gruppen und VPN-Berechtigungen prüfen

SSO allein gibt noch keinen VPN-Zugriff. Der Benutzer muss auch in der passenden Remote-Access-Konfiguration erlaubt sein.

Zu prüfen:

• Entra-Gruppe wurde in die Firewall importiert oder wird korrekt gemappt.
• Gruppe ist bei Remote Access IPsec unter Allowed users and groups ausgewählt.
• Gruppe ist bei SSL VPN unter Policy members ausgewählt.
• Firewall-Regeln erlauben Traffic aus der VPN-Zone nur zu den benötigten Zielen.
• Benutzer ist nicht nur authentifiziert, sondern erhält auch die erwartete Policy.

Wenn der Tunnel verbunden ist, aber kein Traffic fliesst, ist häufig nicht SSO die Ursache, sondern Regelwerk, Routing, DNS oder NAT. Für die Analyse passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

UPN, E-Mail und Gruppen-Matching prüfen

Bei Microsoft Entra ID SSO sollte man Benutzeridentität und Gruppen-Matching besonders sauber prüfen. Ein Login kann am Identity Provider erfolgreich sein und auf der Firewall trotzdem falsch zugeordnet werden, wenn UPN, E-Mail-Adresse, importierte Gruppe oder lokale Benutzerkennung nicht zusammenpassen.

Das ist vor allem in Umgebungen relevant, in denen Benutzer historisch unterschiedliche Werte haben:

In der Known-Issues-Liste ist ein Sonderfall dokumentiert, bei dem Azure-AD-Benutzer nicht am SSL-VPN- oder IPsec-Portal anmelden können, wenn E-Mail-Adresse und UPN unterschiedlich sind. Für die Praxis heisst das: Bei Entra-ID-SSO-Problemen sollte man nicht nur Redirect URI und Client Secret prüfen, sondern auch die Benutzerattribute.

Praktischer Prüfablauf:

1. Testbenutzer in Microsoft Entra ID öffnen.
2. UPN und E-Mail-Adresse vergleichen.
3. Prüfen, ob der Benutzer Mitglied der geplanten VPN-Gruppe ist.
4. Auf der Firewall die importierte Gruppe öffnen und kontrollieren, ob der Benutzer dort wie erwartet erscheint.
5. Unter Authentication > Services prüfen, ob der richtige Microsoft-Entra-ID-Server für VPN Portal, SSL VPN und IPsec ausgewählt ist.
6. Testlogin durchführen und Log Viewer sowie oauth_sso_vpn.log prüfen.

Wenn nur einzelne Benutzer betroffen sind, ist ein Attribut- oder Gruppenproblem wahrscheinlicher als ein genereller Entra-ID-Serverfehler. Wenn alle Benutzer betroffen sind, zuerst Tenant ID, Client ID, Client Secret, Redirect URIs, Uhrzeit und Microsoft-Endpunkte prüfen.

Bei Benutzerregeln nach erfolgreichem VPN-Login gilt zusätzlich: Die Firewall-Regel muss den Benutzer oder die Gruppe im tatsächlichen Traffic sehen. Wenn der Tunnel steht, aber die geplante Benutzerregel nicht matched, passt die Analyse aus Sophos Firewall Regel greift nicht: Ursachen prüfen.

Sophos Connect und Provisioning testen

Für Sophos Connect gilt: Nach der Entra-ID-Konfiguration oder nach Änderungen an der SSO-Konfiguration muss die Clientkonfiguration erneut importiert werden.

Testablauf:

1. Aktuellen Sophos Connect Client auf Windows installieren.
2. Passende Provisioning- oder VPN-Konfiguration importieren.
3. Prüfen, ob die SSO-Option im Client sichtbar und anklickbar ist.
4. Mit Entra ID anmelden.
5. MFA oder Conditional Access wie geplant auslösen.
6. Tunnelstatus prüfen.
7. VPN-IP, DNS, interne Ziele und Firewall-Regel-Match prüfen.
8. Auf einem gemeinsam genutzten Gerät einen erzwungenen SSO-Re-Login testen.

Für die Clientinstallation auf Windows passt Sophos Connect Client auf Windows installieren. Für SSL VPN mit Sophos Connect passt zusätzlich Sophos SSL VPN mit Sophos Connect auf Windows einrichten.

Betrieb und Sicherheit

Entra ID SSO verlagert die Login-Sicherheit stärker in den Identity Provider. Das ist gut, wenn Entra ID sauber betrieben wird. Es ist problematisch, wenn Gruppen, Conditional Access oder App Secrets nebenbei gepflegt werden.

Im Betrieb sollten diese Punkte regelmässig geprüft werden:

• App Secret läuft nicht unerwartet ab.
• Entra-Gruppen enthalten nur berechtigte Benutzer.
• Conditional Access gilt für Remote Access.
• Break-Glass- und Fallback-Zugänge sind dokumentiert.
• VPN Portal ist nur so breit erreichbar wie nötig.
• Sophos Connect Versionen sind aktuell.
• Alte Clientprofile werden nach Änderungen aus dem Umlauf genommen.
• Logs werden bei Anmeldeproblemen früh geprüft.

Für die Clientseite sollte zusätzlich ein eigener Updateprozess existieren. Der Artikel Sophos Connect Client Version prüfen und sicher aktualisieren fasst zusammen, welche Windows-, macOS-, SSO-, OTP- und Provisioning-Themen vor einem Rollout geprüft werden sollten.

Mit SFOS 22 MR1 hat Sophos die erneute Bewertung von Conditional-Access-Policies bei wiederverwendeten SSO-Sessions verbessert. Für Umgebungen, die Entra-MFA als Sicherheitsgrenze verwenden, ist das ein wichtiger Grund, die Firewallversion aktuell zu halten.

Troubleshooting

SSO-Button ist im Sophos Connect Client nicht nutzbar

Wenn der Client meldet, dass SSO nicht konfiguriert ist, zuerst die Verbindung zum Microsoft-Entra-ID-Server auf der Firewall testen. Danach unter Authentication > Services prüfen, ob der Entra-ID-Server für SSL VPN beziehungsweise IPsec und VPN Portal korrekt gesetzt ist.

Benutzer darf sich nicht am VPN Portal anmelden

Dann kann SSO grundsätzlich funktionieren, aber die VPN-Berechtigung fehlen. Prüfen, ob die Entra-Gruppe in der Remote-Access-IPsec-Konfiguration unter Allowed users and groups oder bei SSL VPN unter Policy members enthalten ist.

Nur einzelne Benutzer können sich nicht anmelden

Dann zuerst UPN, E-Mail-Adresse, Gruppenmitgliedschaft und importierte Firewall-Gruppe prüfen. Besonders bei Benutzern mit abweichender E-Mail-Adresse, geänderten Namen oder migrierten Konten kann die technische Kennung anders aussehen als erwartet.

Microsoft meldet falschen Tenant oder falsche Application

Dann stimmen oft Authentifizierungsmethoden, Entra-App, Tenant ID oder die Serverauswahl auf der Firewall nicht zusammen. Besonders bei mehreren Entra-ID-Servern muss geprüft werden, ob VPN Portal, SSL VPN und IPsec denselben erwarteten Server verwenden.

Redirect oder Login endet auf Fehlerseite

FQDN, Zertifikat, öffentlicher DNS, Redirect URI und Gateway-Wert der Provisioning-Datei vergleichen. Schon kleine Abweichungen bei Hostname, Port oder Pfad können den OAuth/OIDC-Flow stören.

Gruppenimport funktioniert nicht

Uhrzeit der Firewall, Tenant-Daten, App-Berechtigungen, Client Secret und Erreichbarkeit der Microsoft-Endpunkte prüfen. Wenn vorhandene lokale Gruppen nicht zu Entra-Gruppen passen, muss entschieden werden, ob sie bereinigt, gemappt oder manuell verwaltet werden.

Verbindung steht, aber interne Systeme sind nicht erreichbar

Dann ist die Authentifizierung wahrscheinlich nicht mehr der Hauptfehler. VPN-IP, DNS, Firewall-Regeln, NAT, Routing und Zielsystem prüfen. Im Log Viewer sollte sichtbar sein, welche Regel Traffic aus der VPN-Zone trifft.

Checkliste

• Entra-App mit Client ID, Tenant ID und Client Secret ist dokumentiert.
• Redirect URIs für VPN Portal und Remote Access sind in Entra ID eingetragen.
• Öffentlicher FQDN, Zertifikat und Provisioning-Gateway passen zusammen.
• VPN Portal ist unter Device Access bewusst erlaubt.
• Microsoft-Login-URLs sind erreichbar.
• Authentication Services verwenden den richtigen Entra-ID-Server.
• VPN-Gruppen sind importiert und in SSL/IPsec Policies erlaubt.
• UPN, E-Mail-Adresse und Gruppenmitgliedschaft wurden mit einem Testbenutzer geprüft.
• Sophos Connect 2.4 oder neuer ist auf Windows im Einsatz.
• Clientprofile wurden nach Änderungen neu importiert.
• Entra-MFA und Conditional Access wurden mit Testbenutzer geprüft.
• oauth_sso_vpn.log, Log Viewer und Access-Server-Logs sind für Troubleshooting bekannt.

Häufige Fragen