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.

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.

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:

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, Captive portal, RADIUS SSO oder ein VPN-Typ?

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 kann eine bestehende normale Sitzung unter Live users getrennt werden. Bei AD SSO kann eine manuell getrennte Sitzung bis zu drei Minuten benötigen, bevor der Benutzer erneut angemeldet werden kann. Clientless Users werden dort nicht mit Disconnect abgemeldet, sondern unter Authentication > Clientless users auf Inactive 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.

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.

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.

STAS, SATC und Multi-User-Hosts

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.

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.

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.

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.

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.

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
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.
• oauth_sso_captive.log gehört zum Entra-SSO-Ablauf des Captive Portals.
• oauth_sso_webadmin.log gehört zu Entra SSO für WebAdmin.
• oauth_sso_vpn.log gehört zu Entra SSO für VPN Portal, IPsec und SSL VPN.

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