SSL-VPN mit Entra-ID-MFA: Remote Access ohne Passwort-Roulette

Sophos SSL-VPN mit MFA über Entra ID — wer das sucht, hat verstanden, was in den Incident-Reports der letzten Jahre auf Seite eins steht: Der VPN-Zugang mit Benutzername und Kennwort ist die Lieblingstür jedes Angreifers, und die Zugangsdaten dazu liegen dank Infostealern und Phishing längst im Umlauf. Die Kurzantwort vorab: Ja, die XGS kann Remote Access mehrfaktorgesichert über Entra ID führen — seit SFOS v21 sogar nativ, mit Browser-Anmeldung im Sophos-Connect-Client, voller Conditional-Access-Unterstützung und ohne separate Token-Lösung; für ältere Firmware bleibt der bewährte Weg über RADIUS und den Microsoft-NPS mit Entra-MFA-Erweiterung, und die XGS-eigene OTP-Funktion deckt Sonderfälle ab. Dieser Artikel sortiert die Bedrohungslage, vergleicht die drei Architektur-Wege, führt durch die Entra-Konfiguration, plant den Rollout so, dass niemand ausgesperrt wird — und zieht am Ende ehrlich die Grenze, ab der ZTNA die bessere Antwort ist.

Bedrohungslage: VPN-Zugänge im Visier

Warum ausgerechnet das VPN? Weil es aus Angreifersicht die perfekte Tür ist: von außen erreichbar (muss es ja sein), mit einem legitimen Protokoll, das keine Malware braucht, und dahinter gleich das ganze Netz statt einer einzelnen Anwendung. Die Zugangsdaten dazu beschafft sich heute niemand mehr mühsam einzeln — Infostealer-Malware erntet auf privaten und dienstlichen Rechnern Kennwörter im industriellen Maßstab, die Ausbeute wird in einschlägigen Märkten sortiert nach Firmennamen gehandelt, und Phishing liefert den Rest. Wer dann mit gültigem Benutzernamen und Kennwort am VPN-Portal ankommt, ist für die Firewall schlicht ein Mitarbeiter im Homeoffice. Kein Exploit, keine Schwachstelle, kein Alarm — Anmelden, Umsehen, Verschlüsseln. Genau so beginnen bemerkenswert viele Ransomware-Fälle im Mittelstand.

Die Gegenmaßnahme ist so unspektakulär wie wirksam: ein zweiter Faktor, der nicht im Infostealer-Dump liegt. Das gestohlene Kennwort allein öffnet dann gar nichts mehr — der Angriff endet an der MFA-Abfrage, und im besten Fall meldet der irritierte Mitarbeiter den unerklärlichen Push auf seinem Handy gleich noch der IT. Die entscheidende Projektfrage ist deshalb nicht ob, sondern womit: Eine separate Token-Lösung bedeutet eine weitere Infrastruktur, weitere Lizenzen und einen weiteren Ort, an dem Benutzer verwaltet werden. Die klügere Antwort nutzt die Identität, die ohnehin schon da ist — Entra ID mit seiner MFA, seinen Richtlinien und seinem Offboarding. Wie die Firewall-Verwaltung selbst an Entra angebunden wird, war Thema des SSO-Artikels; jetzt kommt der Fernzugriff dran.

Architektur-Optionen für MFA am Sophos-VPN

Drei Wege führen zur MFA am Sophos-Remote-Access, und sie unterscheiden sich weniger im Ob als im Wie viel Entra-Welt du mitbekommst. Weg A ist der moderne Standard: die native Entra-ID-Anmeldung für das SSL-VPN, verfügbar ab SFOS v21 mit aktuellem Sophos-Connect-Client. Beim Verbinden öffnet der Client ein Browserfenster, die Anmeldung läuft komplett über login.microsoftonline.com — und damit gilt alles, was dort gilt: die volle MFA-Palette bis hin zu FIDO2-Keys, Conditional Access mit Geräte- und Standortbedingungen, sofort wirksames Offboarding und jede Anmeldung in den Sign-in-Logs. Kein zusätzlicher Server, keine zweite Benutzerverwaltung.

Weg B ist der bewährte Umweg für Umgebungen, die (noch) nicht auf v21 sind: Die XGS authentifiziert VPN-Benutzer per RADIUS gegen einen Windows-Server mit NPS-Rolle, dessen Entra-MFA-Erweiterung nach erfolgreicher Kennwortprüfung den Push in der Authenticator-App auslöst. Das liefert solide MFA, hat aber zwei ehrliche Einschränkungen: Conditional Access greift auf diesem Pfad nicht — die Erweiterung erzwingt MFA, wertet aber keine Richtlinien aus —, und es steht ein zusätzlicher Server im Spiel, der gepflegt und überwacht werden will. Weg C schließlich ist die XGS-eigene zeitbasierte OTP-Funktion: MFA komplett ohne Cloud, Codes aus jeder TOTP-App — die richtige Nische für externe Dienstleister ohne Entra-Konto und für bewusst cloud-freie Sonderfälle, aber ohne die Entra-Vorteile. Die Skizze und die Tabelle stellen die drei Wege nebeneinander; Mischbetrieb ist übrigens ausdrücklich erlaubt und oft die pragmatischste Lösung.

Skizze 1: Drei Wege, ein Ziel — aber nur der native Entra-Weg bringt Conditional Access, FIDO2 und Sign-in-Logs mit.

Konfiguration: Sophos SSL-VPN mit Entra-ID-MFA Schritt für Schritt

Der Aufbau von Weg A gliedert sich in drei Etappen. Etappe eins ist die Entra-Seite, und die kennst du im Prinzip schon aus der Anbindung des WebAdmin: eine App-Registrierung mit Redirect-URI (exakt so, wie die XGS sie im VPN-Kontext anzeigt), Client Secret mit dokumentiertem Ablaufdatum und den Gruppen-Claims als Objekt-ID — die Details samt Stolpersteinen stehen im SSO-Artikel [LINK: B1] und werden hier nicht wiederholt. Neu dazu kommt eine dedizierte Sicherheitsgruppe SG-VPN-Users, die den Kreis der VPN-Berechtigten definiert, sowie — das eigentliche Schmuckstück — eine eigene Conditional-Access-Policy für die VPN-App: MFA verpflichtend, gern in der phishing-resistenten Variante, auf Wunsch ergänzt um die Bedingung, dass nur konforme (Intune-verwaltete) Geräte verbinden dürfen. Damit wird aus dem VPN nebenbei ein Compliance-Gate: Das private Wohnzimmer-Notebook bleibt draußen, auch mit korrektem Kennwort und bestandener MFA.

Etappe zwei ist die XGS: Unter den Authentifizierungs-Einstellungen wird der Entra-Server für den VPN-Dienst aktiviert und in der SSL-VPN-Remote-Access-Richtlinie die berechtigte Gruppe hinterlegt; anschließend erzeugt die Firewall die Provisioning-Datei für Sophos Connect, die neben Gateway und Tunnelparametern auch das neue Anmeldeverhalten transportiert. Etappe drei ist der Client: Sophos Connect in aktueller Version verteilen — bei verwalteten Geräten sauber per Intune samt Provisioning-Datei —, und beim ersten Verbindungsaufbau öffnet sich statt der Kennwortmaske das Microsoft-Anmeldefenster. Teste den kompletten Fluss zuerst mit einem einzelnen Konto und offener Admin-Sitzung: Anmeldung, MFA-Abfrage, Conditional-Access-Bewertung im Sign-in-Log, Tunnelaufbau, Erreichbarkeit der Zielsysteme. Das Sequenzdiagramm zeigt, was dabei unter der Haube passiert — und warum das Kennwort allein nirgendwo mehr hinführt.

Skizze 2: Vom Klick auf »Verbinden« bis zum stehenden Tunnel — die Identitätsprüfung inklusive MFA und Conditional Access liegt komplett bei Entra ID.

Client-Rollout und Benutzerkommunikation

Die Technik ist an einem Tag konfiguriert — über Erfolg oder Ticketflut entscheidet der Rollout. Das bewährte Muster: erst die Pilotgruppe, dann Wellen. Die Pilotgruppe (fünf bis zehn Freiwillige quer durch die Abteilungen, ausdrücklich nicht nur IT) fährt eine Woche im Parallelbetrieb — die neue Entra-Anmeldung aktiv, die alte Methode als Rückfallebene noch vorhanden. In dieser Woche zeigen sich die echten Sonderfälle: der Kollege ohne Diensthandy, die Kollegin mit privatem Gerät ohne Authenticator, der Werksmitarbeiter, dessen Smartphone in der Produktion nicht mit darf. Für genau diese Fälle gehört vorab eine Antwort definiert — FIDO2-Hardware-Keys sind die eleganteste, die XGS-eigene OTP mit beliebiger TOTP-App die pragmatischste; was es nicht geben darf, ist die stillschweigende MFA-Ausnahme.

Die Kommunikation entscheidet über die Ticketzahl, und sie ist erfreulich billig: eine kurze Mail mit zwei Screenshots (»so sieht die neue Anmeldung aus, das ist normal und gewollt«), ein Zweizeiler zur Frage, warum das Ganze (»Ihr Kennwort allein reicht Angreifern heute — uns ab jetzt auch nicht mehr«), und ein klarer Hinweis, an wen man sich wendet. Dazu die organisatorischen Leitplanken: Umstellung nie freitags, Support-Bereitschaft an den ersten beiden Tagen jeder Welle, und ein definiertes Rollback-Fenster je Welle — die alte Authentifizierung wird erst deaktiviert, wenn die Welle stabil läuft, und ganz am Ende komplett abgeschaltet. Die Checkliste fasst den Ablauf zusammen; wer sie abarbeitet, erlebt einen unspektakulären Rollout, und unspektakulär ist hier das höchste Lob.

Abgrenzung: wann ZTNA die bessere Antwort ist

Zum Schluss die ehrliche Einordnung, denn MFA macht das VPN sicherer, aber nicht modern: Ein VPN bleibt architektonisch ein Tunnel ins Netz. Wer verbunden ist, erreicht ein Netzsegment — und damit potenziell auch Systeme, die er gar nicht braucht; die Firewall-Regeln begrenzen den Radius, aber das Grundmodell heißt Netzzugang. Zero Trust Network Access dreht das um: Der Zugriff wird pro Anwendung vermittelt — Identität, Gerätestatus und Richtlinie werden je Verbindung geprüft, der Benutzer erreicht exakt die freigegebene Anwendung, und der Rest des Netzes ist für ihn schlicht unsichtbar. Kein Tunnel, keine Route, nichts zum Scannen. Auf der Sophos-Seite läuft das über das ZTNA-Produkt mit eigenem Per-User-Lizenzmodell, wobei das Gateway kostenfrei auf der XGS mitlaufen kann.

Wann lohnt der Umstieg? Die klaren ZTNA-Kandidaten sind externe Dienstleister (die sollen die Wartungs-Anwendung sehen, nicht das Netz), definierte interne Anwendungsfälle wie der Zugriff auf drei, vier Kernanwendungen aus dem Homeoffice, und BYOD-Szenarien, in denen kein voller Netztunnel aufs Privatgerät gehört. Das MFA-gehärtete VPN behält seine Berechtigung überall dort, wo es um breiten, protokolloffenen Zugriff geht — Admin-Arbeit, Legacy-Protokolle, Sonderfälle, die kein App-Modell abbilden. Die realistische Reise für die meisten Mittelständler: heute das VPN mit Entra-MFA härten (dieser Artikel), parallel die ersten ZTNA-Anwendungsfälle pilotieren, und über zwei, drei Jahre den Schwerpunkt verschieben. Beides läuft problemlos parallel auf derselben XGS. Die Architektur-Skizze zeigt den Unterschied der Modelle; die Tiefe — Lizenzen, Agent, Konfiguration — gehört in den eigenen ZTNA-Artikel [LINK: B3].

Skizze 3: Netzzugang vs. Anwendungszugang — das VPN öffnet ein Segment, ZTNA genau eine App. Beides hat seinen Platz, gern parallel.

FAQ — häufige Fragen zu SSL-VPN und Entra-MFA auf der Sophos XGS

Kann die Sophos XGS MFA über Entra ID erzwingen?

Ja, auf zwei Wegen. Der moderne: Seit SFOS v21 unterstützt das SSL-VPN die native Entra-ID-Anmeldung — Sophos Connect öffnet beim Verbinden ein Browserfenster, die Anmeldung läuft über login.microsoftonline.com, und damit greifen MFA und Conditional Access in voller Breite; erzwungen wird der zweite Faktor über eine Conditional-Access-Policy für die VPN-App, die MFA verpflichtend macht. Der klassische Weg für ältere Firmware: RADIUS-Authentifizierung gegen einen Windows-NPS mit der Entra-MFA-Erweiterung, die nach der Kennwortprüfung den Authenticator-Push auslöst — MFA ja, Conditional Access allerdings nicht. In beiden Fällen gilt: Die Erzwingung ist erst vollständig, wenn die alte Kennwort-only-Anmeldung abgeschaltet ist. Eine parallel weiterlaufende ungeschützte Anmeldemethode ist die Hintertür, die den ganzen Aufwand entwertet.

Brauchen Benutzer eine zusätzliche App?

In den meisten Fällen nicht — und das ist eines der besten Verkaufsargumente intern: Wer Microsoft 365 nutzt, hat die Microsoft-Authenticator-App typischerweise längst auf dem Handy, und genau die bedient auch die VPN-Anmeldung; für die Benutzer ändert sich nur, dass der vertraute Microsoft-Anmeldedialog jetzt auch beim VPN-Verbinden erscheint. Auf dem Rechner braucht es den Sophos-Connect-Client in aktueller Version — bei verwalteten Geräten verteilt Intune den samt Provisioning-Datei unsichtbar im Hintergrund. Bleiben die Sonderfälle: Für Mitarbeiter ohne Diensthandy (oder ohne Bereitschaft, das private zu nutzen) sind FIDO2-Hardware-Keys die eleganteste Lösung — kleiner USB-Stick statt App, nebenbei phishing-resistent. Und für Externe ohne Entra-Konto tut es die XGS-eigene OTP-Funktion mit einer beliebigen TOTP-App. Für niemanden gibt es einen Grund, ohne zweiten Faktor zu bleiben.

Was ist mit Dienstkonten und Site-to-Site?

Zwei verschiedene Baustellen, beide wichtig. Site-to-Site-Tunnel zwischen Standorten sind vom MFA-Thema gar nicht betroffen: Sie authentifizieren sich über Zertifikate oder Pre-Shared Keys zwischen Geräten, nicht über Benutzerkonten — dort gelten eigene Härtungsregeln (starke PSKs, besser Zertifikate), die im Multi-Site-Artikel [LINK: A1] behandelt werden. Heikler sind Dienstkonten im Remote Access: das Wartungsskript, das sich nachts per gespeichertem Kennwort einwählt, der Monitoring-Kollektor beim Dienstleister. Solche Konten können naturgemäß keinen Push bestätigen — und genau deshalb sind sie als klassische VPN-Benutzer die falsche Konstruktion. Die sauberen Alternativen: ein kleiner Site-to-Site-Tunnel zum Dienstleister mit eng geschnittenen Firewall-Regeln, ZTNA mit Client-Zertifikat für definierte Anwendungszugriffe, oder mindestens ein dediziertes Konto mit IP-Beschränkung, eigenem Netzsegment und Alarmierung. Was nicht geht: die MFA-Ausnahme »weil es ein Skript ist« — das ist der Klassiker unter den späteren Einfallstoren.

Wie verhindere ich Aussperrungen beim Rollout?

Mit Parallelbetrieb, Rückfallebenen und Geduld beim letzten Schalter. Konkret: Die neue Entra-Anmeldung wird zusätzlich zur bestehenden Methode aktiviert, nicht anstelle — die Pilotgruppe und jede Welle fahren erst einmal zweigleisig, und die alte Methode fliegt pro Welle erst raus, wenn die neue nachweislich stabil läuft. Der Admin testet den kompletten Fluss vorab mit einem separaten Konto, während seine eigene Sitzung offen bleibt. Für den Fall der Fälle existieren zwei Netze: das dokumentierte Sonderfall-Angebot (FIDO2-Key, OTP) für alle, bei denen der Standardweg klemmt, und die Erreichbarkeit der Firewall selbst über die Management-Zone samt Break-Glass-Konto — falls die Cloud-Anmeldung großflächig streikt, kommt die IT trotzdem an die Konfiguration. Dazu die Prozessregeln: nie freitags umstellen, Support-Bereitschaft an den ersten Tagen jeder Welle, Rollback je Welle definiert. Wer so vorgeht, erlebt Aussperrungen höchstens als Einzelticket, nie als Flächenbrand.

Ist SSL-VPN oder IPsec besser für MFA?

Für den benutzerbezogenen Remote Access mit Entra-MFA ist das SSL-VPN mit Sophos Connect der Weg der Wahl: Die native Entra-Anmeldung ab SFOS v21 ist genau für diesen Pfad gebaut — Browserfenster, Token, Conditional Access, fertig. IPsec-Remote-Access funktioniert grundsätzlich auch mit Sophos Connect und lässt sich über den RADIUS/NPS-Weg mehrfaktorgesichert betreiben, aber die elegante Browser-Integration mit voller Entra-Funktionalität gehört der SSL-Variante. Praktisch kommt dazu: SSL-VPN über TCP/443 kommt durch praktisch jedes Hotel- und Gäste-WLAN, was für Außendienst und Reisende schlicht robuster ist. Für Site-to-Site zwischen Standorten bleibt IPsec dagegen erste Wahl — dort geht es um Geräte-Authentifizierung, nicht um Benutzer und MFA. Kurzformel: Benutzer-Fernzugriff mit MFA → SSL-VPN; Standortkopplung → IPsec; und beides koexistiert friedlich auf derselben XGS.

Sollte ich gleich auf ZTNA wechseln?

Gleich statt MFA: nein. Zusätzlich und schrittweise: gute Idee. Die Reihenfolge hat einen simplen Grund — die MFA-Härtung des bestehenden VPN ist in zwei bis vier Wochen komplett ausgerollt und schließt sofort die Tür, durch die real angegriffen wird; ein vollständiger ZTNA-Umstieg ist dagegen ein Architekturprojekt mit eigenem Lizenzmodell, Agent-Rollout und App-Inventur, das Monate braucht. In der Zwischenzeit ohne MFA zu bleiben, weil »eh bald ZTNA kommt«, ist die schlechteste aller Optionen. Die empfohlene Reise: erst das VPN mit Entra-MFA absichern, dann ZTNA dort pilotieren, wo es sofort glänzt — externe Dienstleister, definierte App-Zugriffe, BYOD — und den Schwerpunkt über die Zeit verschieben; beides läuft parallel auf derselben XGS, das ZTNA-Gateway sogar ohne Zusatzhardware. Details zu Lizenzen, Architektur und Rollout stehen im eigenen ZTNA-Artikel.

Fazit: Die billigste Tür zuerst schließen

Die Lage ist unbequem klar: VPN-Zugänge mit Kennwort-only sind die meistgenutzte Eintrittstür in mittelständische Netze, und die Kennwörter dazu sind längst im Umlauf — nicht vielleicht, sondern statistisch. Die Antwort ist zum Glück genauso klar: MFA mit der Identität, die schon da ist. Ab SFOS v21 nativ mit voller Entra-Integration samt Conditional Access, davor über den soliden NPS-Weg, und für die Sonderfälle liegt die OTP-Funktion bei. Der technische Aufbau ist ein Tagesprojekt, der Rollout eine Frage von Wellen, Kommunikation und der Disziplin, am Ende wirklich den letzten Schalter umzulegen — und keine einzige »temporäre« Ausnahme zu sammeln. Wer das durchzieht, hat mit überschaubarem Aufwand die einzelne wirksamste Verbesserung seiner Außenhaut umgesetzt. Die Modernisierung Richtung ZTNA kann danach in Ruhe kommen; die offene Tür schließt man zuerst.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Das Fundament dieses Artikels — App-Registrierung, Rollen-Mapping und Break-Glass für die Firewall-Verwaltung — steht im Entra-SSO-Artikel [LINK: B1]. Der architektonische nächste Schritt vom Netz- zum Anwendungszugang ist Thema des ZTNA-Artikels [LINK: B3]. Und wie Site-to-Site-Verbindungen zwischen Standorten sauber gehärtet werden, behandelt der Multi-Site-Artikel [LINK: A1].