Sophos Firewall Authentifizierungsfehler systematisch beheben

Ein Authentifizierungsfehler auf der Sophos Firewall kann an sehr unterschiedlichen Stellen entstehen. Der Server ist vielleicht erreichbar, aber nicht für den betroffenen Dienst ausgewählt. Die Anmeldung kann funktionieren, während Main Group, Quota oder Firewall-Regel den Zugriff verhindern. Oder die Firewall sieht den Benutzer gar nicht und verarbeitet den Traffic nur anhand seiner IP-Adresse.

Der sichere Schnellweg trennt diese Ebenen bewusst:

1. Benutzer, Quell-IP, betroffenen Dienst, Uhrzeit und erwartetes Ergebnis notieren.
2. Erreichbarkeit des Portals oder Authentifizierungsdienstes aus der echten Quellzone prüfen.
3. Unter Authentication > Services kontrollieren, ob der richtige Server beim betroffenen Dienst ausgewählt ist und an der vorgesehenen Position steht.
4. Test connection am Authentifizierungsserver ausführen, aber nur als Nachweis für Zugangsdaten und Serververbindung werten.
5. Einen frischen Login erzeugen und unter Current activities > Live users Benutzer, Quell-IP und Client Type prüfen.
6. Unter Authentication > Users Status, Main Group, weitere Gruppen, Benutzer-Overrides und User ID kontrollieren.
7. Access Time, Quoten, MFA und Sign-in Restrictions nur beim tatsächlich betroffenen Benutzer beziehungsweise seiner wirksamen Gruppe prüfen.
8. Erst nach erfolgreicher Identität die erwartete Firewall-Regel, Rule ID, Web- oder VPN-Policy, NAT und Routing mit echtem Traffic testen.

⚠️ Authentifizierungsserver, Gruppenreihenfolge, Quoten und Device Access nicht auf Verdacht breit ändern. Ein Service-Restart, Purge AD users oder eine Any-Regel ist kein normaler erster Diagnoseschritt. Zuerst wird belegt, an welcher Ebene der Ablauf abbricht.

Fünf Ebenen statt eines einzigen Login-Fehlers

In der Praxis hilft ein einfaches Modell. Ein Benutzerzugriff durchläuft nicht nur eine einzige Prüfung, sondern mindestens fünf getrennte Ebenen:

1. Erreichbarkeit: Client und Firewall erreichen das Portal, den Proxy oder den Authentifizierungsserver über den vorgesehenen Pfad.
2. Dienst und Methode: Der richtige Authentifizierungsserver ist unter Authentication > Services für genau diesen Dienst ausgewählt.
3. Identität: Die Firewall erkennt den erwarteten Benutzer und zeigt ihn mit der richtigen Quell-IP sowie dem passenden Client Type.
4. Autorisierung: Benutzerstatus, Gruppe, Main Group, Access Time, Quota, MFA und dienstspezifische Berechtigungen passen.
5. Folge-Traffic: Eine Firewall-Regel, Web Policy oder VPN-Policy erlaubt die gewünschten Ziele und der Rückweg funktioniert.

Diese Trennung verhindert zwei häufige Fehlschlüsse. Ein grüner Test connection beweist keine funktionierende SSO-Anmeldung. Umgekehrt beweist ein Benutzer unter Live users noch nicht, dass sein Traffic die beabsichtigte Regel oder Policy trifft.

Einen reproduzierbaren Testfall festlegen

Vor der ersten Änderung wird ein einzelner Testfall definiert. Als sichere Dokumentationswerte eignen sich beispielsweise:

• Benutzer: auth-pilot@example.com
• Client-IP: 192.0.2.25
• Quellzone: LAN
• Dienst: Firewall authentication, User portal, VPN portal, SSL VPN oder Web admin console
• Testzeit: lokale Firewall-Zeit mit Datum und Minute
• erwartete Gruppe: Internet-Standard
• erwartete Regel: LAN-Users-to-WAN
• erwartetes Ergebnis: erfolgreicher Login und HTTPS-Zugriff auf ein definiertes Testziel

example.com und 192.0.2.0/24 sind Dokumentationswerte. Benutzername, Quell-IP, Zone, Gruppe, Regel und Ziel werden durch reale Pilotwerte ersetzt. Der Pilot sollte die gleiche Authentifizierungsquelle und Berechtigungsgruppe wie der betroffene Benutzer verwenden, aber keine unnötigen Administratorrechte besitzen.

Wenn möglich, wird zusätzlich ein funktionierender Vergleichsbenutzer aus derselben Quelle getestet. Funktionieren beide nicht, liegt die Ursache eher bei Dienst, Server oder Erreichbarkeit. Scheitert nur ein Benutzer, sind Benutzerobjekt, Gruppen, Quoten, MFA oder Sign-in Restrictions wahrscheinlicher.

Dienst, Erreichbarkeit und Server prüfen

Device Access nur für den benötigten Dienst kontrollieren

Portale und lokale Authentifizierungsdienste werden nicht durch normale Firewall-Regeln freigegeben. Unter Administration > Device access beziehungsweise mit einer gezielten Local service ACL exception rule muss der benötigte Dienst aus der vorgesehenen Quellzone oder von den bekannten Quellnetzen erreichbar sein.

Je nach Test sind unterschiedliche Einträge relevant, beispielsweise Captive portal, User portal, VPN portal, SSL VPN, AD SSO oder Client Authentication. Nur der tatsächlich benötigte Dienst wird geprüft. Eine pauschale Freigabe für LAN oder WAN würde das Fehlerbild verdecken und kann zusätzliche Management- oder Portaldienste exponieren. Die sichere Abgrenzung erklärt Device Access und Local Service ACL auf Sophos Firewall.

Erreichbarkeit allein ist noch keine Authentifizierung. Eine sichtbare Portalseite bestätigt nur, dass der Client den lokalen Dienst erreicht. Benutzername, Passwort, SSO-Token, Gruppe und spätere Firewall-Regel sind damit noch nicht geprüft.

Authentifizierungsmethode pro Dienst prüfen

Unter Authentication > Services besitzt jeder Dienst seine eigene Serverauswahl. Deshalb wird nicht nur nachgesehen, ob ein AD-, LDAP-, RADIUS- oder Entra-Server existiert, sondern ob er beim betroffenen Dienst ausgewählt ist:

• Firewall authentication methods für Benutzertraffic und klassische Firewall-Authentifizierung;
• User portal authentication methods für das User Portal;
• VPN portal authentication methods für das VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods für diese VPN-Anmeldungen;
• Administrator authentication methods für benannte Administratoren;
• SSL VPN authentication methods für SSL VPN.

Die Firewall unterstützt insgesamt höchstens 20 Authentifizierungsserver; auch pro Authentifizierungsmethode lassen sich höchstens 20 Server auswählen. Fehlt ein weiterer Server beim Anlegen oder in der Auswahl, ist das deshalb nicht automatisch ein Verbindungsfehler. Zuerst werden Gesamtzahl, Auswahl und tatsächlicher Bedarf geprüft.

User Portal und VPN Portal können mit Set authentication methods same as firewall die Serverliste der Firewall-Authentifizierung übernehmen. SSL VPN kann entsprechend Same as VPN oder Same as firewall verwenden. Diese Vererbung ist bequem, erweitert aber die Wirkung einer späteren Änderung an Reihenfolge oder Serverauswahl. Für die Diagnose wird deshalb immer die effektiv geerbte Liste dokumentiert. Administrator authentication methods gelten zudem nicht für den lokalen Super-Administrator admin; sein getesteter Rückweg bleibt getrennt erhalten.

Globale Session-Grenzen separat prüfen: Maximum session timeout beendet eine erfolgreich angemeldete Session nach der maximalen Dauer. SFOS prüft die Autorisierung alle drei Minuten; Access Policies, Surfing Quota, Data Transfer Limit und die maximale Sessiondauer können den Zugriff früher begrenzen. Der globale Wert Simultaneous logins gilt nur für Benutzer, die nach dem Setzen des Werts angelegt werden.

Endliche API-Grenzen und Unlimited unterscheiden: Die Legacy-XML-API-Dokumentation für SFOS 22 und SFOS 23 nennt für MaximumSessionTimeoutMinutes einen endlichen Bereich von 3–1440 Minuten und für SimultaneousLogins von 1–99 gleichzeitigen Anmeldungen. Das Beispiel zeigt dagegen Unlimited/{minutes} und Unlimited/{count}; die Tabelle führt neben den numerischen INTEGER-Zeilen separate STRING-Zeilen für Unlimited. Die unbeschränkte Alternative lässt sich daraus nicht in ein Unlimited-Attribut oder einen sendefertigen Payload umrechnen. Die Schrägstrichfolgen sind keine Literalwerte für die Produktion. Aus leeren Default-Spalten oder optionalen Feldern folgt weder ein bestimmtes Verhalten beim Auslassen noch, dass null oder leer Unlimited bedeutet. Zuerst die tatsächlich gespeicherte Auswahl und die wirksamen Benutzergrenzen lesen; die globale Login-Grenze gilt weiterhin nur für danach angelegte Benutzer. Unklare Automatisierung vor einer produktiven Schreiboperation für den konkreten Build mit dem Support klären.

In SFOS 22 und SFOS 23 werden auch die methodenspezifischen Werte unter Authentication > Services getrennt geprüft: AD SSO settings (NTLM and Kerberos) und Web client settings (iOS, Android and API) besitzen jeweils Inactivity time und Data transfer threshold. Wird innerhalb der eingestellten Zeit weniger als die minimale Datenmenge übertragen, gilt der Benutzer als inaktiv; Inactivity time legt fest, nach welcher Inaktivitätsdauer er abgemeldet wird. Bei einer unerwarteten Abmeldung zuerst den verwendeten Client Type, beide Werte des passenden Blocks und den tatsächlichen Traffic im gleichen Zeitraum dokumentieren. Nicht stattdessen den globalen Maximum session timeout oder STAS-/Captive-Portal-Timer verändern.

NTLM: Minuten und Bytes vergleichen. Die Legacy-API-Dokumentation für SFOS 22 und SFOS 23 nennt bei NTLMInActivtyTime einen Default von 6 Minuten und den Bereich 6–1440 Minuten, bei NTLMDataTransferThreshold einen Default von 1024 Bytes. Für den Byte-Schwellwert nennt sie nur maximal zehn Ziffern, keinen vollständigen Zahlenbereich; daraus wird kein Minimum oder Maximum abgeleitet. Die Schreibweise InActivty ist wörtlich aus der API übernommen, ebenso NTLMChallegeRedirect für die Challenge-Umleitung: nicht still zu vermeintlich korrekten Schlüsseln umschreiben. Diese Dokumentationswerte sind keine ausgelesenen Werte der eigenen Firewall und kein Grund, produktive Defaults zurückzusetzen oder HTTP challenge redirect on intranet zone abzuschalten.

iOS-Webclient: eigenen dokumentierten Bereich verwenden. Für iOSWebClientInActivtyTime nennt dieselbe Legacy-API-Dokumentation den Default 6 Minuten und den Bereich 6–1440 Minuten; für iOSWebClientDataTransferThreshold den Default 1024 Bytes und den Bereich 1–4294967295 Bytes. Minuten sind nicht Sekunden, Bytes nicht Kilobytes. Auch hier bleibt die API-Schreibweise InActivty unverändert. Die iOS-Operation belegt keine identischen Schlüssel oder Zahlenbereiche für Android oder API-Clients, obwohl die GUI diese Clientarten im gemeinsamen Webclient-Block aufführt.

Für diese Grenzen zuerst nur lesend den gespeicherten Zustand unter Authentication > Services, den tatsächlichen Client Type, Einheiten und – bei einem fehlgeschlagenen API-Versuch – die Anfrage sowie die zugehörige Antwort ohne Geheimnisse vergleichen. Ein abgewiesener Wert beweist nicht, dass er gespeichert wurde; ein dokumentierter Default beweist nicht, dass er aktuell gesetzt ist. Mit einem frischen Pilotlogin, zeitlich zugeordnetem Traffic und den unten beschriebenen Authentication-Logs prüfen, ob die Abmeldung zum tatsächlich gespeicherten Zeit-/Byte-Paar passt. Vor einer freigegebenen Korrektur die bisherigen Werte sichern und einen lokalen Managementzugang prüfen, der nicht von dem untersuchten externen Authentifizierungspfad abhängt. Nachher den gespeicherten Zustand, Pilotlogin, Client Type, Negativtest und Regelmatch erneut kontrollieren. Bei unerwarteter Wirkung nur die dokumentierten betroffenen Werte zurücksetzen und den Zustand erneut lesen, nicht pauschal Reset to default verwenden. Diese API-Grenzen vor jeder Operation mit der Hilfe des installierten Builds abgleichen.

Bei mehreren Servern ist auch die Reihenfolge relevant. Der Server wird nicht vorschnell nach oben verschoben. Zuerst werden aktuelle Reihenfolge, Default Group und der funktionierende Vergleichsbenutzer dokumentiert. Eine Änderung kann sonst weitere Benutzer oder Dienste betreffen. Für externe Administratoren trennt TACACS+ für Sophos Firewall WebAdmin zusätzlich Serverauthentifizierung, lokales Administratorprofil und Lockout-sicheren Fallback.

eDirectory vor dem Upgrade ablösen: Der native eDirectory-Pfad gehört zu SFOS 22. Vor einem Upgrade auf SFOS 23.0 oder neuer muss ein unterstützter Ersatz für alle betroffenen Dienste validiert und die native eDirectory-Konfiguration entfernt sein; bleibt sie bestehen, schlägt das Upgrade fehl. Die produktive Authentifizierung nicht vor der Prüfung von Zielanmeldungen, Gruppen, Policies und unabhängigem lokalem Fallback löschen. eDirectory sicher migrieren beschreibt den kontrollierten Cutover und Rückweg.

VPN-Authentifizierungslisten per XML API einordnen

Bei automatisierten Änderungen werden Dienstwahl und Serverliste getrennt geprüft. Die folgenden XML-Pfade betreffen die Authentifizierungsquelle, nicht VPN-Protokollstärke, Verschlüsselung oder MFA-Konfiguration.

• Für SSL VPN liegt der Selektor unter SSLVPNAuthentication/SSLVPNAuthenticationMethods. In SFOS 22 und SFOS 23 stimmen Beispiel und Parametertabelle überein: SameAsVPN, SameAsFirewall und Custom sind die dokumentierten Werte. Die ersten beiden übernehmen entsprechend die VPN- beziehungsweise Firewall-Authentifizierungsliste; Custom steht für eine eigene Serverauswahl unter SSLVPNAuthentication/SSLVPNAuthenticationServerList/AuthenticationServer.
• Für die übrige VPN-Authentifizierung zeigt das Beispiel unter VPNAuthentication/VPNAuthenticationMethods dagegen SameAsFirewall/Custom, mit der Serverliste unter VPNAuthentication/VPNAuthenticationServerList/AuthenticationServer. Die Parametertabelle kombiniert jedoch VPNAuthenticationMethods/UserPortalAuthenticationMethods und erlaubt nur die als ''on'' und ''off'' geschriebenen Tokens. Dieser Widerspruch besteht in beiden Versionen. Daraus lässt sich keine verifizierte Umrechnung zwischen den Beispielwerten und den Tabellenwerten ableiten; auch eine Alias- oder Selektorkompatibilität mit dem User Portal ist damit nicht belegt. Einen produktiven VPN-Selektor deshalb nicht anhand dieser Zuordnung automatisiert umstellen, sondern den Konflikt für den konkreten Build über den Support klären.

In beiden Serverlisten beschreibt die Tabelle AuthenticationServer als optionales ARRAY mit Datentyp STRING und mehreren möglichen Werten. Servernamen müssen zur eigenen Konfiguration passen. Der SSL-VPN-Selektor ist als optionales SCALAR markiert, der kombinierte VPN-/User-Portal-Tabelleneintrag als verpflichtendes SCALAR. Die Default-Spalten sind leer; daraus folgt kein bestätigtes Verhalten bei ausgelassenen oder leeren Feldern. Die Schrägstrichfolgen im Beispiel sind keine fertigen Werte zum unveränderten Senden.

Vor einer freigegebenen Änderung die aktuelle Auswahl, Reihenfolge, effektiv geerbte Liste und den getesteten lokalen Rückweg sichern. Danach den gespeicherten Zustand unter Authentication > Services, einen frischen Pilotlogin, Client Type, Negativtest und tatsächlichen Regelmatch prüfen. Bei einem unerwarteten Ergebnis den gespeicherten Zustand und die passenden Logs lesen, nicht blind erneut schreiben; bei Bedarf nur die dokumentierte betroffene Konfiguration wiederherstellen. Request, Operationsantwort und tatsächlichen Objektzustand getrennt prüfen.

Test connection richtig einordnen

Unter Authentication > Servers prüft Test connection die Zugangsdaten und die Verbindung zwischen Firewall und Server. Ein Fehler an dieser Stelle wird zuerst bei DNS, Routing, Port, Verbindungssicherheit, Zertifikatskette, Servicekonto oder Kennwort behoben.

Ein erfolgreicher Test ist dagegen nur die erste Ebene. Bei AD SSO prüft er weder Kerberos noch NTLM, SPN, Redirection Location, Browser-Trust oder den tatsächlichen Benutzerzugriff. Auch bei Portal- und VPN-Anmeldungen bleiben Dienstwahl, Gruppe, MFA und Policy separat zu testen. Die vollständige AD-Grundkonfiguration beschreibt Active Directory mit Sophos Firewall verbinden.

Live Users als Identitätsnachweis verwenden

Nach einem frischen Login wird Current activities > Live users geöffnet. Dort sind mindestens drei Angaben wichtig:

Kapazitätsgrenze: SFOS 22 und SFOS 23 unterstützen höchstens 32,000 Live Users. Benutzer und Gruppen teilen sich den User-ID-Bereich; für die Diagnose ist eine sichtbare ID bis 65535 zulässig. In sehr grossen Umgebungen wird diese Grenze getrennt von einem einzelnen fehlgeschlagenen Login geprüft. Sitzungen oder Benutzerobjekte werden nicht unkontrolliert gelöscht.

Beim Client Authentication Agent muss der Clienttyp Authentication agent lauten; zusätzlich werden der Pfad zu 1.2.3.4:9922, die Authentication Server CA und der echte Firewall-Regelmatch separat geprüft.

• User: Entspricht der erkannte Benutzer wirklich dem Pilotkonto?
• IP address: Passt die Adresse zur beobachteten Clientverbindung?
• Client Type: Wurde der erwartete Weg verwendet, beispielsweise AD SSO Kerberos, AD SSO NTLM, STAS, Multi-host client, Web client, RADIUS SSO oder ein VPN-Typ?

Der Typ wird nach seiner Quelle interpretiert und nicht als generischer Login. Browserbasierte Captive-Portal- und Gastsitzungen erscheinen als Web client, Android web client oder iOS web client. Clientseitige Zuordnungen umfassen STAS, Thin client, Heartbeat und API; serverseitiges SSO umfasst RADIUS SSO und Chromebook SSO. eDirectory SSO gehört nur zur SFOS-22-Liste; SFOS 23 entfernt das native eDirectory SSO und führt diesen Typ nicht mehr auf. Bei VPN-Einträgen wird zwischen IPsec VPN, SSL VPN, L2TP VPN und PPTP VPN unterschieden. Der angezeigte Typ muss dem vorgesehenen Mechanismus entsprechen.

Clientless Users sind die Ausnahme beim Test mit einem frischen Login: Sie erscheinen direkt nach der Konfiguration in der Liste, weil SFOS sie anhand ihrer IP-Adresse authentifiziert, und werden im Status Inactive nicht angezeigt.

Fehlt der Benutzer, ist die Identitätsebene noch nicht erfolgreich. Dann wird nicht an der späteren Benutzerregel weitergesucht. Erscheint ein Computername statt des angemeldeten Benutzers, kann ein Betriebssystemdienst wie Windows Update NTLM-Zugangsdaten des Geräts gesendet haben. Ein echter interaktiver Benutzerlogin und ein neuer Webzugriff grenzen diesen Fall ein.

Ein externer AD-, LDAP- oder RADIUS-Benutzer erscheint unter Authentication > Users normalerweise erst nach seiner ersten erfolgreichen Anmeldung an einem Firewall-Dienst. Ein fehlender lokaler Benutzerdatensatz beweist deshalb nicht, dass das Konto im Verzeichnis fehlt. Bei einem direkt auf SFOS gepflegten Konto erklärt normale lokale Benutzer erstellen und verwalten dagegen den vollständigen Konto-, Dienst-, Test- und Offboarding-Ablauf.

Für einen sauberen Wiederholungstest wird eine bestehende normale Sitzung unter Live users ausgewählt, auf Disconnect geklickt, der Benachrichtigungstext bei Bedarf geändert und Disconnect bestätigt. Bei AD SSO kann eine manuell getrennte Sitzung bis zu drei Minuten benötigen, bevor der Benutzer erneut angemeldet werden kann. Die Benachrichtigung erreicht nur Benutzer, die mit Authentication agent, Android client, iOS client oder Chromebook SSO angemeldet sind.

Clientless Users werden nicht mit Disconnect abgemeldet. Stattdessen wird der betreffende Benutzer unter Authentication > Clientless users auf Inactive gesetzt. Wurde bei einem Clientless User bereits Disconnect verwendet und soll der Zugriff wiederhergestellt werden, wird sein Status auf Inactive und danach auf Active gesetzt.

Benutzerobjekt, Main Group und Einschränkungen prüfen

Ist der Benutzer sichtbar oder wurde bereits ein lokaler Datensatz angelegt, folgt Authentication > Users. Dort werden keine Werte blind geändert, sondern zuerst die effektiven Eigenschaften dokumentiert:

• Status Active oder Inactive;
• Feld Group als Main Group bei AD-Benutzern;
• Other group memberships;
• benutzerspezifische Policy-Overrides;
• Access Time und Sign-in Restriction;
• Surfing Quota und Network Traffic Quota;
• MFA-Zuweisung für den betroffenen Dienst;
• zusätzliche Eigenschaft User ID.

Main Group und weitere Gruppen nicht gleichsetzen

Ein AD-Benutzer kann mehreren Gruppen angehören. Sophos Firewall zeigt die wirksame Main Group im Feld Group und weitere Mitgliedschaften separat. Firewall-Regeln, Web Policies und einige andere Funktionen können mehrere Gruppen berücksichtigen. Access Time, Quoten, MFA und verschiedene Remote-Access-Funktionen verwenden dagegen nur die Main Group oder eine explizite Benutzerzuweisung.

Darum wird die Gruppenreihenfolge nicht als schneller Fix verändert. Zuerst muss klar sein, welche Funktion fehlschlägt und welche Gruppenlogik sie unterstützt. Nach einer geplanten Änderung wird der Benutzer neu authentifiziert und die Main Group erneut geprüft.

Den vollständigen Betriebsablauf von Gruppenanlage und Default Group bis zu Reorder, Mehrfachgruppen, Benutzer-Overrides und Rollback zeigt Sophos Firewall Benutzergruppen und Main Group richtig verwalten.

Access Time, Quoten und MFA als eigene Ursache behandeln

Ein unerwartetes Captive Portal oder ein abgewiesener Login kann auch durch eine gesperrte Zugriffszeit, eine ausgeschöpfte Surfing- oder Network-Traffic-Quota oder eine fehlende MFA-Registrierung entstehen. Diese Einstellungen werden am Benutzer und an seiner wirksamen Gruppe verglichen.

Die jeweiligen Prüf- und Rückwege stehen in Access Time für Benutzer und Gruppen, Surfing und Network Traffic Quota sowie MFA für Sophos Firewall. Eine Quota wird nicht zurückgesetzt und eine Access-Time-Policy nicht verbreitert, bevor ihre tatsächliche Zuweisung belegt ist.

Scheitert nur die MFA, werden Issued tokens, Tokenstatus sowie Firewall- und Smartphone-Zeit geprüft. Mit Synchronize token time offset lässt sich Zeitdrift kontrollieren und korrigieren. SFOS 22 unterstützt SHA1, SHA256 und SHA512; die Authenticator-App muss den konfigurierten Algorithmus unterstützen. Ein Algorithmuswechsel oder das Löschen eines Tokens ist kein Diagnosetest, sondern eine geplante Migration beziehungsweise Neuregistrierung.

User-ID-Limit nur nach sichtbarem Wert zuordnen

Unter Show additional properties lässt sich die User ID einblenden. Ein Wert über 65535 liegt ausserhalb des unterstützten Bereichs; der Benutzer kann dann nicht authentifiziert und nicht zum Live User werden. Die Zahl sichtbarer Benutzer allein reicht für diese Diagnose nicht aus, weil Gruppen denselben ID-Bereich verwenden.

Ist die ID gültig oder fehlt der Benutzer noch vollständig, wird die allgemeine Diagnose fortgesetzt. Purge AD users gehört nur in den belegten Bereinigungsfall. Der sichere Spezialablauf steht unter Sophos Firewall User-ID-Limit prüfen.

Die verwendete Methode gezielt weiterprüfen

Sobald Dienst und Fehlerstufe feststehen, wird nur der passende Methodenpfad vertieft. So bleibt die Fehlersuche klein und verändert nicht gleichzeitig mehrere Authentifizierungssysteme.

Klassischer Login und Captive Portal

Bei einem manuellen Login werden direkte Portal-URL, Device Access, gewählte Authentifizierungsmethode, Benutzerstatus, Kennwort und MFA geprüft. Beim Captive Portal kommt hinzu, ob die unbekannte Verbindung die vorgesehene Regel mit Use web authentication for unknown users erreicht und ob DNS vor der Anmeldung funktioniert. Benutzername und Kennwort dürfen dort jeweils höchstens 50 Zeichen lang sein.

Der vollständige Aufbau samt Port 8090, Live Users, Benutzerregel und Abmeldung steht unter Sophos Firewall Captive Portal einrichten und testen.

AD SSO mit Kerberos oder NTLM

Ein erfolgreicher AD-Verbindungstest reicht für SSO nicht aus. Zusätzlich müssen Hostname beziehungsweise FQDN, DNS-Auflösung, Redirection Location, Zertifikat, Browser-Trust, Domain Join und bei Kerberos der passende HTTP-SPN stimmen. Fällt Kerberos auf NTLM oder das Captive Portal zurück, wird zuerst dieser Namens- und Vertrauenspfad geprüft.

nasm.log ist für NTLM- und Kerberos-Fehler relevant. SPN oder Domain Join werden nicht blind geändert; der bestehende Zustand wird zuerst auf Firewall und Domain Controller gesichert.

Zeigt /log/nasm.log einen KVNO-Fehler, kann nach einem erneuten Domain Join noch ein Kerberos-Ticket mit alter Schlüsselversion auf dem Client liegen. Den Benutzer zuerst am Windows-Client sperren und wieder entsperren oder vollständig ab- und anmelden, damit ein neues Ticket bezogen wird. Bleibt der Fehler bestehen, werden Key Version Number, Firewall-Computerobjekt und SPN auf dem Domain Controller geprüft; ein weiterer Domain Join ist nicht der erste Schritt.

STAS, SATC und Multi-User-Hosts

Bei Synchronized User ID Authentication kommen Windows-Domänenidentität und Client-IP über Security Heartbeat. Dann müssen Endpoint-Status, UPN-Domäne, sAMAccountName, AD-Validierung und Live users zusammenpassen; ein grüner Heartbeat allein beweist noch keine Benutzerregel.

Bei STAS muss dieselbe Client-IP durch Windows-Events, STA Agent, Collector und Firewall verfolgt werden. Fehlt der Benutzer nur unter Live Users, werden Collector-Erreichbarkeit, überwachte Netze, Exclusion List und Client Authentication geprüft. Der vollständige Ablauf steht unter STAS auf Sophos Firewall einrichten.

Der Legacy SATC Client wird nicht mehr unterstützt. Sophos empfiehlt, SATC-Installationen zu Sophos Server Protection in Sophos Fusion zu migrieren. Vor der Fehlersuche wird deshalb geklärt, welcher SATC-Client tatsächlich installiert ist; ein veralteter Legacy-Client wird nicht durch Änderungen an Firewall-Regeln oder Gruppen repariert.

Mehrere gleichzeitige Benutzer hinter einer Terminalserver-IP benötigen ein Sitzungsmodell. SATC für Remote Desktop Services kann mehrere Protokolle einer Sitzung zuordnen. Per-Connection AD SSO für Multi-User-Hosts gilt dagegen nur für HTTP- und HTTPS-Verbindungen über den Direct Web Proxy. Eine normale IP-basierte Zuordnung kann mehrere Benutzer hinter derselben Adresse nicht zuverlässig unterscheiden.

RADIUS SSO, Entra ID und VPN

RADIUS SSO benötigt Accounting-Ereignisse mit der richtigen Client-IP; ein erfolgreicher RADIUS-Zugangstest beweist diesen Accounting-Pfad nicht. Die Konfiguration und Prüfung der Framed-IP-Address beschreibt RADIUS SSO mit Accounting. Das VPN Portal unterstützt keine RADIUS-Authentifizierung mit Challenge-basierter MFA; ein dort abgewiesener Challenge-Flow ist daher kein Fehler der Serverreihenfolge.

API-Validierung vor der Accounting-Netzwerkdiagnose: Die Legacy-XML-API-Dokumentation für SFOS 22 und SFOS 23 begrenzt SharedSecret auf 50 Zeichen. Ein längeres generiertes Secret kann deshalb eine abgewiesene Konfiguration erklären, nicht einen Accounting-Netzwerkfehler. ClientIP ist dort als mehrwertiges ARRAY mit Datentyp IPADDRESS und maximal 15 Zeichen dokumentiert; der GUI-Eintrag ist RADIUS client IPv4. Das ist kein Nachweis für IPv6-Unterstützung. Die kopierte iOS-Beschreibung auf der RADIUS-API-Seite ist ein Dokumentationsfehler, keine Aussage zur RADIUS-/iOS-Kompatibilität. Zuerst den tatsächlichen Sender mit der gespeicherten erlaubten Client-IP vergleichen und die Übereinstimmung der Secret-Konfiguration auf beiden Seiten sicher prüfen; echte Secrets nie ausgeben oder in Logs, Screenshots oder Supportpakete übernehmen. Produktive Secrets nicht zur Diagnose kürzen, schwächen oder rotieren. Bei einem API-Fehler die bereinigte Antwort und den tatsächlich gespeicherten Zustand lesen, statt blind erneut zu schreiben. Ein notwendiger Credential-Wechsel ist eine separat freizugebende, beidseitig koordinierte Änderung mit gesichertem lokalem Managementzugang und dokumentiertem Rückweg; anschliessend gespeicherte Konfiguration, Accounting-Ereignis, Benutzer/IP unter Live users und Regelmatch kontrollieren.

SFOS 22: Bei Microsoft Entra ID SSO wird zusätzlich der dienstspezifische OAuth-Flow geprüft. Captive Portal, VPN Portal und WebAdmin verwenden unterschiedliche Redirect URIs, Authentifizierungsmethoden und Logdateien. Ein erfolgreicher Login an einem dieser Dienste beweist den anderen nicht.

SFOS 23.0: Unter Authentication > Servers ist OpenID Connect der Servertyp; IdP vendor unterscheidet Microsoft Entra ID und Google Workspace. Für den tatsächlich betroffenen Dienst verwendet man die versionierten Prüfwege für Entra WebAdmin, Entra VPN Portal und Remote Access oder Google Workspace OIDC. Redirect URI, Dienstzuweisung, Gruppen beziehungsweise Admin-Mapping, MFA sowie Positiv-, Negativ- und lokaler Fallback-Test bleiben getrennte Prüfungen. Eine erfolgreiche IdP-Anmeldung verleiht nicht automatisch Administratorrechte.

Bei VPN wird nach der Authentifizierung zusätzlich geprüft, ob der Benutzer beziehungsweise seine Gruppe in der richtigen Remote-Access-Policy steht. Ein grüner Tunnelstatus beweist noch keinen Zugriff auf interne Ziele.

Methodenspezifische Prüfungen vor Konfigurationsänderungen

AD SSO: Zeit, DNS und sichere Diagnose

Die Uhren von Client, Firewall und Domain Controller vergleichen. Kerberos-Tickets sind zeitlich begrenzt; standardmässig beträgt die Toleranz fünf Minuten, massgeblich ist aber die konfigurierte Domänenrichtlinie. Die Auflösung von _ldap._tcp.dc._msdcs.<AD domain> und die AD-Suchabfragen prüfen. Gruppen lesen und die Firewall der Domäne beitreten lassen erfordern unterschiedliche Berechtigungen: Ein passend delegiertes Join-Konto für einen späteren erneuten Beitritt nach HA-, Upgrade- oder Serveränderungen bereithalten. Ein normaler Testbenutzer wird dafür nicht zum Domain Admin gemacht.

Die Troubleshooting-Anleitung schlägt vor, vorübergehend Plaintext auf Port 389 zu verwenden, während die AD-Einrichtung STARTTLS auf 389 oder SSL/TLS auf 636 unterstützt. Die Verschlüsselung eines produktiven Authentifizierungspfads nicht zur Fehlereingrenzung abschalten. Stattdessen TLS-Kette, Namen, Port und AD-Serverlogs prüfen; einen ungelösten sicheren Verbindungsfehler eskalieren. Unter Authentication > Services die Option HTTP challenge redirect on intranet zone prüfen, statt sie zur Umgehung des Browservertrauens zu deaktivieren. Den konfigurierten Redirect-Namen und das Intranetvertrauen grenzt der AD-Workflow ein.

SATC und STAS: Registrierung von Erreichbarkeit unterscheiden

Für SATC bietet Option 4. Device Console diese lesende Registrierungsprüfung:

system auth thin-client show

Die aufgeführten Adressen mit den Terminalservern vergleichen. Fehlt ein Server, den SATC-Einrichtungs- und Wiederherstellungsworkflow verwenden, statt die Registrierung ungeplant zu ändern. Den ausgewählten AD-Server, das Ziel der SATC-Ereignisse und mögliche Quellportänderungen durch Proxy- oder Sicherheitssoftware prüfen. Ein Port-Mismatch kann Traffic unauthentifiziert lassen, obwohl die Serveradresse registriert ist.

Bei STAS prüfen, ob Collector-Host und Dienst laufen, UDP 6060 und 6677 nur auf den erforderlichen Pfaden erlaubt sind, Sicherheitssoftware nicht stört und ein Collector mit mehreren NICs an der richtigen Schnittstelle gebunden ist. Über IPsec wird die SNAT-Quelle systemgenerierten Traffics geprüft. Während SFOS auf die Identifizierung durch den Collector wartet, kann es Traffic des unbekannten Benutzers verwerfen. Eine Portalverzögerung von zwei Minuten kann die standardmässige Lernphase von 120 Sekunden sein, kein Portaldefekt. Die Lernphase nicht als Schnelllösung auf unter 20 Sekunden verkürzen. Windows-DCOM-Ereignisse 10009 oder 10028 sowie Zuordnungen mit LogonType: 1 aus nicht überwachten Netzen erfordern die Prüfung der WMI-Erreichbarkeit und übereinstimmender Agent-/Collector-Subnetzfilter. Die STAS-Diagnose und kontrollierte Wiederherstellung nutzen; vor Änderungen die bisherigen Filter- und Timerwerte sichern und nach einem erforderlichen Neustart erneut einen Pilotbenutzer testen.

Chromebook SSO und SSL VPN

Chromebook SSO ist nicht Google Workspace OIDC. Man vergleicht unter Authentication > Services > Chromebook SSO die Felder Domain, Port, Certificate und Logging level mit der Einrichtung der verwalteten Geräte. Das Zertifikat braucht einen privaten Schlüssel, die installierte zugehörige CA und einen CN, der zum vorgesehenen Gateway-Namen für das Benutzernetz passt. Weiter führt der Chromebook-SSO-Workflow für Zertifikat, Erweiterung und Regeln.

Man vergleicht bei SSL VPN die Benutzer/Gruppen der Remote-Access-Policy mit Authentication > Multi-factor authentication und prüft den genauen Clientfehler. Sophos-Connect-Benutzernamen müssen ASCII verwenden; auch nicht unterstützte Sonderzeichenfolgen sind zu prüfen. Die SSL-VPN-Anleitung nennt sowohl Call-/Push-MFA als auch <password><otp>; daraus folgt kein allgemein gültiger kombinierter Ablauf. Ein OTP nur bei einem konfigurierten Passwort-plus-OTP-Ablauf anhängen, nicht als Abhilfe für einen fehlgeschlagenen Push oder Anruf. Tatsächliche MFA-Methode und Client-/Serverkompatibilität über den SSL-VPN-Workflow klären, ohne MFA abzuschalten.

Bei bestehenden L2TP-/PPTP-Installationen auch das ausgehandelte Authentifizierungsprotokoll vergleichen: lokal und RADIUS unterstützen PAP, CHAP oder MSCHAPv2; AD und LDAP verwenden PAP; TACACS+ unterstützt PAP oder CHAP. Das ist eine Kompatibilitätsprüfung, keine Empfehlung für PPTP oder schwächere Verschlüsselung. Nach einer freigegebenen Korrektur frischen Login, Client Type, negativen Zugriffstest und Regelmatch wiederholen; bei erfolgloser Korrektur die dokumentierte Konfiguration wiederherstellen.

Authentifizierung erfolgreich, Traffic trotzdem blockiert

Ist der Benutzer unter Live users mit der erwarteten IP sichtbar, wechselt die Diagnose zur Autorisierung und zum Paketpfad. Ein echter Testflow muss zeigen:

1. Welche Firewall Rule ID verarbeitet die Verbindung?
2. Ist in dieser Regel der erwartete Benutzer oder eine unterstützte Gruppe enthalten?
3. Ist Log firewall traffic aktiv?
4. Wählt die Regel die richtige Web-, Application-, IPS- oder Traffic-Shaping-Policy?
5. Stimmen Ziel, Service, NAT, Route und Rückweg?

Eine allgemeine IP-Regel oberhalb der Benutzerregel kann den Traffic bereits vorher verarbeiten. Ebenso kann eine richtige Benutzerregel matchen, während Web Policy, TLS Inspection, DNS, Routing oder ein Zielsystem den späteren Zugriff verhindert. Deshalb wird eine Authentifizierungsänderung nicht als Fix für einen belegten Routing- oder Policy-Fehler verwendet.

Die vollständige Abnahme mit Log Viewer, Policy tester und Packet Capture erklärt Sophos Firewall-Regel sauber testen.

Log Viewer und Logdateien korrelieren

Im Log viewer wird das Modul Authentication mit dem notierten Benutzer, der Quell-IP und dem engen Testzeitraum geprüft. Danach wird derselbe Zeitpunkt im Firewall- oder VPN-Modul gesucht. So lässt sich erkennen, ob die Anmeldung bereits scheitert oder ob erst der spätere Datenflow blockiert wird.

Für die klassische Authentifizierung, Autorisierung und das Accounting ist access_server.log der erste Dateicheck. In der Advanced Shell sind die folgenden Befehle lesend:

cd /log
tail -n 200 access_server.log

Je nach Methode kommt genau die passende Datei hinzu:

tail -n 200 nasm.log

Die folgenden dienstspezifischen Entra-Lesebeispiele gelten nur für SFOS 22, nicht für SFOS 23:

tail -n 200 oauth_sso_captive.log
tail -n 200 oauth_sso_webadmin.log
tail -n 200 oauth_sso_vpn.log

• nasm.log gehört zu NTLM und Kerberos.
• SFOS 22: oauth_sso_captive.log gehört zum Entra-SSO-Ablauf des Captive Portals.
• SFOS 22: oauth_sso_webadmin.log gehört zu Entra SSO für WebAdmin.
• SFOS 22: oauth_sso_vpn.log gehört zu Entra SSO für VPN Portal, IPsec und SSL VPN.

SFOS 23.0: Den OIDC-Anmeldefluss prüft man in /log/oauth_sso_svc.log. Bei Entra gehört ein TLS-Fehler von Test connection dagegen zu /log/sfos-macro-cfg.log. Im Log viewer verwendet man Admin für WebAdmin und Authentication für Captive Portal, VPN Portal, IPsec und SSL VPN. Die oben verlinkten Anbieterabläufe ordnen Validierung und Fehlerbehandlung dem tatsächlichen Dienst zu; ein Neustart ist für diese lesende Diagnose nicht erforderlich.

Die Befehle lesen nur die letzten 200 Zeilen. Dabei wird kein Debug aktiviert und kein Dienst neu gestartet. Weitere Dateien wie vpnportal.log, sslvpn.log, strongswan.log, chromebook-sso-backend.log oder csd.log werden erst nach der Methodenwahl hinzugezogen. Die Zuordnung erklärt Sophos Firewall Service-Logs.

In einem HA-Cluster speichert jeder Node nur Logs und Reports für den Traffic, den er selbst verarbeitet. Deshalb werden Rolle, Testzeit und verarbeitender Node dokumentiert und die Dateien auf diesem Node geprüft. Eine leere Datei auf dem anderen Gerät widerlegt den Fehler nicht.

Fehler nach Symptom eingrenzen

Test connection ist erfolgreich, SSO funktioniert nicht

Der Authentifizierungsserver und seine Zugangsdaten sind erreichbar. Als Nächstes werden Authentication > Services, Device Access, Live Users und der methodenspezifische SSO-Pfad geprüft. Bei AD sind das insbesondere DNS, FQDN, Redirection Location, SPN, Browser-Trust, Domain Join und nasm.log.

Captive Portal erscheint statt transparenter Anmeldung

Zuerst feststellen, ob AD SSO oder STAS den Benutzer vor dem Webzugriff erkennen sollte. Danach Client Type unter Live Users, Authentication-Modul, Access Time, Quoten und Zugangsdaten prüfen. Das Portal ist ein Symptom fehlender oder abgewiesener Identität und nicht automatisch ein Portalfehler.

Computername erscheint statt Benutzername

Ein Systemdienst kann NTLM-Zugangsdaten des Endpoints senden, obwohl noch kein Benutzer interaktiv angemeldet ist. Einen echten Benutzer anmelden, neue Browser-Sitzung öffnen und den Test wiederholen. Bleibt der Computername, werden Browser-/Proxy-Pfad, SSO-Methode und nasm.log geprüft.

Benutzer fehlt unter Live Users

Zuerst Dienstwahl, Device Access und die konkrete Methode prüfen. Bei STAS müssen Collector und Firewall dieselbe IP sehen; bei Captive Portal muss der Login wirklich abgeschlossen sein; bei externen Servern entsteht der lokale Benutzerdatensatz erst nach erfolgreicher Anmeldung. User ID, Sign-in Restriction und Quoten werden nur geprüft, wenn ein entsprechender Benutzerdatensatz vorhanden ist.

Benutzer ist sichtbar, aber Gruppe oder Policy ist falsch

Unter Authentication > Users Main Group, Other group memberships und Benutzer-Overrides vergleichen. Danach prüfen, ob die konkrete Funktion mehrere Gruppen unterstützt. Gruppenreihenfolge erst in einem geplanten Wartungsfenster ändern, weil sich dadurch auch MFA, Quoten, Access Time, VPN und weitere Policies verschieben können.

Login ist erfolgreich, aber Internet oder VPN-Ziel bleibt unerreichbar

Die Authentifizierung ist nicht mehr die erste Fehlerstufe. Firewall Rule ID, Regelreihenfolge, Logging, Web-/VPN-Policy, NAT, Route und Rückweg werden mit einem echten Flow geprüft. Benutzeridentität und Paketpfad müssen beide stimmen.

Fehler tritt nur nach HA-Failover oder sporadisch auf

Firmware-Build, Rollenwechsel, aktive Node-Rolle, Loginzeit und Authentifizierungsmethode dokumentieren. Einen neuen Login und eine neue Verbindung nach dem Failover testen. Danach die Logs auf dem Node prüfen, der den Versuch verarbeitet hat. Keine bestehende Sitzung als Beweis für eine neue erfolgreiche Authentifizierung werten.

Stop-Bedingungen und Supportdaten

Die produktive Konfiguration wird nicht weiter verändert, wenn:

• der betroffene Dienst oder die Authentifizierungsmethode nicht eindeutig ist;
• Test connection fehlschlägt und DNS, Route, Port, TLS oder Zugangsdaten noch ungeklärt sind;
• der Pilotbenutzer mit einem unerwarteten Client Type oder einer falschen Quell-IP erscheint;
• Main Group, Benutzer-Override oder Quota nicht nachvollziehbar zugeordnet werden kann;
• ein Negativtest unerwartet Zugriff erhält;
• nur eine breite Device-Access- oder Firewall-Freigabe den Test scheinbar erfolgreich macht;
• ein HA-Problem keinem verarbeitenden Node und Zeitpunkt zugeordnet werden kann.

Vor einer Eskalation werden mindestens gesichert:

• Appliance-Modell, SFOS-Version und vollständiger Build;
• bei HA beide Rollen und der verarbeitende Node;
• Authentifizierungsquelle und betroffener Dienst;
• Testbenutzer, Quell-IP, Client Type und Zeitfenster;
• Serverreihenfolge unter Authentication > Services;
• Ergebnis von Test connection mit seiner begrenzten Aussage;
• Status, Main Group, weitere Gruppen, Overrides und User ID;
• Authentication-Event, Firewall Rule ID und Ergebnis des echten Testflows;
• passende Authentifizierungs-, Portal-, VPN- und Firewall-Logs.

Benutzernamen und Gruppen können sensible Informationen enthalten. Das Paket wird nur für den vorgesehenen Supportweg bereitgestellt. Ein Consolidated Troubleshooting Report und gezielter Logexport sollte vor Service-Restarts, Debug oder Datenbereinigung erstellt werden.

Checkliste

• Testfall enthält Benutzer, Quell-IP, Dienst, Zeitpunkt und erwartetes Ergebnis.
• Der lokale Dienst ist nur aus der vorgesehenen Zone beziehungsweise Quelle erreichbar.
• Der richtige Server ist unter Authentication > Services beim betroffenen Dienst ausgewählt.
• Test connection wurde nicht mit einem vollständigen SSO-Test verwechselt.
• Live Users zeigt Benutzer, IP und erwarteten Client Type.
• Status, Main Group, weitere Gruppen, Overrides und User ID sind geprüft.
• Access Time, Quoten, Sign-in Restriction und MFA wurden nur beim wirksamen Benutzerpfad bewertet.
• Authentifizierungserfolg und späterer Firewall-, Web- oder VPN-Flow wurden getrennt getestet.
• Log Viewer und passende Logdatei wurden mit demselben Zeitfenster korreliert.
• In HA wurde der verarbeitende Node geprüft.
• Es gab keinen pauschalen Restart, Purge oder eine breite Freigabe als Schnellfix.
• Supportdaten wurden vor weiteren Änderungen gesichert.

Häufige Fragen