MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren

Administrative Zugänge und Remote-Access-Portale sollten nicht nur mit Benutzername und Passwort geschützt werden. Mit Multi-Factor Authentication, kurz MFA, verlangt die Sophos Firewall zusätzlich einen zweiten Faktor, zum Beispiel einen zeitbasierten OTP-Code aus einer Authenticator-App.

Für den übergeordneten Hardening-Kontext passt der Hub Sophos Firewall Hardening: Best Practices für eine sichere Konfiguration.

Der Artikel erklärt, wie man MFA sinnvoll plant, aktiviert und testet. Der Fokus liegt auf WebAdmin, VPN Portal und Remote Access.

Einordnung und Zugriffsschutz

MFA ist ein wichtiger Schutz für Anmeldungen, aber nur ein Baustein. Zuerst sollte klar sein, welcher Zugang geschützt wird, welche Identitätsquelle dahintersteht und ob der Dienst überhaupt aus dem jeweiligen Netz erreichbar sein muss.

Welcher Authentifizierungs-Artikel passt?

MFA ist nur ein Teil der Zugriffssicherheit. Je nach Ziel geht es zuerst um Erreichbarkeit, Identitätsquelle, Portal, VPN-Client oder veröffentlichte Webanwendung:

• MFA für WebAdmin, VPN Portal oder Remote Access planen: Dieser Artikel.
• WebAdmin, SSH, User Portal, VPN Portal, DNS oder Ping erreichbar einschränken: Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.
• Microsoft Entra ID SSO für Sophos Connect oder VPN Portal nutzen: Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten.
• Sophos Connect, SSL VPN, IPsec oder ZTNA als Remote-Access-Modell vergleichen: Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt?.
• Sophos Connect Clientversion, OTP-Reconnects oder SSO-Provisioning prüfen: Sophos Connect Client Version prüfen und sicher aktualisieren.
• WAF-veröffentlichte Webanwendung mit MFA absichern: Sophos Firewall WAF mit MFA absichern.
• Klassisches Active Directory als Benutzerquelle anbinden: Active Directory auf Sophos Firewall hinzufügen.
• Supportzugriff für Avanet oder Sophos kontrolliert vorbereiten: Einrichtung des Avanet Support-Zugriffs auf Sophos Firewall.
• Health-Check-Findings zu MFA oder Portalzugriff priorisieren: Sophos Firewall Health Check richtig nutzen.

Diese Trennung ist wichtig: MFA schützt Anmeldungen, aber sie begrenzt nicht automatisch, aus welchen Netzen WebAdmin, SSH oder Portale erreichbar sind. Umgekehrt ersetzt eine enge Device-Access-Regel keinen zweiten Faktor. Gute Zugriffssicherheit kombiniert Erreichbarkeit, Identitätsquelle, MFA, Logging und einen getesteten Fallback-Zugang.

Wann MFA sinnvoll ist

MFA sollte mindestens für alle Konten aktiviert werden, die auf administrative Oberflächen oder Remote-Access-Funktionen zugreifen dürfen.

Typische Einsatzbereiche:

• Anmeldung am WebAdmin.
• Anmeldung am VPN Portal.
• SSL VPN oder Sophos Connect Remote Access.
• Zugriff für externe Dienstleister.
• Zugriff für privilegierte Administratoren.

MFA reduziert das Risiko gestohlener Passwörter, ersetzt aber keine saubere Zugriffsbeschränkung. SSH, WebAdmin und Portale sollten weiterhin nur aus vertrauenswürdigen Netzen oder über klar definierte Management-Zugriffe erreichbar sein.

MFA ist kein Ersatz für Device Access

MFA schützt den Anmeldevorgang. Die Angriffsfläche eines Dienstes reduziert sie aber nicht. Wenn WebAdmin, User Portal, VPN Portal oder SSL VPN aus dem gesamten Internet erreichbar sind, werden diese Dienste weiterhin von Bots, Scannern und Brute-Force-Versuchen getroffen. Das erzeugt unnötige Logeinträge, Supportaufwand und Risiko.

Deshalb sollte man MFA immer mit Erreichbarkeitskontrollen kombinieren:

• Device access: Grundsätzlich festlegen, welche Dienste in welcher Zone erreichbar sind.
• Local service ACL exception rule: WebAdmin, SSH oder Portale gezielt nur aus Managementnetzen, VPN-Netzen oder bekannten Quelladressen erlauben.
• MFA: Anmeldungen zusätzlich absichern, falls gültige Zugangsdaten kompromittiert wurden.
• Logging und Syslog: Fehlversuche, Rolloutprobleme und Angriffe nachvollziehbar machen.

Wenn ein Portal weltweit erreichbar sein muss, sollte man wenigstens MFA, gültige Zertifikate, Logging, restriktive Benutzergruppen und regelmässige Review-Prozesse kombinieren. Für öffentlich erreichbare Firewall-Dienste ist die Frage nicht nur, ob sich ein Angreifer anmelden kann, sondern ob der Dienst überhaupt breit erreichbar sein muss.

Zugriff zusätzlich mit ACL-Regeln einschränken

Bevor man MFA aktiviert, sollte man prüfen, von wo WebAdmin, SSH, User Portal und VPN Portal überhaupt erreichbar sind.

Der Menüpfad lautet System > Administration > Device access.

Dort gibt es zwei relevante Bereiche:

• Local service ACL: Grundsätzlicher Zugriff pro Zone, zum Beispiel LAN, VPN oder WAN.
• Local service ACL exception rule: Gezielte Ausnahmen für einzelne Quellnetze, Hosts oder Support-Zugänge.

Für produktive Umgebungen sollte man WebAdmin und SSH nicht allgemein für die WAN-Zone aktivieren. Besser ist eine Einschränkung auf:

• eine Management-IP,
• ein Admin-Netz,
• ein VPN-Netz,
• einen dedizierten Support-Host,
• oder eine klar definierte FQDN-/Host-Ausnahme.

Wenn SSH benötigt wird, sollte der Zugriff zusätzlich eingeschränkt und idealerweise mit Public Key genutzt werden. Dazu passt Sophos Firewall per SSH verbinden.

⚠️ MFA schützt vor gestohlenen Zugangsdaten, aber nicht vor unnötig exponierten Diensten. WebAdmin, SSH und Portale sollten nie breiter erreichbar sein als nötig.

MFA-Variante auswählen und Rollout planen

Vor der Aktivierung sollte man entscheiden, ob die lokale Sophos-OTP-Funktion reicht oder ob eine bestehende MFA-Plattform über RADIUS, NPS oder SSO eingebunden werden soll. Danach wird der Rollout geplant, damit sich Administratoren und Benutzer nicht selbst aussperren.

Voraussetzungen

Vor der Aktivierung sollte man prüfen:

• Die Systemzeit der Firewall ist korrekt.
• Ein funktionierender NTP-Server ist konfiguriert.
• Die Benutzer sind lokal, über AD, LDAP, RADIUS oder einen anderen unterstützten Authentifizierungsdienst vorhanden.
• Die betroffenen Benutzer können sich am User Portal oder am jeweiligen Dienst anmelden.
• Mindestens ein administrativer Fallback-Zugang ist vorhanden.

⚠️ Bei Admin-MFA muss man besonders aufpassen. MFA sollte nicht direkt für alle Administratoren aktiviert werden, ohne vorher einen Testbenutzer, einen zweiten Administrator und einen Fallback-Zugang geprüft zu haben. Eine falsche MFA-Konfiguration kann dazu führen, dass man sich selbst aus dem WebAdmin oder VPN Portal aussperrt.

Sophos MFA oder externe MFA?

Für MFA auf der Sophos Firewall gibt es grundsätzlich zwei Wege: Man nutzt die lokale OTP-Funktion der Firewall oder bindet eine externe MFA-Lösung über RADIUS beziehungsweise SSO an. Beide Varianten sind legitim, lösen aber unterschiedliche Probleme.

Die lokale MFA der Sophos Firewall verwaltet OTP-Token direkt auf der Firewall. Das ist meistens der schnellste Weg, um WebAdmin, Portale und Remote Access mit einem zweiten Faktor abzusichern. Es braucht keine zusätzliche RADIUS-Infrastruktur und keinen Identity Provider.

Vorteile der Sophos-eigenen MFA:

• Keine zusätzliche RADIUS- oder Identity-Provider-Integration nötig.
• Schneller Rollout für lokale Benutzer und kleine Umgebungen.
• Token können direkt auf der Firewall erzeugt und verwaltet werden.
• Geeignet für WebAdmin, User Portal, VPN Portal, SSL VPN Remote Access und IPsec Remote Access.

Nachteile:

• Benutzer müssen möglicherweise eine zusätzliche Authenticator-App oder einen zusätzlichen Token pflegen.
• Der Token ist getrennt von Microsoft 365, Entra ID oder anderen bestehenden MFA-Prozessen.
• Je nach Login-Maske gibt es kein eigenes OTP-Feld.
• Benutzer müssen bei bestimmten Portalen Passwort und Token direkt hintereinander eingeben.

In grösseren Umgebungen kann eine externe MFA-Lösung sinnvoller sein. Typische Varianten sind RADIUS mit einem MFA-fähigen Backend, Microsoft NPS mit Entra-MFA-Erweiterung oder ein anderes RADIUS-kompatibles MFA-System. Je nach SFOS-Version und Remote-Access-Modell kann auch Microsoft Entra ID SSO für WebAdmin, VPN Portal sowie Sophos Connect mit SSL VPN oder IPsec VPN passen.

Wichtig ist die Unterscheidung: Entra ID ist nicht einfach derselbe Mechanismus wie die lokale Sophos-OTP-Funktion. Entweder wird Entra MFA indirekt über RADIUS/NPS in den Authentifizierungsfluss eingebunden oder man nutzt ein SSO-Modell, wenn der verwendete Dienst und Client dies unterstützen.

Für Benutzer ist eine externe MFA oft angenehmer, weil sie dieselbe MFA verwenden wie für Microsoft 365 oder andere Unternehmensdienste. Dadurch entsteht keine zweite MFA-Welt mit zusätzlicher App, zusätzlichem Token und anderem Loginverhalten.

Der Nachteil einer externen Lösung ist die höhere Komplexität. RADIUS, Gruppen, Timeouts, Challenge-Verhalten und Fallback müssen sauber geplant und getestet werden.

• Sophos OTP auf der Firewall: Schnell eingerichtet, ohne Zusatzinfrastruktur und direkt in SFOS verwaltet. Dafür entsteht ein zusätzlicher Token, getrennt von Microsoft 365 oder Entra ID; je nach Portal muss Passwort plus OTP in ein Feld. Typisch für kleine Umgebungen, lokale Benutzer und schnelle Härtung von WebAdmin oder VPN.
• Externe MFA über RADIUS: Bestehende MFA-Plattform kann genutzt werden und zentrale Benutzerprozesse bleiben erhalten. Dafür müssen RADIUS, NPS, Timeouts, Gruppen und Clientverhalten sauber getestet werden. Typisch für AD-/Microsoft-365-Umgebungen mit vielen VPN-Benutzern.
• Entra ID SSO: Vertrauter Microsoft-Login, bessere Benutzererfahrung und zentrale Identity-Prozesse. Nicht jedes Szenario ist identisch nutzbar; es hängt von SFOS-Version, Dienst und Client ab. Typisch für WebAdmin, VPN Portal und Sophos Connect, wenn SSO zum Betriebsmodell passt.

Entscheidungshilfe

Die richtige MFA-Variante hängt weniger von der Firewall ab als vom bestehenden Identitätsbetrieb.

• Kleine Umgebung mit lokalen Firewall-Benutzern: Sophos-eigene OTP-Funktion ist oft ausreichend.
• Microsoft-365-Umgebung mit bestehender Entra-MFA: Externe MFA über RADIUS/NPS oder Entra-ID-SSO prüfen, damit Benutzer nicht zwei MFA-Welten pflegen müssen.
• Viele externe Dienstleister: Eigene Benutzergruppe, MFA-Pflicht, klare Laufzeit und regelmässiger Review.
• Kritische Admin-Zugänge: MFA plus Device Access, Management-Netz, Fallback-Admin und Logging kombinieren.
• Viele Remote-Access-Benutzer: Pilotgruppe, Helpdesk-Prozess, Token-Reset und Clienttests vor dem breiten Rollout einplanen.

Wenn Microsoft Entra ID direkt als SSO-Quelle für VPN Portal oder Sophos Connect geplant ist, passt zusätzlich Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten. Das ist ein anderes Betriebsmodell als die klassische Sophos-OTP-Funktion und sollte nicht ungeprüft mit RADIUS-MFA gleichgesetzt werden.

MFA planen

Für produktive Umgebungen ist es meist besser, MFA zuerst für eine kleine Pilotgruppe zu aktivieren.

Bewährt hat sich diese Reihenfolge:

1. Testbenutzer oder Pilotgruppe vorbereiten.
2. NTP und Uhrzeit der Firewall prüfen.
3. MFA für den Testbereich aktivieren.
4. Anmeldung mit Authenticator-App testen.
5. Erst danach weitere Benutzergruppen einbinden.

Für Dienstleister empfiehlt sich eine eigene Benutzergruppe. Dadurch lässt sich MFA gezielt erzwingen und der Zugriff später einfacher entfernen.

Für Administratoren sollte man zusätzlich planen:

• Wer ist der erste Test-Admin?
• Gibt es einen zweiten Admin mit funktionierendem Zugriff?
• Ist der Zugriff über ein Management-Netz oder VPN möglich?
• Ist der default admin separat geschützt?
• Ist dokumentiert, wie ein verlorener Token ersetzt wird?

MFA aktivieren und Token einrichten

Wenn Voraussetzungen, Gruppen und Fallback geklärt sind, kann MFA zuerst für eine Pilotgruppe aktiviert werden. Erst nach erfolgreichen Tests sollte man weitere Benutzer oder Administratoren einbeziehen.

MFA auf der Sophos Firewall aktivieren

Die MFA-Einstellungen befinden sich in aktuellen SFOS-Versionen unter Authentication > Multi-factor authentication. In älteren Oberflächen oder je nach Navigation kann der Bereich noch unter Configure > Authentication > Multi-factor authentication erscheinen.

1. Am WebAdmin der Sophos Firewall anmelden.
2. Authentication öffnen.
3. Auf den Tab Multi-factor authentication wechseln.
4. Bei One-time password (OTP) auswählen, für wen MFA gelten soll:
   • No OTP: MFA ist deaktiviert.
   • All users: MFA gilt für alle Benutzer.
   • Specific users and groups: MFA gilt nur für ausgewählte Benutzer oder Gruppen.
5. Generate OTP token with next sign-in aktivieren, wenn Benutzer ihren Token beim nächsten Login selbst einrichten sollen.
6. Unter Require MFA for auswählen, für welche Dienste MFA verlangt wird.
7. Die Konfiguration mit Apply speichern.

Typische Optionen unter Require MFA for sind:

• User portal
• Web admin console
• VPN portal
• SSL VPN remote access
• IPsec remote access
• Web application firewall

Je nach Umgebung kann MFA für einzelne Dienste oder Benutzergruppen unterschiedlich angewendet werden. Für Administratoren sollte man MFA konsequent erzwingen, aber zuerst kontrolliert testen.

Wenn Webanwendungen über Web Server Protection veröffentlicht werden, braucht es zusätzlich eine passende WAF-Authentifizierungsrichtlinie. Der Ablauf steht in Sophos Firewall WAF mit MFA absichern.

Rollout und Betrieb vorbereiten

MFA ist nicht nur ein Schalter in der Firewall. Nach der Aktivierung ändern sich Loginverhalten, Supportfragen und Notfallzugriffe. Deshalb sollte vor dem breiten Rollout klar sein, wer Tokens ausgibt, wer verlorene Tokens zurücksetzt und wie ausserhalb der Bürozeiten reagiert wird.

Für den Betrieb haben sich diese Punkte bewährt:

• Pilotgruppe mit echten Benutzern testen, nicht nur mit Administratoren.
• Einen zweiten Admin und einen Break-Glass-Zugang dokumentieren.
• Helpdesk über Passwort+OTP-Verhalten informieren.
• Token-Reset-Prozess für neue Smartphones oder verlorene Geräte festlegen.
• Log Viewer und Authentifizierungslogs nach dem Rollout prüfen.
• Externe MFA über RADIUS mit realistischen Timeouts testen.
• Device Access und ACL-Ausnahmen regelmässig mitprüfen.

Besonders bei Remote Access sollte man MFA mit den betroffenen VPN-Regeln, Benutzergruppen und Clientprofilen zusammen testen. Ein funktionierender WebAdmin-Login beweist nicht automatisch, dass SSL VPN, IPsec Remote Access oder Sophos Connect gleich funktionieren.

Fallback und Break-Glass planen

MFA erhöht die Sicherheit, kann aber auch legitime Admins aussperren, wenn Token, Uhrzeit, Authentifizierungsserver oder Gruppen nicht passen. Deshalb braucht es vor der Aktivierung einen Fallback-Plan.

Mindestens diese Punkte sollten dokumentiert sein:

• Wer hat einen zweiten getesteten Admin-Zugang?
• Ist der Zugriff aus einem Management-Netz oder Admin-VPN möglich?
• Ist der lokale default admin als Notfallkonto geschützt, aber nicht für den Alltag verwendet?
• Wie wird ein verlorener oder defekter OTP-Token zurückgesetzt?
• Wer darf Token für Administratoren zurücksetzen?
• Wie wird ausserhalb der Bürozeiten reagiert?
• Gibt es vor der Änderung ein aktuelles Backup?

Der Fallback darf nicht bedeuten, dass ein ungeschützter Admin-Zugang dauerhaft aus dem Internet erreichbar bleibt. Besser ist ein Notfallkonto mit klarer Dokumentation, engem Zugriffspfad und regelmässigem Review.

MFA für den default admin

Der lokale default Benutzer admin ist ein Sonderfall. MFA für diesen Benutzer wird nicht direkt im Tab Multi-factor authentication aktiviert.

Der Menüpfad lautet System > Administration > Device access.

Dort kann man MFA for default admin aktivieren. Das sollte man erst machen, wenn:

• die Systemzeit korrekt ist,
• ein zweiter Administrator getestet wurde,
• der Zugriff über ein vertrauenswürdiges Management-Netz funktioniert,
• und klar ist, wie man im Notfall wieder administrativen Zugriff erhält.

Für den default admin gilt: Nicht deaktivieren, nicht ungeschützt im Internet erreichbar machen und nicht als normaler Tagesbenutzer verwenden. Er ist ein Break-Glass- oder Notfallkonto.

Andere Administratoren sollten nicht davon ausgehen, dass sie den MFA-Token des default admin wie einen normalen Benutzertoken bearbeiten oder löschen können. Dieser Zugang muss bewusst über den eigenen Device-Access-Pfad geplant und getestet werden.

Token für Benutzer einrichten

Nach der Aktivierung muss der Benutzer seinen zweiten Faktor einrichten. Wenn Generate OTP token with next sign-in aktiv ist, meldet sich der Benutzer am User Portal oder VPN Portal an und scannt den QR-Code mit einer Authenticator-App.

Geeignete Apps sind zum Beispiel:

• Microsoft Authenticator.
• Google Authenticator.
• Sophos Intercept X for Mobile.
• 1Password.
• Bitwarden.
• Andere TOTP-kompatible Authenticator-Apps.

Der erzeugte Code ist zeitbasiert. Wenn die Uhrzeit auf Firewall oder Smartphone stark abweicht, schlägt die Anmeldung fehl.

Wenn das User Portal deaktiviert ist, können Benutzer ihre Tokens unter Umständen nicht selbst einrichten. In diesem Fall muss man entweder das Portal kontrolliert bereitstellen oder Tokens administrativ vorbereiten.

Unter Authentication > Multi-factor authentication > Issued tokens sieht man, welche Benutzer bereits einen Token erzeugt oder zugewiesen bekommen haben. Dort lassen sich Tokens prüfen, löschen oder bei Bedarf manuell vorbereiten. Für den default admin gilt eine Sonderregel: Andere Administratoren können dessen Token nicht wie normale Benutzertokens ändern oder löschen. Dieser Token wird über den eigenen default-admin-MFA-Pfad verwaltet.

Token-Algorithmus und App-Wechsel

Sophos Firewall unterstützt für OTP-Token die Hash-Algorithmen SHA1, SHA256 und SHA512. SFOS-Versionen vor 22.0 verwenden für MFA den Hash-Algorithmus SHA1; ab SFOS 22.0 sollte man für neue oder migrierte Tokens SHA256 oder SHA512 prüfen. Das darf aber nicht blind gesetzt werden: Der gewählte Hash-Algorithmus muss zur verwendeten Authenticator-App passen.

Sophos weist ausdrücklich darauf hin, dass eine App den gewählten Algorithmus unterstützen muss. Wenn eine App SHA256 oder SHA512 nicht sauber unterstützt, kann der QR-Code zwar gescannt werden, die Anmeldung schlägt aber trotzdem fehl. Deshalb gehört der Algorithmus immer in den Pilot-Test, besonders wenn Microsoft Authenticator, Passwortmanager-TOTP, Google Authenticator oder Sophos Intercept X for Mobile gemischt verwendet werden.

Für den Betrieb sind diese Punkte wichtig:

• Neue Token nicht mehr mit alten App-Annahmen planen.
• Eine Authenticator-App verwenden, die den gewählten Hash-Algorithmus unterstützt.
• Bei App-Wechsel oder verlorenem Smartphone den alten Token löschen und den QR-Code neu erzeugen lassen.
• Hardware-Token nur einsetzen, wenn Algorithmus, Zeitschritt und Geheimnis sauber verwaltet werden können.
• Vor einer SHA256-/SHA512-Migration eine Pilotgruppe testen, statt alle Token gleichzeitig umzustellen.
• Bestehende SHA1-Tokens bei einer Migration kontrolliert löschen und neu erzeugen lassen.

Die alte Sophos Authenticator App sollte nicht mehr als neue Standard-App eingeplant werden; sie ist laut Sophos seit dem 31. Juli 2022 End of Life. In vielen Umgebungen sind Microsoft Authenticator, Google Authenticator, Sophos Intercept X for Mobile, 1Password oder Bitwarden die realistischeren Optionen. Wichtig ist weniger der Markenname der App, sondern ob TOTP, Hash-Algorithmus, Backup/Restore-Verhalten und Helpdesk-Prozess zusammenpassen.

Wenn ein Benutzer das Smartphone wechselt, sollte der alte Token nicht einfach stillschweigend weiterbestehen. Besser ist ein klarer Prozess: Identität prüfen, alten Token löschen, neuen QR-Code erzeugen, Login mit richtigem und falschem OTP testen und den Vorgang dokumentieren.

Wichtiger Hinweis zu Passwort und Token

Je nach Sophos-Dienst gibt es für den OTP-Code kein separates Formularfeld. Besonders beim VPN Portal oder bei Remote-Access-Logins führt das immer wieder zu Verwirrung.

In diesen Fällen muss der Benutzer häufig Passwort und OTP-Code direkt hintereinander eingeben.

Beispiel:

Passwort: MeinSicheresPasswort
OTP-Code: 123456
Eingabe:  MeinSicheresPasswort123456

Das sollte man den Benutzern vor dem Rollout klar kommunizieren. Sonst sieht es für den Benutzer so aus, als ob das Passwort falsch wäre, obwohl nur der OTP-Code fehlt.

Dieses Verhalten sollte vor dem Rollout getestet und dokumentiert werden, weil es je nach Dienst und Loginmaske unterschiedlich wahrgenommen wird.

Testen und Betrieb kontrollieren

Ein erfolgreicher WebAdmin-Test reicht nicht aus. Jede betroffene Anmeldefläche muss separat getestet werden, weil Portal, VPN-Client, Benutzergruppe und Authentifizierungsserver unterschiedlich reagieren können.

Anmeldung testen

MFA sollte zuerst mit einem Benutzer getestet werden, der nicht der einzige Administrator ist.

Dabei sollten diese Punkte geprüft werden:

• Anmeldung am WebAdmin.
• Anmeldung am VPN Portal.
• Anmeldung am Remote-Access-Dienst.
• Verhalten bei falschem OTP-Code.
• Verhalten nach Ablauf eines OTP-Codes.
• Zugriff mit einem Benutzer, der nicht in der MFA-Gruppe ist.
• Login mit Passwort und angehängtem OTP-Code.
• Zugriff über die geplanten ACL-Regeln.

Erst wenn diese Tests erfolgreich sind, sollte man MFA auf weitere Gruppen ausrollen.

Testmatrix nach Dienst

Ein MFA-Test sollte nicht nur aus einem erfolgreichen WebAdmin-Login bestehen. Je nach Dienst greifen andere Portale, Gruppen, Profile und Logdateien. Diese Matrix hilft, die wichtigsten Fälle getrennt zu prüfen:

• WebAdmin: Admin-Benutzer mit richtigem und falschem OTP anmelden. Richtiger OTP erlaubt Zugriff, falscher OTP wird sauber abgelehnt und geloggt.
• Default admin: Separaten MFA-Pfad unter System > Administration > Device access testen. Das Notfallkonto ist geschützt, aber ein dokumentierter Break-Glass-Weg bleibt verfügbar.
• User Portal: Benutzer richtet Token selbst ein. QR-Code erscheint nur für berechtigte Benutzer, der Token funktioniert danach beim Login.
• VPN Portal: Benutzer meldet sich mit Passwort und OTP an. Der Login funktioniert mit dokumentiertem Eingabeformat und wird im Log Viewer sichtbar.
• SSL VPN / Sophos Connect: Profil importieren oder Verbindung neu aufbauen. MFA wird im echten Client abgefragt, nicht nur im Browser.
• IPsec Remote Access: Gruppe und Authentifizierungsmethode prüfen. MFA greift für dieselbe Gruppe, die auch in der Remote-Access-Konfiguration erlaubt ist.
• Externe MFA über RADIUS: Push, Challenge oder Token mit echtem Client testen. Timeout reicht aus, Challenge-Verhalten passt zum Client und Fehler werden am RADIUS-Server sichtbar.

Bei jedem Test sollte zusätzlich geprüft werden, ob Device Access oder eine Local-Service-ACL-Regel den Dienst absichtlich erlaubt. Wenn der Token funktioniert, das Portal aber aus dem falschen Netz erreichbar ist, ist die MFA-Konfiguration nur ein Teil des Problems gelöst.

Logs und Betriebskontrolle

Nach dem Rollout sollte man prüfen, ob MFA-Ereignisse im Betrieb nachvollziehbar sind. Das ist wichtig für Supportfälle, Sicherheitsreviews und Incident Response.

Sinnvolle Prüfpunkte:

• Im Log viewer nach Authentifizierungsereignissen suchen.
• Fehlgeschlagene Logins von falschem Passwort, falschem OTP und abgelaufenem OTP unterscheiden.
• VPN-Portal- und Remote-Access-Tests mit Uhrzeit und Benutzer dokumentieren.
• Bei externem RADIUS zusätzlich RADIUS-Server, NPS-Logs oder Identity-Provider-Logs prüfen.
• Bei längerer Aufbewahrung Central Reporting oder Syslog/SIEM einplanen.

Für lokale Logdateien und Service-Zuordnung passt Sophos Firewall Troubleshooting: Services und Logs. Wenn Authentifizierungs- und Portalereignisse langfristig ausgewertet werden sollen, passt Sophos Firewall Syslog an SIEM senden.

Bei Sophos Central, Syslog oder SIEM sollte man nach dem Rollout nicht nur erfolgreiche Logins prüfen. Interessant sind vor allem wiederholte Fehlversuche auf WebAdmin, User Portal, VPN Portal und SSL VPN, weil diese zeigen, ob ein Dienst unnötig breit erreichbar ist oder ob Benutzer mit dem OTP-Format kämpfen.

Troubleshooting

OTP-Code wird nicht akzeptiert

Zuerst Systemzeit der Firewall und Uhrzeit des Smartphones prüfen. TOTP ist zeitabhängig. Schon eine deutliche Abweichung kann dazu führen, dass gültige Codes abgelehnt werden.

Unter Authentication > Multi-factor authentication kann man ausgestellte Token prüfen. Wenn ein einzelner Token immer wieder knapp danebenliegt, sollte man nicht sofort die gesamte MFA-Konfiguration ändern. Zuerst Token-Zeitdrift, verwendete App, Hash-Algorithmus und Zeitschritt kontrollieren.

Benutzer sieht keinen QR-Code

Der Benutzer muss für MFA berechtigt sein und sich am richtigen Portal anmelden. Zusätzlich sollte geprüft werden, ob der Benutzer über die erwartete Authentifizierungsquelle gefunden wird.

Wenn das User Portal deaktiviert ist, kann der Benutzer den Token möglicherweise nicht selbst einrichten. Dann muss das Portal temporär erreichbar gemacht oder der Token administrativ erstellt werden.

Portal ist durch Device Access nicht erreichbar

Wenn Benutzer ihren Token nicht einrichten können, obwohl MFA korrekt aktiviert wurde, sollte man nicht zuerst den Token löschen. Häufig ist das benötigte Portal über System > Administration > Device access oder eine Local-Service-ACL-Regel nicht aus dem aktuellen Netz erreichbar.

Zuerst prüfen:

• Welches Portal wird für die Token-Einrichtung verwendet?
• Aus welcher Zone oder Quelle kommt der Benutzer?
• Ist der Zugriff bewusst erlaubt oder versehentlich blockiert?
• Gibt es eine engere ACL-Ausnahme statt einer breiten Freigabe?

Administrator ist ausgesperrt

In diesem Fall den vorbereiteten Fallback-Zugang verwenden. Wenn kein Fallback vorhanden ist, muss der Zugriff je nach Situation über Konsole, Support oder Wiederherstellungswege geprüft werden.

MFA greift nicht für Remote Access

Man prüft, ob die Remote-Access-Konfiguration die gleiche Benutzergruppe verwendet, für die MFA aktiviert wurde. Häufig liegt der Fehler nicht an MFA selbst, sondern an unterschiedlichen Gruppen in VPN- und Authentifizierungsregeln.

Auch Clientprofile müssen zur aktuellen Konfiguration passen. Nach Änderungen an VPN Portal, SSL VPN, IPsec Remote Access, Entra SSO oder RADIUS sollte man betroffene Sophos-Connect-Profile neu importieren oder neu verteilen.

Benutzer gibt nur das Passwort ein

Wenn kein separates OTP-Feld angezeigt wird, muss der Benutzer Passwort und OTP-Code direkt hintereinander eingeben. Das ist einer der häufigsten Supportfälle nach der Aktivierung von Sophos OTP.

Externe MFA funktioniert nicht zuverlässig

Bei RADIUS-basierten MFA-Lösungen müssen Timeouts, Challenge-Verhalten und Gruppen sauber passen. Wenn Push-MFA, Call-MFA oder Challenge-Antworten verwendet werden, sollte man den kompletten Loginprozess mit dem betroffenen Client testen.

Wichtig ist ausserdem die Portalgrenze: Nicht jeder Sophos-Login unterstützt jedes RADIUS-Challenge-Verhalten gleich gut. Besonders VPN Portal, SSL VPN, Sophos Connect, WebAdmin und Captive Portal sollten getrennt mit echten Clients getestet werden. Ein erfolgreicher RADIUS-Test in der Serverkonfiguration reicht nicht als Nachweis für den produktiven Remote-Access-Login.

MFA wurde für die falsche Gruppe aktiviert

Wenn MFA bei einigen Benutzern greift und bei anderen nicht, sollte man Gruppen zuerst technisch vergleichen. Relevant sind nicht nur die sichtbaren Anzeigenamen, sondern die tatsächlich importierten oder gematchten Gruppen aus AD, LDAP, RADIUS oder Entra ID. Ein Benutzer kann sich erfolgreich authentifizieren und trotzdem nicht in der Gruppe landen, für die MFA verlangt wird.

Betriebscheckliste und Empfehlung

Nach der technischen Aktivierung braucht MFA einen einfachen Betriebsprozess: Wer setzt Token zurück, wer prüft Logs und wie wird kontrolliert, dass Portale nicht unnötig breit erreichbar sind?

Betriebscheckliste

• Systemzeit und NTP geprüft.
• Pilotgruppe definiert und getestet.
• MFA nicht direkt für alle Administratoren gleichzeitig aktiviert.
• Zweiter Admin und Break-Glass-Zugang dokumentiert.
• Device Access und Local Service ACL für WebAdmin, User Portal, VPN Portal und SSL VPN geprüft.
• Zugriff aus erlaubtem und nicht erlaubtem Quellnetz getestet.
• Benutzer über Passwort+OTP-Verhalten informiert.
• Token-Reset-Prozess für verlorene Smartphones dokumentiert.
• Authenticator-App, Hash-Algorithmus und Token-Migration dokumentiert.
• Remote Access mit echten Clients und aktuellen Profilen getestet.
• RADIUS-/Entra-Timeouts getestet, falls externe MFA verwendet wird.
• Logs und zentrale Aufbewahrung geprüft.

Betriebsempfehlung

MFA sollte für administrative Zugänge Standard sein. Besonders wichtig ist MFA für WebAdmin, VPN Portal und alle Benutzer mit Remote-Access-Berechtigung.

Für kleine Umgebungen ist die Sophos-eigene OTP-Funktion oft ausreichend. In Microsoft-365- oder Entra-ID-Umgebungen kann eine externe MFA über RADIUS angenehmer sein, weil Benutzer keine zweite MFA-Welt lernen müssen.

Unabhängig von der MFA-Variante gilt: Zugriff zuerst mit ACL-Regeln einschränken, Admin-MFA vorsichtig testen, Benutzer über Passwort+Token informieren und erst danach breit ausrollen.

FAQ