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.

Versionswahl: Die bisherigen Klickpfade, Feldnamen und dienstspezifischen Logdateien in diesem Artikel beziehen sich auf SFOS 22. Für SFOS 23.0 verwendet man den unten beschriebenen OpenID-Connect-Zweig und die dort genannten Logs. App-Berechtigungen, VPN-Policies, Provisioning, MFA, Pilot- und Rückwegtests bleiben Teil desselben Ablaufs; die Umstellung der Servermaske allein gibt noch keinen VPN-Zugriff. Aus der Verfügbarkeit der SFOS-23-Hilfe wird kein GA-Termin abgeleitet.

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.

Direktes Microsoft Entra ID SSO deckt nicht jeden klassischen Firewall-Login ab. Für User Portal und Client Authentication Agent verweist Sophos auf Microsoft Entra ID Domain Services. Das ist eine separate, AD- beziehungsweise LDAP-kompatible Verzeichnisarchitektur und kein zusätzlicher Schalter am OAuth-/OIDC-Serverobjekt. Wer User Portal oder CAA benötigt, darf deshalb nicht davon ausgehen, dass die hier eingerichtete SSO-Anwendung diese Dienste automatisch authentifiziert.

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.

Ein Entra-ID-Server, mehrere Dienste

Der Microsoft-Entra-ID-Server wird auf der Sophos Firewall einmal unter Authentication > Servers angelegt. Danach kann dasselbe Server-Objekt unter Authentication > Services für unterschiedliche Dienste ausgewählt werden, zum Beispiel VPN Portal, SSL VPN, IPsec Remote Access, Captive Portal oder Administrator-Login.

Das bedeutet nicht, dass jeder Dienst automatisch gleich funktioniert. Jeder Dienst braucht die passende Redirect URI, die richtige Authentication Method und einen eigenen Testpfad. Für VPN Portal, SSL VPN und IPsec Remote Access ist vor allem die VPN portal and remote access URL relevant. Wenn zusätzlich Captive Portal oder WebAdmin über Entra ID SSO verwendet werden, müssen die jeweiligen Service-URLs ebenfalls in der Entra-App hinterlegt und separat getestet werden.

Für den administrativen Dienst gehören zusätzlich Entra-Rollen oder -Gruppen, lokale Berechtigungsprofile und ein getesteter Notfallzugang zusammen. Der eigene Ablauf steht unter Microsoft Entra ID SSO für Sophos Firewall WebAdmin einrichten.

Pro Authentication Method kann nur ein Microsoft-Entra-ID-Server verwendet werden. Bei Sophos Connect Provisioning sollten VPN Portal, SSL VPN und IPsec deshalb bewusst denselben Entra-ID-Server verwenden, damit Gateway-Wert, Redirect URI und Clientprofil zusammenpassen.

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.
• Passende Microsoft-Entra-Lizenzen für die geplanten Conditional-Access-Regeln.
• 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.
• Unter SFOS 22 kann pro Authentifizierungsmethode nur ein Microsoft-Entra-ID-Server ausgewählt werden. Unter SFOS 23 gilt die Grenze für einen OpenID-Connect-IdP-Server, nicht einen Entra-Server zusätzlich zu einem anderen OIDC-Anbieter.
• 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.
• SFOS 22: Microsoft 365 Government Community Cloud High (GCC High) wird für diese SSO-Integration nicht unterstützt. Die SFOS-23-Hilfe führt diese Einschränkung nicht mehr auf; daraus wird hier keine bestätigte GCC-High-Unterstützung abgeleitet. Für einen solchen Tenant muss die Unterstützung vor dem Rollout separat geklärt werden.

⚠️ Conditional Access braucht einen behobenen Firmwarestand: Auf SFOS 21.5 GA Build 171 konnte Sophos Connect eine vorhandene SSO-Sitzung wiederverwenden, ohne MFA und andere Conditional-Access-Bedingungen erneut zu prüfen. Ein Trennen und erneutes Verbinden des VPN-Tunnels reichte nicht zwingend aus. Sophos führt das Problem als NC-167126 und nennt keinen offiziellen Workaround. Behoben ist es ab SFOS 21.5 MR2 Build 323 beziehungsweise SFOS 22.0 MR1 Build 490. Wer Conditional Access als Sicherheitsgrenze nutzt, sollte zuerst mindestens auf einen dieser Stände aktualisieren. Force SSO re-login reduziert das Risiko auf älteren Systemen, ersetzt den Fix aber nicht.

⚠️ Upgrade auf SFOS 22 kann SSO automatisch aktivieren: Standen VPN Portal, Remote Access IPsec oder SSL VPN vor dem Upgrade unter Authentication > Services auf Same as firewall, aktiviert SFOS 22.0 oder neuer Microsoft Entra ID SSO für diese Dienste automatisch. Vor dem Upgrade werden die effektiven Methoden dokumentiert. Ist Entra SSO beabsichtigt, muss danach die exakte VPN portal and remote access URL aus dem Entra-Serverobjekt in der Entra-App hinterlegt und mit einem echten Login geprüft werden. Die Sophos-Central-Reverse-SSO-URL darf dafür nicht verwendet werden. Ist SSO nicht beabsichtigt, wird die gewünschte Methode ausdrücklich gesetzt, statt den geerbten Zustand ungeprüft zu übernehmen.

Architektur planen

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

Wichtige Entscheidungen:

• VPN Portal: Soll die Anmeldung am Portal über Entra ID erfolgen?
• SSL VPN: Soll SSL VPN über Sophos Connect mit Entra SSO genutzt werden?
• IPsec Remote Access: Soll IPsec Remote Access über Sophos Connect mit Entra SSO genutzt werden?
• Provisioning-Datei: Wird eine automatische Provisioning-Datei verwendet?
• Gruppen: Welche Entra-Gruppen dürfen VPN verwenden?
• MFA: Welche Conditional-Access- und MFA-Regeln gelten für Remote Access?
• Fallback: Was passiert, wenn Entra ID oder Internetzugriff zu Microsoft nicht verfügbar ist?

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.

Vor dem Umbau werden der aktuelle Zustand unter Authentication > Services, die Reihenfolge der Server, die VPN-Gruppen und -Policies, Device Access sowie die verteilten Clientprofile dokumentiert. Zusätzlich braucht man einen lokalen Firewall-Administrator, dessen Anmeldung nicht von Entra ID abhängt. Dieser Zugang ist der technische Break-glass-Pfad für Konfigurationsfehler oder einen Ausfall von Microsoft; er wird geschützt, überwacht und regelmässig separat geprüft.

Entra-Anwendung für die Firewall vorbereiten

Sophos empfiehlt eine eigene Anwendung für die Firewall. Das begrenzt Berechtigungen und macht Anmeldeprotokolle, Conditional Access und die Rotation des Secrets eindeutig zuordenbar.

1. In Microsoft Entra zu App registrations > New registration wechseln.
2. Einen eindeutigen Namen vergeben und Accounts in this organizational directory only wählen.
3. Als Plattform Web wählen. Die konkrete Redirect URI wird erst eingetragen, nachdem SFOS sie erzeugt hat.
4. Application (client) ID und Directory (tenant) ID kopieren.
5. Unter API permissions > Microsoft Graph die von Sophos geforderten delegierten Berechtigungen User.Read.All und Group.Read.All hinzufügen. Nur wenn Gruppen mit dem SFOS-Assistenten importiert werden, zusätzlich Group.Read.All als Application permission erteilen. Für alle Berechtigungen ist Admin Consent erforderlich.
6. Unter Certificates & secrets ein Client Secret mit bewusst gewählter Laufzeit erstellen, den Value sofort sicher übernehmen und Ablauf sowie Rotation terminieren.

Unter der zugehörigen Enterprise application > Properties sollte Assignment required? auf Yes stehen. Danach werden nur die vorgesehene Pilot- oder VPN-Gruppe und notwendige Administratoren der Anwendung zugewiesen. Diese Zuweisung ist die erste Zugangsschranke; die SSL-/IPsec-Policy auf der Firewall bleibt eine zweite, unabhängige Berechtigungsprüfung. Microsoft beschreibt die Zuweisung von Benutzern und Gruppen zu Enterprise Applications und die Regeln für Redirect URIs im Detail.

Gruppenbasierte App-Zuweisungen setzen Microsoft Entra ID P1 oder P2 voraus und gelten nicht für Benutzer, die nur über eine verschachtelte Gruppe Mitglied sind. Ohne diese Lizenz oder bei verschachtelten Gruppen weist man die Pilotbenutzer direkt zu; andernfalls fällt bereits der Entra-Login negativ aus, obwohl die VPN-Gruppenmitgliedschaft korrekt aussieht.

Microsoft Entra ID Server auf der Firewall anlegen

SFOS 23.0: OpenID Connect mit Microsoft Entra ID

Unter SFOS 23 wird Entra ID als Anbieter im gemeinsamen OpenID-Connect-Serverobjekt eingerichtet. Die bestehende Entra-App wird weiterhin benötigt; man legt nicht allein wegen der umbenannten Maske eine zweite App an. Vor einer Änderung werden das vorhandene Serverobjekt, seine Dienstzuweisungen und die Redirect URIs dokumentiert. Ein Upgrade ist erst mit einem erneuten Portal- und Tunneltest abgenommen.

1. Authentication > Servers > Add öffnen und unter Server type die Option OpenID Connect wählen.
2. Server name vergeben und IdP vendor: Microsoft Entra ID auswählen.
3. Unter Client ID die Application (client) ID der Entra-App und unter Client secret deren Secret-Value eintragen.
4. Unter OpenID Connect URLs > Issuer URL die Directory (tenant) ID eintragen. Bei diesem Anbieter erwartet das dokumentierte SFOS-Feld die Tenant-ID; man ersetzt sie nicht durch eine selbst zusammengesetzte Issuer-URL. Die anderen URL-Einstellungen gelten nicht für Microsoft Entra ID.
5. Unter Redirect URIs entweder Use firewall URL wählen oder mit Enter manually den vorgesehenen Firewall-FQDN beziehungsweise die IP-Adresse eintragen. Bei Verwaltung einer einzelnen Firewall über Sophos Fusion den Hostnamen manuell setzen; die Reverse-SSO-URL ist kein Appliance-Callback.
6. Show URLs öffnen und die exakte VPN portal and remote access URL als Web-Redirect-URI in der Entra-App hinterlegen. Bei Provisioning muss der gateway-Wert zum hier verwendeten Firewall-FQDN beziehungsweise zur IP passen. Änderungen erfordern den erneuten Import der Clientkonfiguration.
7. Unter User attributes die Vorgaben Display name: name, Username: upn und Email address: email beibehalten. Nur ein tatsächlich anders aufgebautes und unterstütztes Token rechtfertigt abweichende Attribute.
8. IdP authentication for firewall administrators für reine VPN-Benutzerdienste ausgeschaltet lassen und eine eng berechtigte Fallback group wählen. Administrator-Mapping ist ein eigener Schritt im WebAdmin-Artikel.
9. Test connection ausführen, erst bei erfolgreichem Test speichern und unter Authentication > Services dem VPN Portal, SSL VPN und gegebenenfalls IPsec zuordnen. Apply pro Dienst ausführen. SSL VPN und VPN Portal verwenden immer denselben Server; mit Provisioning gilt das zusätzlich für IPsec.

Nach einem Upgrade auch den bestehenden Hinweis zu Same as firewall prüfen: Die automatische Aktivierung für geerbte VPN-Methoden gilt für SFOS 22.0 und neuer, also auch beim entsprechenden Versionswechsel zu SFOS 23. Eine dokumentierte Servermigration ersetzt weder die Prüfung der effektiven Methoden noch den echten Login mit Redirect-, Gruppen-, MFA- und Tunnelkontrolle.

SFOS 22: Microsoft Entra ID SSO

Die folgende Servermaske mit Directory (tenant) ID, User attribute mapping und Fallback user group gehört zu SFOS 22. Für SFOS 23 verwendet man die Felder im vorherigen Zweig.

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 eigens angelegten 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.

Unter User attribute mapping übernimmt SFOS die Benutzerattribute automatisch aus dem Entra-Token. Unter User policies wird eine Fallback user group festgelegt. Diese Gruppe sollte keine breiten VPN-Rechte besitzen: Fehlt eine importierte Entra-Gruppe, landet der Benutzer sonst ausgerechnet im weitreichenden Fallback. Ein enges Gruppenmodell ist sicherer als der Versuch, Zugriff allein über einen Claim oder den erfolgreichen Entra-Login abzuleiten.

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

Ohne Provisioning-Datei müssen SSL VPN und VPN Portal weiterhin denselben Microsoft-Entra-ID-Server verwenden; für Remote Access IPsec darf dann ein anderes Entra-Serverobjekt eingesetzt werden. Mit Provisioning-Datei müssen dagegen VPN Portal, SSL VPN und IPsec auf dasselbe Objekt zeigen. Diese Unterscheidung sollte bewusst dokumentiert und nicht erst aus einem Tenant-Fehler im SSO-Dialog abgeleitet werden.

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 Microsoft Entra Admin Center 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. Für Internetzugänge muss das VPN Portal deshalb unter Administration > Device access in der Zeile WAN erlaubt sein. Weitere Zonen aktiviert man nur, wenn Clients das Portal tatsächlich von dort erreichen müssen.

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.

Treten bereits viele fehlgeschlagene Anmeldungen, verteilte Quellen oder Entra-Kontosperren auf, verbindet VPN-Portal-Brute-Force erkennen und eindämmen die Firewall-Logs mit Entra-Prüfung, sicherer ACL-Eingrenzung und Nachkontrolle.

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:

• Die vollständige Allowlist für Microsoft-Entra-Anmeldungen für FQDN Hosts und Proxy-Ausnahmen verwenden.
• 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.

Bei einem Direct Web Proxy reicht die Allow-Regel zur FQDN Host Group allein nicht. Der verlinkte Allowlist-Artikel enthält die exakten URL-Muster und beschreibt das Vorgehen unter Web > Exceptions. Begrenzen Sie die Ausnahme auf die erforderlichen Login- und CDN-Muster.

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.

Entra-Gruppen gezielt importieren

Für den Gruppenimport benötigt die Firewall in der Entra-App die Microsoft-Graph-Berechtigung Group.Read.All als Application permission sowie den erteilten Admin Consent. Danach wird unter Authentication > Servers beim Entra-Server der Assistant for importing groups geöffnet. Statt ungeprüft alle Gruppen zu importieren, kann der Assistent beispielsweise nach Display name oder Description filtern.

Beim Import lassen sich Surfing quota, Access time, Network traffic und Traffic shaping für alle oder einzelne Gruppen setzen. Diese Policies werden nur vergeben, wenn sie für die Gruppe wirklich benötigt werden. Die Zeit von Firewall und Microsoft Entra ID muss synchron sein, sonst kann bereits der Import scheitern.

Existiert die Entra-Gruppe auf der Firewall, ordnet SFOS den Benutzer dieser Gruppe zu. Fehlt sie, greift die im Entra-Server konfigurierte Fallback user group. Das gilt auch dann, wenn der Entra-Server unter Firewall authentication methods verwendet wird; die dortige Default group ersetzt die Fallback-Gruppe nicht. Nach dem Import muss die neue Gruppe zusätzlich in der jeweiligen IPsec- oder SSL-VPN-Policy freigegeben werden.

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:

• User Principal Name: max.muster@example.com wird oft als eigentlicher Loginname erwartet.
• E-Mail-Adresse: m.muster@example.com kann abweichen und bei Zuordnung oder Portal-Login verwirren.
• Anzeigename: Max Muster ist für Menschen lesbar, aber nicht als technische Kennung geeignet.
• Gruppe: VPN-Users muss auf der Firewall importiert und in der richtigen Remote-Access-Konfiguration verwendet werden.

Bei einer Migration von lokalem Active Directory zu Entra ID ist auch das Anmeldeformat entscheidend. AD verwendet häufig sAMAccountName@domain, Entra ID dagegen UserPrincipalName@domain. SFOS behandelt unterschiedliche Zeichenfolgen als getrennte Benutzerobjekte, selbst wenn sie zur gleichen Person gehören. Das Format sollte deshalb vor der Migration angeglichen werden. Werden bewusst andere Namen verwendet, entstehen Duplikate; alte AD-Benutzer werden erst entfernt, nachdem Regeln, Gruppen, Reporting und der neue Entra-Login geprüft sind.

Der frühere Known Issue NC-157635 führte bei abweichender E-Mail-Adresse und UPN zu fehlgeschlagenen SSL-VPN- oder IPsec-Portal-Logins. Sophos behob ihn mit SFOS 21.0 MR2 Build 349, 21.5 MR1 Build 261 und 22.0 EAP0 Build 274. Die Prüfung der Benutzerattribute bleibt bei Problemen mit einzelnen Konten sinnvoll, damit abweichende lokale Benutzerobjekte oder Gruppenberechtigungen auffallen.

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.

MFA und Conditional Access kontrolliert einführen

Die Conditional-Access-Policy wird auf die Enterprise Application der Firewall begrenzt und zunächst mit Pilotbenutzern beziehungsweise im Report-only-Modus ausgewertet. Eine typische Baseline verlangt MFA und berücksichtigt die von der Organisation erlaubten Standorte oder Gerätezustände. Welche Bedingungen zulässig sind, hängt von Risiko, Lizenz und Betriebsmodell ab; eine pauschale Policy zum Kopieren wäre hier unsicher. Microsoft empfiehlt, Policies vor dem Erzwingen zu planen und im Report-only-Modus zu prüfen.

Mindestens zwei cloudbasierte Entra-Notfallkonten werden nach Microsofts Empfehlung getrennt verwahrt, überwacht und von Conditional Access ausgenommen. Sie ersetzen nicht den lokalen Firewall-Administrator: Wenn Internet, Entra ID oder die App selbst ausfällt, kann nur ein davon unabhängiger Zugang die Firewall-Konfiguration reparieren. Die Konten werden nicht allein für einen Test der VPN-Umgehung der Anwendung zugewiesen. Microsoft beschreibt Aufbau und Überwachung unter Manage emergency access accounts.

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.

macOS separat testen: Für Microsoft Entra ID SSO mit Sophos Connect ab 2.1 auf macOS (nicht 2.0) folgt man dem macOS-Browserablauf. auto beginnt eingebettet und wechselt bei entsprechenden Conditional-Access-Anforderungen zum Systembrowser; embedded hat keinen automatischen Fallback. Die gezielte Wahl von system über eine freigegebene .pro gehört zum Provisioning-Schema, nicht zu manuellen Änderungen an .ovpn oder .scx. Die Anmeldung im vom Client geöffneten Browser einschliesslich MFA vollständig abschliessen, zum Client zurückkehren und Tunnel, DNS und Zugriff prüfen. Ein Browserwechsel umgeht keine Geräte-Compliance: Anforderungen erfüllen oder die IT kontaktieren, Conditional Access nicht abschwächen. Der folgende Windows-Test bleibt auf Sophos Connect 2.4 oder neuer bezogen.

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 und das Ergebnis in den Entra-Anmeldeprotokollen prüfen.
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 den letzten Test im Sophos Connect Client oben rechts das Menü öffnen, Force SSO re-login wählen und mit OK bestätigen. Erst danach muss sich der nächste Benutzer mit den eigenen Entra-Zugangsdaten anmelden. Ein normales Trennen des Tunnels ist nicht dasselbe. Auf gemeinsam genutzten Windows-Geräten gehört dieser Schritt auch mit aktueller Firmware zum sauberen Benutzerwechsel.

Die Ergebnisse werden pro Testfall mit Uhrzeit, Benutzer, VPN-Typ und erwartetem Resultat protokolliert. Im Entra-Anmeldeprotokoll müssen Anwendung, Benutzer, MFA- beziehungsweise Conditional-Access-Ergebnis und Fehlercode zum Versuch passen; SFOS muss denselben Vorgang in oauth_sso_vpn.log beziehungsweise im Authentication-Modul des Log Viewer zeigen. So wird nicht nur ein sichtbarer Tunnel als Beweis gewertet.

Vor dem breiten Rollout gehören mindestens diese Tests in der eigenen Umgebung dazu:

• Zugewiesener Pilotbenutzer meldet sich am VPN Portal an; ein nicht zugewiesener Benutzer wird abgewiesen.
• Je ein tatsächlich eingesetztes SSL-VPN- und/oder IPsec-Profil verbindet über Sophos Connect, erhält die erwartete VPN-IP und erreicht nur freigegebene DNS- und Anwendungsziele.
• MFA und jede geplante Conditional-Access-Bedingung werden mit einem positiven und einem bewusst nicht erfüllten Fall geprüft; das Ergebnis wird in den Entra-Anmeldeprotokollen bestätigt.
• Ein Benutzer ohne erlaubte VPN-Gruppe authentifiziert sich nicht bis zu einem nutzbaren Tunnel beziehungsweise Portalzugang durch.
• Force SSO re-login verlangt auf einem gemeinsam genutzten Windows-Gerät die Identität des nächsten Benutzers.
• Der lokale Break-glass-Administrator kann sich über den dafür vorgesehenen, eingeschränkten Managementpfad anmelden, ohne dass die produktive Entra-Anmeldung verändert wird.

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.

Zustanderhaltender Rollback

Die frühere Authentifizierung wird erst entfernt, wenn Pilot und Rollback erfolgreich geprüft sind. Alte VPN-Konfigurationsdateien bleiben kontrolliert verfügbar und werden weder überschrieben noch an neue Benutzer verteilt.

Falls SSO den Zugang stört, meldet man sich mit dem unabhängigen lokalen Administrator an und stellt unter Authentication > Services für VPN Portal, SSL VPN und IPsec exakt die zuvor dokumentierten Server und deren Reihenfolge wieder her. Für jeden geänderten Dienst wird Apply ausgeführt. Pilotgeräte importieren anschliessend das aufbewahrte alte Profil und prüfen Portal-Login, Tunnelaufbau, DNS und ein freigegebenes internes Ziel.

Die Entra-App, das neue Serverobjekt, importierte Gruppen und das Client Secret werden erst gelöscht, wenn der alte Zugang wieder funktioniert und die Logs dies bestätigen. Wurde Device Access nur für SSO erweitert, wird auch diese Freigabe erst danach auf den dokumentierten Ausgangszustand zurückgesetzt; andernfalls könnte man gleichzeitig den wiederhergestellten VPN-Pfad sperren. Dieser Ablauf erhält beide Konfigurationsstände lange genug für Diagnose und einen zweiten Umstellungsversuch.

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.

Troubleshooting

SFOS 23.0: Für den OIDC-Anmeldefluss verwendet man /log/oauth_sso_svc.log; Fehler bei Test connection mit x509: certificate signed by unknown authority werden in /log/sfos-macro-cfg.log geprüft. Im Log Viewer bleibt für VPN Portal, IPsec und SSL VPN das Authentication-Modul relevant. Die nachfolgenden Verweise auf oauth_sso_vpn.log und der dienstspezifische Neustart gehören zu SFOS 22.

Nach Korrektur einer nachweislich unvollständigen CA-Kette wird zuerst Test connection wiederholt. Nur wenn ein Neustart danach noch erforderlich ist und eine Unterbrechung der verwendeten OIDC-Anmeldedienste im Wartungsfenster akzeptiert ist, lautet der von Sophos für SFOS 23 dokumentierte Advanced-Shell-Befehl:

service oauth_sso_svc:restart -ds nosync

Danach Test connection, einen neuen VPN-Portal-Login und den tatsächlich eingesetzten Tunnel erneut prüfen. Der gemeinsame Dienst ist kein VPN-exklusiver Neustart; auch andere über dieses OIDC-Objekt verwendete Dienste werden separat nachgetestet. Kein Neustart ersetzt DNS-, Zeit-, Berechtigungs- oder CA-Prüfung.

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.

Test connection scheitert mit x509-Fehler

Zeigt oauth_sso_vpn.log den Fehler x509: certificate signed by unknown authority, kann eine Root- oder Intermediate-CA in der Zertifikatskette zu Microsoft Entra ID fehlen. Der Known Issue NC-176806 wurde mit SFOS 22.0 MR2 Build 546 behoben; andere unvollständige Zertifikatsketten oder TLS-Fehler sind weiterhin möglich.

In der Advanced Shell lässt sich die von Microsoft gelieferte Kette prüfen:

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

1. Zertifikatskette und Issuer in der Ausgabe prüfen.
2. Nur die fehlende Root- oder Intermediate-CA aus einer vertrauenswürdigen Quelle beziehen. Kein Serverzertifikat als CA importieren.
3. CA unter Certificates > Certificate Authority hinzufügen und anwenden.
4. Unter Authentication > Servers den Entra-ID-Server öffnen und Test connection erneut ausführen.
5. Nur wenn der Test danach weiterhin scheitert und eine kurze Unterbrechung laufender VPN-SSO-Anmeldungen akzeptiert ist, in der Advanced Shell den VPN-SSO-Dienst neu starten:

service oauth_sso_vpn:restart -ds nosync

Danach Test connection erneut ausführen. Der Service-Neustart ist ein optionaler letzter Schritt, nicht die erste Massnahme bei einem x509-Fehler.

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