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

Für die lokale OTP-Funktion öffnet man Authentication > Multi-factor authentication, wählt zuerst Specific users and groups, aktiviert die benötigten Dienste und testet alles mit einer Pilotgruppe. All users sollte erst nach erfolgreichen Tests verwendet werden.

MFA schützt WebAdmin, VPN Portal und Remote Access vor der alleinigen Verwendung gestohlener Passwörter. Sie ersetzt aber weder enge Zugriffsregeln noch einen getesteten Notfallzugang. Dieser Artikel führt deshalb von der sicheren Aktivierung bis zu App-Auswahl, Recovery und Troubleshooting.

Im Zentrum steht das lokale Sophos OTP. RADIUS und Entra ID SSO werden weiter unten als Alternativen eingeordnet.

Sophos OTP sicher aktivieren

Die folgenden Abläufe unterscheiden die dokumentierten MFA-Funktionen von SFOS 22 und SFOS 23. Insbesondere Share QR code und die beschriebene QR-Laufzeit dürfen nicht auf SFOS 22 übertragen werden. Die App-Einschränkungen beziehen sich auf den dokumentierten Sophos-Registrierungsablauf, nicht pauschal auf jede aktuelle App-Version. Vor dem Rollout werden deshalb der installierte SFOS-Build, das mobile Betriebssystem, die konkrete App-Version und jeder benötigte Dienst mit der Pilotgruppe geprüft.

Vor dem Aktivieren

Vor der ersten Änderung sollten diese Punkte geklärt sein:

• Die Firewall verwendet unter Administration > Time eine korrekte Uhrzeit, idealerweise über NTP.
• Benutzer und Gruppen sind lokal oder über AD, LDAP beziehungsweise einen anderen Authentifizierungsserver verfügbar.
• Eine Pilotgruppe und ein zweiter getesteter Administrator existieren.
• Für den default admin sind Konsole und Recovery-Weg bekannt.
• Ein aktuelles Backup und ein dokumentierter Token-Reset-Prozess sind vorhanden.

Bei klassischem Active Directory hilft Active Directory auf Sophos Firewall hinzufügen bei der Benutzerquelle.

Unter Administration > Device access legt man fest, aus welchen Zonen WebAdmin, User Portal, VPN Portal und andere lokale Dienste erreichbar sind. Local service ACL exception rules grenzen den Zugriff weiter auf Managementnetze, VPN-Netze oder bekannte Quelladressen ein. Die genaue Härtung erklärt Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.

SSH gehört nicht zu den Diensten, die durch Sophos OTP geschützt werden. Es sollte über Device Access eingeschränkt und möglichst mit Public Key verwendet werden; der Ablauf steht unter Sophos Firewall per SSH verbinden.

⚠️ MFA reduziert das Risiko kompromittierter Passwörter, verkleinert aber nicht die Angriffsfläche eines öffentlich erreichbaren Dienstes. WebAdmin, SSH und Portale sollten nie breiter freigegeben sein als nötig.

Vor Negativtests prüft man zusätzlich Administration > Admin and user settings > Login security > Block login. Mehrere absichtliche Fehlversuche können die Quell-IP für WebAdmin, CLI, VPN Portal und User Portal sperren und damit auch einen Fallback-Admin aus demselben Netz blockieren. Eine zweite Quelle oder der Konsolenzugang sollte deshalb verfügbar sein.

MFA für eine Pilotgruppe konfigurieren

1. Am WebAdmin anmelden und Authentication > Multi-factor authentication öffnen.
2. Unter One-time password (OTP) zuerst Specific users and groups auswählen.
3. Add users and groups öffnen, die Pilotgruppe auswählen und übernehmen.
4. Generate OTP token with next sign-in aktivieren, wenn eine Authenticator-App verwendet wird. Unter SFOS 23 zusätzlich Share QR code auswählen: Email sendet den QR-Code beim nächsten Login am VPN Portal oder User Portal an die E-Mail-Adresse des Benutzers. Portals zeigt ihn im User Portal und VPN Portal nach dem nächsten Login am VPN Portal, User Portal oder WebAdmin. Diese Auswahl gilt nicht für den unten beschriebenen Default-Admin-Assistenten.
5. Unter Require MFA for nur die tatsächlich benötigten Anmeldeflächen auswählen.
6. Unter OTP hash algorithm einen von der vorgesehenen App unterstützten Algorithmus festlegen.
7. Optionale OTP timestep settings nur ändern, wenn die App denselben Zeitschritt unterstützt; der Standard beträgt 30 Sekunden.
8. Mit Apply speichern.

Nach Apply schliesst ein Pilotbenutzer den Ablauf sofort ab: je nach gewähltem Dienst zunächst nur mit dem Passwort am User Portal oder VPN Portal anmelden, QR-Code beziehungsweise Base32-Schlüssel in der Authenticator-App registrieren und danach eine frische Sitzung mit <password><passcode> öffnen. Ein absichtlich falscher Code muss abgewiesen und der Versuch im Log viewer sichtbar werden. Erst nach diesem Positiv- und Negativtest kommt All users infrage.

Die Benutzeroptionen bedeuten:

• No OTP: MFA ist deaktiviert.
• All users: MFA gilt für alle Benutzer; erst nach dem Pilot verwenden.
• Specific users and groups: MFA gilt nur für die ausgewählten Konten oder Gruppen.

Bei extern authentifizierten Benutzern wirkt das Entfernen aus einer MFA-Gruppe nicht sofort beim ersten folgenden Login. Sophos verlangt noch eine Anmeldung mit MFA; erst bei den darauffolgenden Anmeldungen entfällt der OTP-Code. Eine Gruppenänderung wird deshalb mit einer frischen Sitzung und mindestens zwei kontrollierten Logins geprüft.

Ist Generate OTP token with next sign-in aktiviert, registrieren Benutzer ihre Authenticator-App beim nächsten Login. Das User Portal wird dabei automatisch als MFA-Dienst ausgewählt. Ist die Option deaktiviert, werden Hardware- oder manuell verwaltete Token unter Issued tokens zugewiesen.

Bei Email vor dem Pilot prüfen, ob die richtige Benutzeradresse hinterlegt ist und die Zustellung funktioniert. Der QR-Code enthält das Token-Geheimnis: Postfachzugriff schützen und QR-Code oder Base32-Schlüssel nicht in ungeschützte Tickets oder Screenshots übernehmen. Bei fehlender Zustellung zuerst Adresse und E-Mail-Versand prüfen, nicht durch wiederholte Fehlanmeldungen einen Login-Block auslösen. Für einen Pilot ohne E-Mail-Zustellung ist Portals die dokumentierte Alternative; der Portalzugriff muss aus dem vorgesehenen Netz möglich sein.

Dienste bewusst auswählen

Unter SFOS 22 stehen diese Dienste unter Require MFA for zur Verfügung:

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

MFA für das User Portal gilt zusätzlich für Captive Portal und Client Authentication Agents. Remote-Access-Benutzer müssen ihren Token zuerst über VPN Portal oder User Portal registrieren.

Für WAF ist die Auswahl allein nicht ausreichend. Ab SFOS 22 benötigt man Webserver Protection, eine Form-basierte Authentication Policy und deren Zuweisung in der WAF-Regel. Der vollständige Ablauf steht unter Sophos Firewall WAF mit MFA absichern.

Passendes MFA-Modell wählen

Lokales Sophos OTP

Sophos OTP verwaltet die Token direkt auf der Firewall und benötigt keine zusätzliche RADIUS- oder Identity-Provider-Infrastruktur. Es eignet sich besonders für normale lokale Benutzer, kleine Umgebungen und eine schnelle Härtung von WebAdmin oder Remote Access.

Der Preis für die einfache Einführung ist ein eigener Token ausserhalb bestehender Microsoft-365-Prozesse. Benutzer und Helpdesk müssen Einrichtung in der Authenticator-App, Passwort-plus-OTP-Eingabe sowie Gerätewechsel kennen.

RADIUS oder Entra ID SSO

Eine bestehende MFA-Plattform kann über RADIUS oder SSO besser zum zentralen Identity-Betrieb passen. Sie benötigt aber dienstspezifische Tests:

• Das VPN Portal unterstützt kein RADIUS mit Challenge-MFA.
• Sophos Connect unterstützt keine OTP-Challenge. Der Client sendet Passwort und OTP zusammen im Format passwordotp, unterstützt aber Call- und Push-MFA.
• User Portal und WebAdmin unterstützen zusätzlich Challenge-basierte MFA.
• Bei Entra ID SSO erfolgt MFA am Identity Provider; lokale Sophos-OTP-MFA kann nicht zusätzlich auf denselben SSO-Login gelegt werden.
• Entra SSO mit Sophos Connect benötigt unter Windows mindestens Clientversion 2.4. WebAdmin-SSO steht auf dem HA-Auxiliary-Gerät nicht zur Verfügung.

Für Remote Access gibt es die separate Anleitung Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten. Soll Entra dagegen die WebAdmin-Anmeldung und Administratorrollen steuern, führt Entra ID SSO für Sophos Firewall WebAdmin durch Rollenmapping, Least Privilege, Pilotlogin und lokalen Notfallzugang.

Bei der Wahl des Remote-Access-Modells hilft Sophos Connect oder SSL VPN: Welche Lösung passt?; vor dem Rollout sollte man zudem die Sophos Connect Clientversion prüfen.

Unabhängig vom Modell beginnt man mit einer Pilotgruppe. Erst wenn WebAdmin, Portale, echte VPN-Clients, Gruppen, Timeouts, Logging und Fallback funktionieren, werden weitere Benutzer aufgenommen.

Token und Authenticator-App einrichten

Token registrieren und verwalten

Bei aktiviertem Generate OTP token with next sign-in meldet sich der Benutzer am VPN Portal oder User Portal an und registriert den QR-Code in einer kompatiblen App. Unter SFOS 22 wird der QR-Code angezeigt; Administratoren können den Token auch am WebAdmin registrieren, wenn dort MFA erzwungen wird. Unter SFOS 23 richtet sich die Zustellung nach Share QR code: Bei Email verwendet man den per E-Mail zugestellten QR-Code, bei Portals den in den Portalen angezeigten QR-Code. Ein WebAdmin-Login kann bei Portals die Anzeige in den Portalen auslösen; er ist kein E-Mail-Auslöser. Die Registrierung gilt nur für Benutzer und Gruppen, für die MFA konfiguriert ist.

Bei der Erstregistrierung unter SFOS 23 mit Generate OTP token with next sign-in auf ON gilt für die ausgewählten MFA-Benutzer: Wird der erzeugte QR-Code nicht innerhalb von 24 Stunden nach seiner Erzeugung zur Anmeldung verwendet, läuft er ab. Zur Neuerzeugung meldet sich der Benutzer nur mit dem Passwort am VPN Portal oder User Portal an; der neue QR-Code wird gemäss Email oder Portals zugestellt. Danach registriert man ihn in der App und prüft eine frische Anmeldung mit <password><passcode>. Diese QR-Laufzeit ist vom 300-Sekunden-Fenster des ersten Passcodes zu unterscheiden. Der Ablauf gilt nicht für einen ausgestellten Token mit Status OFF oder eine manuelle Seed-Neuausgabe; er wird weder für SFOS 22 noch pauschal für den Default-Admin-Assistenten vorausgesetzt.

Unter Authentication > Multi-factor authentication > Issued tokens lassen sich ausgestellte Token prüfen, vorübergehend deaktivieren, löschen oder manuell hinzufügen. Dort kann man ausserdem zusätzliche Einmalcodes erzeugen und den Zeitoffset eines Tokens prüfen beziehungsweise synchronisieren.

Wird der Token-Status auf OFF gesetzt, verhindert dies die Anmeldung des Benutzers; es erlaubt keinen Passwort-only-Zugang. Das ist weder das Löschen mit anschliessender Neuregistrierung noch der einmalige MFA-Skip unter CLI Main Menu > 2. System Configuration.

Bei einem verlorenen Smartphone oder App-Wechsel wird zuerst die Identität des Benutzers geprüft. Unmittelbar vor dem Löschen prüft man unter Authentication > Multi-factor authentication, dass Generate OTP token with next sign-in auf ON steht; unter SFOS 23 wird zusätzlich Share QR code mit Email oder Portals festgelegt. Ist bewusst der manuelle Modus OFF vorgesehen, wird stattdessen die manuelle Neuausgabe mit neuem Seed vorbereitet; der folgende automatische QR-Ablauf gilt dann nicht. Erst danach wird der alte Token unter Issued tokens gelöscht. Der Benutzer meldet sich einmal nur mit dem Passwort am VPN Portal oder User Portal an und registriert den neuen QR-Code: unter SFOS 22 wird er angezeigt, unter SFOS 23 wird er entsprechend der Auswahl per E-Mail zugestellt oder im Portal angezeigt. Danach wird eine frische Anmeldung mit <password><passcode> geprüft. Ein alter Token sollte nicht parallel unkontrolliert weiterbestehen.

Für diesen App-Wechsel-/Ersatzablauf unter SFOS 23 gilt: Wird der erzeugte QR-Code nicht innerhalb von 24 Stunden nach seiner Erzeugung zur Anmeldung verwendet, läuft er ab. Eine erneute Anmeldung nur mit dem Passwort erzeugt einen neuen QR-Code; die Zustellung erfolgt wieder gemäss Email oder Portals. Die 24 Stunden betreffen den QR-Code, nicht das unten erklärte 300-Sekunden-Fenster des ersten Passcodes. Diese QR-Laufzeit wird hier weder für SFOS 22 noch pauschal für den Default-Admin-Assistenten vorausgesetzt.

Die Liste kann auch manuell vorbereitete Token ohne Benutzerzuweisung enthalten; diesen kann später ein Benutzer zugeordnet werden. Ausserdem erscheinen manuell zugewiesene Token sowie Token von Benutzern und Administratoren, die den QR-Code registriert haben. Ein Listeneintrag allein beweist deshalb noch keinen erfolgreichen MFA-Login: vor der Übergabe Benutzerzuweisung, Token-Status und tatsächliche Anmeldung prüfen.

Nach dem Löschen ist der Passcode des alten Tokens ungültig und darf beim Passwort-only-Registrierungslogin nicht angehängt werden. Eine Löschung lässt sich nicht durch erneutes Eingeben des alten Codes rückgängig machen; der sichere Wiederherstellungsweg ist die kontrollierte Neuausgabe. Vor dem Löschen deshalb Portalzugriff, Zustellung beziehungsweise manuelle Seed-Übergabe und Fallback prüfen. Bei mehreren Benutzern schrittweise vorgehen und jede Neuregistrierung abnehmen, bevor die nächste Gruppe umgestellt wird.

Hardware- oder Software-Token manuell bereitstellen

Auch im manuellen Modus zuerst Specific users and groups mit der Pilotgruppe sowie die benötigten Dienste unter Require MFA for festlegen, den kompatiblen Algorithmus und Timestep wählen und mit Apply speichern. Danach im Add token (for hardware tokens)-Dialog OTP hash algorithm für den neu anzulegenden Token auswählen, bevor Secret, Benutzer und gegebenenfalls Use custom timestep ausgefüllt und mit Save gespeichert werden. Die Auswahl eines globalen Defaults allein ersetzt weder die Token-Zuweisung noch den anschliessenden Pilotlogin.

Soll die Firewall keinen QR-Code erzeugen, bleibt Generate OTP token with next sign-in deaktiviert. Bereits registrierte Token funktionieren weiter; für neue Benutzer wird der Seed unter Authentication > Multi-factor authentication > Issued tokens > Add token (for hardware tokens) manuell hinterlegt. Der Name der Schaltfläche ist enger als die Funktion, denn derselbe Dialog lässt sich auch für einen manuell provisionierten Software-Token verwenden.

Zuerst werden OTP hash algorithm und Timestep so gewählt, wie es der konkrete Token beziehungsweise die Authenticator-App verlangt. Danach gilt für Secret:

• Bei einem Hardware-Token wird der individuelle Schlüssel des Herstellers eingetragen.
• Bei einem Software-Token wird ein einmaliger, ausreichend zufälliger hexadezimaler Seed verwendet. Benötigt die App Base32, wird dieser Seed mit einem kontrollierten Offline-Werkzeug lokal umgewandelt.
• Ein produktiver Seed gehört weder auf eine öffentliche Konverter-Webseite noch in ein Ticket, eine unverschlüsselte E-Mail oder ein Shell-Kommando, das im Verlauf gespeichert wird. Wer den Seed kennt, kann gültige OTP-Codes erzeugen.

Weicht der einzelne Token vom globalen Default token timestep ab, wird Use custom timestep nur für diesen Token aktiviert und das tatsächlich unterstützte Intervall eingetragen. Ohne diese Option gilt der globale Standard; die App- und Hardware-Kompatibilität wird vor dem Speichern geprüft.

Anschliessend wird der exakt vorgesehene Benutzer ausgewählt und mit Save gespeichert. Die Übergabe des Hardware-Tokens beziehungsweise des Base32-Seeds erfolgt einmalig über einen geschützten Kanal. Danach werden ein korrekter und ein bewusst falscher Passcode getestet und unter Issued tokens bei Bedarf der Zeitoffset synchronisiert. War der Seed möglicherweise offengelegt, wird der Token nicht weiterverwendet, sondern gelöscht und mit einem neuen Seed ausgegeben.

API-Automation: Einstellungen und Token-Zustand trennen

Bei API-Automation sind OTPSettings und OTPTokens zwei verschiedene Aufgaben: Die Einstellungen legen MFA-Geltungsbereich, Dienste und globale Vorgaben fest; der Token-Datensatz gehört zu einem einzelnen ausgestellten Token. Eine Einstellungsänderung ersetzt weder Benutzerzuweisung noch Registrierung oder Pilotlogin.

Unter OTPSettings verwendet man die dokumentierten Schalterwerte 0 und 1, nicht GUI-Bezeichnungen oder Enable/Disable:

• otp schaltet OTP aus oder ein. allUsers=0 begrenzt den Geltungsbereich auf explizit ausgewählte Benutzer oder Gruppen; es schaltet OTP nicht selbst ein. Für den Pilot bleibt die Auswahl eng, statt allUsers=1 zu setzen. Das Beispiel zeigt die Auswahl unter otpUsers/user, die Parametertabelle definiert dafür aber keine Benutzer-ID-Kodierung. Keine Identitäten aus Namen oder vermuteten IDs konstruieren.
• tokenAutoCreation steuert die automatische Token-Erzeugung, nicht den Zustand eines bereits ausgestellten Tokens. otpUserPortal, otpVPNPortal, otpSSLVPN, otpWebAdmin und otpIPsec stehen für User Portal, VPN Portal, SSL VPN Remote Access, WebAdmin und IPsec Remote Access. Nur die benötigten Dienste auswählen; die automatische User-Portal-Auswahl des GUI-Ablaufs bleibt bei der Kontrolle zu beachten.
• Nur SFOS 23 dokumentiert das optionale qrCodeVia mit exakt email oder portal. Die GUI-Beschriftungen Email und Portals sind keine wörtlichen API-Werte. Ein API-Default ist nicht dokumentiert; in der SFOS-22-Referenz fehlt dieses Feld.

Die Zeitwerte getrennt behandeln: OTPSettings/defaultTimeStep ist das globale Token-Intervall, OTPSettings/maxTimeStepsInterval das laufende Verifikationsfenster und OTPSettings/maxInitialTimeStepDiff das Fenster bei der ersten Verwendung. OTPTokens/timeStep ist dagegen das Intervall des einzelnen Tokens. Die API nennt dafür jeweils 10–300 Sekunden, 0–10 Zeitschritte, 0–600 Zeitschritte und 10–300 Sekunden als Validierungsgrenzen. Das sind weder Betriebsempfehlungen noch API-Defaults; die Default-Spalten sind leer. Die oben beschriebenen GUI-Defaults und die App-Kompatibilität bleiben davon getrennt.

Beim Token betreffen active, autoCreated und lastLogin dessen Status beziehungsweise Herkunft und letzte erfolgreiche Anmeldung, nicht die globale MFA-Auswahl. lastLogin oder autoCreated nicht als Pflichtfelder einer Automatisierung befüllen. Auch das Token-Beispiel ist kein validiertes Importschema: Es verwendet OTPTokens/user, während die Tabelle userid nennt. Sophos verlangt beim API-Import in der MFA-Hilfe ein leeres <tokenid/>; das Token-Beispiel zeigt es ebenfalls, die API-Tabelle nennt jedoch eine Mindestlänge von 1 Zeichen. Diesen Widerspruch nicht durch erfundene IDs oder ein vermeintlich allgemein gültiges Schreibschema auflösen.

XML-Delete ist kein Token-Import. Die Referenz Delete OTP Token für SFOS 22 und SFOS 23 identifiziert einen vorhandenen Token über tokenid; dokumentiert ist ein einzelner String mit 1–32 Zeichen. Vor einer Löschung liest man den gespeicherten Token-Datensatz aus einer vertrauenswürdigen aktuellen Ansicht aus und prüft dessen Kennung und Zuordnung zum exakt vorgesehenen Benutzer. Weder user noch userid noch das leere <tokenid/> aus der Import-Anleitung ersetzen diese Löschkennung. Die Tabellenangabe Mandatory: No ist keine Freigabe, die Kennung wegzulassen, zu erfinden oder aus einem Benutzernamen abzuleiten. Sind Identität oder versionspassendes Schema unklar, wird nicht gelöscht, sondern zuerst die Zuordnung beziehungsweise das Schema geklärt.

Vor XML-Delete bleiben der getestete Fallback, Management- und Konsolenzugang verfügbar; die oben beschriebene Benutzerprüfung und Vorbereitung der automatischen oder manuellen Neuausgabe gelten unverändert. Ebenso bleiben die Einschränkungen für den Default-Admin bestehen. Nach dem Aufruf liest man den Token-Bestand erneut und prüft, dass genau der vorgesehene alte Token nicht mehr vorhanden ist und andere Token unverändert geblieben sind. Anschliessend folgt die vorbereitete Neuausgabe mit einer frischen erfolgreichen MFA-Anmeldung; der Fallback bleibt bis zur Abnahme verfügbar. Eine Antwort allein ersetzt weder diese Bestandskontrolle noch den MFA-Test.

Die Delete-Referenz führt 200 mit dem nicht aufgelösten Nachrichtensymbol OTPTokenDeleted und 500 mit OTPTokenNotThere auf. Das sind Dokumentationsangaben, keine bestätigten Laufzeitmeldungen oder Garantien für einen HTTP-Status, Wiederholbarkeit oder einen sicheren automatischen Retry. Daraus wird weder ein ausführbarer XML-Request noch ein Request-Umschlag abgeleitet.

Der API-Import ist nicht mit dem manuellen Add token-Dialog gleichzusetzen. Vor einem produktiven Import Backup und zulässigen API-Zugriff prüfen, das versionspassende Schema klären und keine Seeds in ungeschützten Request-Logs speichern. Anschliessend gespeicherte Einstellungen, enge Benutzerauswahl, Dienstzuordnung und Token-Status kontrollieren sowie den beschriebenen Pilotlogin prüfen. Ein erfolgreicher API-Aufruf allein ist keine MFA-Abnahme.

Zusätzliche Einmalcodes kontrolliert ausgeben

Fehlt der Zugriff auf App oder Hardware-Token nur vorübergehend, wird unter Authentication > Multi-factor authentication > Issued tokens der betroffene Benutzer bearbeitet. Unter Additional codes erzeugt die Plus-Schaltfläche zusätzliche Passcodes; mit Save werden sie dem Token zugeordnet. Die Firewall löscht jeden dieser Codes automatisch aus der Liste, sobald er verwendet wurde.

Vor der Ausgabe wird die Identität des Benutzers geprüft. Die Codes werden einmalig über einen geschützten Kanal an genau diesen Benutzer übergeben und nicht gemeinsam in einem ungeschützten Ticket oder einer E-Mail abgelegt. Bei dauerhaft verlorenem oder möglicherweise kopiertem Token ersetzen zusätzliche Codes keine Neuausgabe: Der alte Token wird gelöscht und mit einem neuen Seed registriert.

App und Hash-Algorithmus müssen zusammenpassen

SFOS 22 unterstützt SHA1, SHA256 und SHA512. Sophos empfiehlt SHA256 oder SHA512, aber der gewählte Algorithmus muss von der App unterstützt werden:

• Sophos Intercept X for Mobile und Google Authenticator unterstützen SHA256 und SHA512.
• Microsoft Authenticator unterstützt diese beiden Algorithmen in diesem Sophos-Workflow nicht. Ein QR-Scan kann trotzdem gelingen, der Login schlägt danach aber fehl.
• Duo Mobile und Okta Verify gehören zu den von Sophos aufgeführten Apps; ihre QR- und Algorithmus-Eignung muss zum verwendeten Betriebssystem und zur Konfiguration passen.
• Andere TOTP-Apps werden erst nach einem realen Pilot-Test freigegeben.

Sophos Intercept X for Mobile unterstützt einen benutzerdefinierten Token-Timestep. Die meisten anderen Authenticator-Apps unterstützen nur den Standard von 30 Sekunden; deshalb wird der globale Wert nicht allein für eine einzelne App verändert.

Unter iOS funktioniert der Sophos-QR-Scan mit Google Authenticator, Duo Mobile und Microsoft Authenticator nicht. Das Konto wird dort mit dem angezeigten Base32-Schlüssel manuell angelegt. Bei Okta Verify ist die manuelle Base32-Aufnahme unter iOS und Android nötig. Sie behebt bei Microsoft Authenticator jedoch nicht die fehlende SHA256-/SHA512-Unterstützung.

Die frühere Sophos Authenticator App ist seit dem 31. Juli 2022 End of Life und sollte nicht mehr für neue Rollouts eingeplant werden.

Nach einem Upgrade von einer Version vor SFOS 22 muss mit bestehenden SHA1-Token gerechnet werden, weil frühere SFOS-Versionen MFA-Token mit SHA1 erzeugten. Die Auswahl eines stärkeren globalen Algorithmus konvertiert diese bestehenden Token nicht.

Für eine Migration von SHA1 auf einen stärkeren Algorithmus:

1. Pilot-App mit SHA256 oder SHA512 testen.
2. Generate OTP token with next sign-in aktivieren. Unter SFOS 23 vor Apply auch Share QR code mit Email oder Portals wählen.
3. Den neuen Algorithmus unter Authentication > Multi-factor authentication auswählen.
4. Mit Apply speichern.
5. Alte SHA1-Token unter Issued tokens löschen. Für den Token des default admin muss man als dieser Benutzer angemeldet sein; ein anderer Administrator kann ihn nicht löschen. Vorher bleiben getesteter Fallback und Konsolenzugang bereit.
6. Normale Benutzer nur mit Passwort am VPN Portal oder User Portal anmelden und QR-Code beziehungsweise Base32-Schlüssel in einer App mit SHA256-/SHA512-Unterstützung neu registrieren lassen. Unter SFOS 23 erfolgt die QR-Zustellung gemäss Email oder Portals. Für den default admin erfolgt die Neuregistrierung nach dem Löschen dagegen durch eine Passwort-only-Anmeldung am WebAdmin, nicht am Benutzer- oder VPN-Portal; dem dort angezeigten Registrierungsablauf folgen. Dies ist die SHA-Migration, nicht Use an existing token im Reaktivierungsassistenten. Für diesen Sonderfall wird kein zusätzlicher Share QR code-Selektor im Assistenten vorausgesetzt.
7. Login mit richtigem und falschem Passcode kontrolliert testen.

Token mit unterschiedlichen Algorithmen können während der Migration parallel existieren. Nicht gelöschte Token verwenden jedoch weiterhin ihren alten Algorithmus.

Zeitschritt und Toleranzfenster begrenzen

Unter OTP timestep settings steuert man neben dem Intervall für neue Codes auch zwei Verifikationsfenster. Die drei Werte haben unterschiedliche Wirkungen:

• Default token timestep legt das Intervall fest, in dem App oder Hardware-Token einen neuen Code erzeugen. Der Standard beträgt 30 Sekunden. Eine Änderung gilt nur für neu erzeugte Token und verändert bestehende Token nicht.
• Maximum verification code offset bestimmt, wie viele Zeitschritte ein noch nicht verwendeter Code gültig bleibt. Der Standardwert 2 erlaubt bei 30 Sekunden auch unbenutzte Codes aus den vorherigen 60 Sekunden.
• Maximum initial verification code offset gilt für den ersten Code nach dem Scan des QR-Codes. Der Standardwert 10 ergibt bei 30 Sekunden ein Fenster von 300 Sekunden, sofern der Code noch nicht verwendet wurde.

Diese Fenster ersetzen keine korrekte Uhrzeit. Zuerst werden NTP der Firewall und Zeit des Endgeräts geprüft; danach bleibt jeder Offset so klein wie mit den eingesetzten Apps und Hardware-Token praktikabel. Ein grösseres Fenster akzeptiert einen abgefangenen, noch unbenutzten Code entsprechend länger. Nach einer Änderung wird ein neu ausgestellter Pilot-Token getestet; bei bestehenden Token wird kein geänderter Timestep vorausgesetzt.

Passwort und OTP richtig eingeben

Für native Sophos-OTP-Anmeldungen lautet das offizielle Format <password><passcode>, ohne Leerzeichen oder Trennzeichen.

Beispiel:

Passwort: MeinSicheresPasswort
OTP-Code: 123456
Eingabe:  MeinSicheresPasswort123456

Sophos Connect kann über otp: true ein separates drittes Eingabefeld anzeigen. Der Client hängt den Code intern an das Passwort an. Diese Darstellung ändert das Format, das an den Authentifizierungsserver gesendet wird, nicht.

Default-Admin absichern und wiederherstellen

MFA für den default admin aktivieren

Der lokale default Benutzer admin wird nicht über die normale Benutzerliste aktiviert. Sein eigener Assistent liegt unter Administration > Device access, nicht unter Issued tokens > Add token (for hardware tokens) für normale Benutzer.

Vorher müssen zweiter Administrator, Managementzugriff und Konsolenzugang funktionieren. Zusätzliche Einmalcodes werden sicher, beispielsweise in einem Passwortmanager, hinterlegt. Der default admin bleibt ein Notfallkonto und wird nicht für tägliche Administration verwendet.

Andere Administratoren können den Token des default admin weder aktivieren oder deaktivieren noch bearbeiten oder löschen. Der gewählte globale OTP hash algorithm gilt auch für diesen Token.

Vor dem Start prüft man zusätzlich Uhrzeit, App-/Hardware-Kompatibilität und Block login wie oben beschrieben. Der Algorithmus für neue Hardware- und Software-Token wird aus Authentication > Multi-factor authentication > OTP hash algorithm übernommen; er wird nicht unabhängig im Default-Admin-Assistenten gewählt. Ein erfolgreicher QR-Scan beweist keine Algorithmus-Kompatibilität. Die oben beschriebenen App- und Base32-Einschränkungen gelten weiterhin.

1. Als default admin am WebAdmin anmelden und Administration > Device access öffnen.
2. MFA for default admin einschalten und Apply anklicken.
3. Im Assistenten die passende Token-Methode auswählen und Next anklicken. Anschliessend den zutreffenden Zweig abschliessen:

• Configure a hardware token: Den individuellen Schlüssel des Geräteherstellers und den zum Hardware-Token passenden Zeitschritt eintragen. Mit Next fortfahren und das Passwort des default admin unmittelbar gefolgt vom aktuellen Hardware-Passcode als <password><passcode> eingeben, ohne Leer- oder Trennzeichen. Validate anklicken und nach erfolgreicher Validierung mit Apply abschliessen.
• Generate a software token: Eine kompatible Authenticator-App auf dem Mobilgerät installieren und den angezeigten QR-Code scannen. Das Passwort des default admin unmittelbar gefolgt vom aktuellen App-Passcode als <password><passcode> eingeben. Validate anklicken und nach erfolgreicher Validierung mit Apply abschliessen.
• Use an existing token: Ist bereits ein Hardware- oder Software-Token für den default admin vorhanden und wird MFA nur wieder eingeschaltet, diesen Zweig wählen und Passwort plus aktuellen Passcode unmittelbar hintereinander eingeben. Soll stattdessen ein neuer Software-Token eingerichtet werden, Generate a software token wählen und den QR-Code in der App registrieren. Diese Wahl ist keine Migration bestehender SHA1-Benutzertoken.

Das erste Apply startet den Einrichtungsablauf; bei den neuen Hardware- und Software-Token gehören Validate und das abschliessende Apply weiterhin dazu. Bei fehlgeschlagener Validierung zunächst Passwort-plus-Passcode, Uhrzeit, Zeitschritt und Algorithmus prüfen, statt wiederholt zu raten. Die bestehende Sitzung während der Prüfung offenhalten und nach Abschluss eine separate frische WebAdmin-Sitzung als default admin mit Passwort plus neuem Passcode testen. Erst nach erfolgreichem Login und sicher hinterlegten Einmalcodes die Einrichtung als abgeschlossen betrachten; der zweite Administrator ersetzt nicht die Default-Admin-Tokenverwaltung oder den beschriebenen Konsolen-Recovery-Weg.

Recovery über CLI Main Menu > 2. System Configuration

Die Recovery-Optionen liegen unter CLI Main Menu > 2. System Configuration, nicht in 4. Device Console. Befindet man sich bereits in der Device Console, kehrt man zuerst zum Main Menu zurück und wählt dort 2 für System Configuration.

Die Menüpunkte 6 und 7 erscheinen nur, wenn MFA for default admin unter Administration > Device access bereits konfiguriert ist. Fehlen sie, ist das nicht automatisch ein Console-Fehler; zuerst werden diese Einstellung und der tatsächlich verwendete default Benutzer admin geprüft. Die Optionen gelten nicht für andere Administratorkonten.

Fehlt der Token nur vorübergehend, kann man unter CLI Main Menu > 2. System Configuration genau die nächste WebAdmin-Anmeldung des default admin ohne MFA erlauben:

1. Im CLI Main Menu 2 für System Configuration eingeben.
2. 6 für Skip multi-factor authentication for next Admin user login eingeben.
3. Am WebAdmin einmal nur mit dem Passwort des default admin anmelden und den Token prüfen. Den getesteten Fallback und den Konsolenzugang weiterhin bereithalten.
4. Danach eine separate frische WebAdmin-Sitzung als default admin mit Passwort plus aktuellem Passcode im Format <password><passcode> öffnen. Erst nach erfolgreicher MFA-Anmeldung ist die Recovery abgeschlossen; das Ergebnis dokumentieren und den Fallback bis dahin verfügbar halten.

Bleibt der Token unbrauchbar, folgt man dem nachstehenden Reset- und Neuregistrierungsablauf und prüft danach erneut eine frische MFA-Anmeldung. Der Skip gilt nur für die nächste Anmeldung; weder No OTP für alle noch eine breitere WAN-Freigabe sind ein Ersatz für diese Kontrolle.

Bei verlorenem Gerät oder dauerhaft unbrauchbarem Token wird MFA zurückgesetzt:

1. Im CLI Main Menu 2 für System Configuration eingeben.
2. 7 für Reset multi-factor authentication for Admin user eingeben.
3. Mit y bestätigen.
4. Am WebAdmin einmal nur mit dem Admin-Passwort anmelden.
5. Den Anweisungen zur neuen MFA-Registrierung folgen und anschliessend wieder mit MFA testen.

Diese beiden Optionen ändern nur den MFA-Zustand. Ist auch das Passwort des Default-Admins unbekannt, erklärt der separate Passwort-Recovery-Artikel den dokumentierten seriellen Weg für physische Appliances und die Grenzen bei einem kombinierten Passwort- und MFA-Verlust.

Testen, Logs prüfen und ausrollen

Jeden Dienst separat testen

Ein erfolgreicher WebAdmin-Login beweist nicht, dass Portale und VPN-Clients gleich funktionieren. Vor dem breiten Rollout prüft man:

• WebAdmin: Pilot-Admin mit richtigem und kontrolliert falschem OTP anmelden.
• Default admin: separaten Device-Access-Pfad und dokumentierten Recovery-Weg prüfen.
• User Portal und VPN Portal: QR- beziehungsweise Base32-Aufnahme sowie Login mit <password><passcode> testen.
• SSL VPN und IPsec Remote Access: echte Clients und genau die produktiv verwendete Benutzergruppe testen.
• Sophos Connect: gegebenenfalls drittes OTP-Feld, aktuelle Clientprofile sowie Call-/Push-Verhalten prüfen.
• RADIUS oder Entra SSO: Timeouts, IdP-Logs und das tatsächlich unterstützte Challenge-Verhalten prüfen.
• Device Access: Zugriff aus erlaubtem und nicht erlaubtem Quellnetz testen.

Fehlversuche werden nur in kontrollierter Zahl ausgeführt, nachdem Block login geprüft wurde. Das erwartete Ergebnis ist nicht nur ein erfolgreicher Login: Ein falscher Code muss abgelehnt, der Versuch geloggt und der Dienst ausschliesslich aus den vorgesehenen Netzen erreichbar sein.

Authentifizierungslogs richtig lesen

Im Log viewer prüft man erfolgreiche und fehlgeschlagene Anmeldungen mit Dienst, Benutzer, Quelle, Uhrzeit und dokumentiertem Grund. Je nach Ereignis liefert SFOS nur einen generischen Hinweis wie falsche Zugangsdaten. Ohne zusätzlichen Nachweis sollte man daraus nicht ableiten, ob Passwort, OTP oder abgelaufener Code allein die Ursache war.

Bei externer MFA gehören RADIUS-, NPS- oder IdP-Logs zur selben Prüfung. Für lokale Logdateien und Service-Zuordnung hilft Sophos Firewall Troubleshooting: Services und Logs. Für längere Aufbewahrung und Korrelation eignet sich Sophos Firewall Syslog an SIEM senden.

Vor dem breiten Rollout

Scheitert der Pilot, wird der Rollout angehalten. Über den getesteten zweiten Administrator lässt sich die normale Pilot-Auswahl unter Specific users and groups auf den dokumentierten Ausgangsstand zurücksetzen; das betrifft weder den separaten Default-Admin-Assistenten noch stellt es gelöschte Token wieder her. Bei externen Gruppen bleibt die oben erklärte zusätzliche MFA-Anmeldung zu beachten. Weder No OTP für alle noch eine breite WAN-Freigabe als pauschalen Reparaturweg verwenden. Nach einer Korrektur die betroffenen Dienste in frischen Sitzungen erneut testen.

• Pilotgruppe mit allen benötigten Diensten erfolgreich getestet.
• Zweiter Administrator, Einmalcodes und Recovery über CLI Main Menu > 2. System Configuration dokumentiert.
• Benutzer über Einrichtung in der Authenticator-App und Passwort-plus-OTP informiert.
• Token-Reset für verlorene oder neue Smartphones geregelt.
• Device Access, Login-Sperren und zentrale Log-Aufbewahrung geprüft.
• Bei externer MFA Zuständigkeit, Timeouts und Fallback festgelegt.

Troubleshooting

Token, QR-Code und Eingabe

OTP-Code wird nicht akzeptiert

Zuerst Uhrzeit von Firewall und Smartphone, verwendete App, Hash-Algorithmus und Zeitschritt vergleichen. Unter Issued tokens kann man den Zeitoffset prüfen und synchronisieren. Bei einer Algorithmusmigration muss der alte Token gelöscht und neu registriert worden sein.

Zum Synchronisieren öffnet man Authentication > Multi-factor authentication > Issued tokens, wählt beim betroffenen Token Synchronize token time offset, gibt den aktuell von App oder Hardware-Token erzeugten Passcode ein und klickt Check. Der Zeitoffset wird mit der Firewall synchronisiert und die Zeitabweichung korrigiert. Danach eine frische Anmeldung kontrolliert testen; Fallback bereithalten und Block login vor weiteren Fehlversuchen beachten.

Ein Wechsel des NTP-Servers sollte separat geplant werden, weil die Firewall dabei bestehende IPsec-Tunnel neu verbindet.

QR-Code erscheint nicht oder lässt sich nicht scannen

Der Benutzer muss zur ausgewählten MFA-Gruppe gehören und sich am VPN Portal oder User Portal anmelden. Unter SFOS 22 können Administratoren bei aktivierter WebAdmin-MFA auch dort registrieren. Unter SFOS 23 zuerst Share QR code prüfen: Bei Email wird nach dem Portal-Login der Posteingang statt einer QR-Anzeige im Portal geprüft; bei Portals wird der QR-Code in den Portalen angezeigt, auch nach einem auslösenden WebAdmin-Login. Zusätzlich müssen Portal und Quelle unter Administration > Device access erlaubt sein. Bei der Erstregistrierung oder beim App-Ersatz unter SFOS 23 mit aktivierter Token-Erzeugung gilt auch die oben erklärte 24-Stunden-Laufzeit: Wurde der QR-Code in dieser Zeit nicht zur Anmeldung verwendet, nur mit dem Passwort am VPN Portal oder User Portal anmelden und den neuen QR-Code gemäss Email oder Portals registrieren.

Unter iOS beziehungsweise bei Okta Verify verwendet man bei den genannten Einschränkungen den Base32-Schlüssel statt des QR-Scans.

Anmeldung meldet falsches Passwort

Bei nativer Sophos-OTP-Anmeldung muss die Eingabe exakt aus Passwort und unmittelbar angehängtem Passcode bestehen. Ohne separates OTP-Feld ist nur das Passwort unvollständig.

Zugriff, Gruppen und Remote Access

Portal ist nicht erreichbar

Zuerst Zone, Quelle und den benötigten Dienst unter Administration > Device access prüfen. Eine enge Local Service ACL Exception Rule ist sicherer als eine pauschale WAN-Freigabe.

MFA greift nicht für Remote Access

MFA- und Remote-Access-Konfiguration müssen dieselbe tatsächlich importierte Benutzergruppe verwenden. Danach Clientprofil neu importieren beziehungsweise verteilen und die Verbindung mit dem echten Client testen. Vor der ersten VPN-Verbindung muss der Token am VPN Portal oder User Portal registriert sein.

MFA gilt nur für einen Teil der Benutzer

Nicht nur sichtbare Gruppennamen vergleichen, sondern die aus AD, LDAP, RADIUS oder Entra ID tatsächlich gematchten Gruppen. Nach dem Entfernen eines AD-Benutzers aus einer MFA-Gruppe kann noch eine letzte Anmeldung mit MFA nötig sein; erst folgende Logins benötigen keinen OTP mehr.

Lockout und externe MFA

Administrator ist ausgesperrt

Für den default admin verwendet man die oben beschriebenen Optionen 6 oder 7 unter CLI Main Menu > 2. System Configuration. Bei einem anderen Admin wird der vorbereitete zweite Administrator aus einer erlaubten Quelle verwendet und danach Gruppen-, Token- und Login-Sperrstatus geprüft.

RADIUS- oder Entra-MFA funktioniert nicht zuverlässig

RADIUS-Timeouts, IdP-Logs, Gruppen und das Challenge-Verhalten des konkreten Dienstes prüfen. Ein erfolgreicher Test des Authentifizierungsservers beweist noch keinen produktiven Login über VPN Portal, Sophos Connect oder WebAdmin. Jeder dieser Wege wird separat getestet.