Sophos Firewall: AD SSO funktioniert nach SFOS-22-Upgrade nicht

Nach einem Upgrade von SFOS 21.5 oder älter auf SFOS 22.0 GA kann Active Directory Single Sign-On mit Kerberos und NTLM unmittelbar ausfallen. Die Firewall leitet weiterhin Traffic weiter, erkennt die betroffenen Domain-Benutzer aber nicht mehr. Dadurch treffen benutzerbasierte Firewall-Regeln nicht wie vorgesehen.

⚠️ Der Cleanup darf nur in der Advanced Shell und nur bei passendem Upgradepfad und Fehlerbild verwendet werden. Läuft die Firewall bereits auf MR1 Build 490 oder neuer, bestand der Fehler schon vor dem Upgrade oder ist ein HA-Cluster betroffen, wird der Befehl nicht pauschal ausgeführt.

Wenn die Firewall noch auf SFOS 22.0 GA läuft und in nasm.log ein zeitlich passender Fehler mit unknown option erscheint, kann NASM gezielt neu aufgebaut werden. Die folgenden Prüfungen verhindern, dass der Cleanup bei einem gewöhnlichen DNS-, SPN- oder Domain-Join-Problem eingesetzt wird.

Für diesen Fehler sind zwei unterschiedliche Issue-IDs dokumentiert: NC-176853 und NC-176039. KBA-000048429 selbst nennt keine NC-ID. Dieser Artikel hält den konkreten Versionsstand fest: Beide Ledger weisen SFOS 22.0 MR1 Build 490 als behobene Version aus; die KBA bezeichnet sie als SFOS v22.0.1 MR-1. Daher wird keine der beiden NC-IDs als allein massgeblich behandelt. Dynamische Angaben zu freigegebenen Builds, aktuellem Maintenance Release und Upgradepfad werden vor der Änderung mit dem SFOS-22-Upgrade-Check geprüft. Der Cleanup ist eine gezielte Reparatur für den beschriebenen GA-Upgradefall und keine allgemeine Lösung für jedes AD-SSO-Problem.

Wann dieser Ablauf passt

Der Ablauf ist für folgenden Fall gedacht:

• Upgrade von SFOS 21.5 oder älter auf SFOS 22.0 GA
• AD SSO mit Kerberos und NTLM funktionierte vor dem Upgrade
• Domain-Benutzer können sich danach nicht mehr per AD SSO authentifizieren
• identitätsbasierte Regeln erkennen Benutzer nicht mehr
• andere Firewall-Funktionen und nicht auf AD basierende Anmeldungen funktionieren weiterhin

Ein erfolgreicher Test connection unter Authentication > Servers schliesst diesen Fehler nicht aus. Der Test bestätigt die Verbindung zum Domain Controller und die Zugangsdaten, aber nicht den vollständigen AD-SSO-Ablauf.

Schlägt bereits Test connection fehl, liegt die Ursache wahrscheinlich bei Erreichbarkeit, DNS, Port, Zertifikat oder Servicekonto. Diese Grundlagen erklärt Active Directory mit Sophos Firewall verbinden.

Fehler in nasm.log prüfen

Per SSH auf der Firewall anmelden und 5. Device Management > 3. Advanced Shell öffnen. Der SSH-Zugang zur Sophos Firewall ist separat erklärt.

Danach nach dem für diesen Fehler vorgesehenen Bestätigungssignal suchen:

grep "unknown option" /log/nasm.log

Dieser Treffer bestätigt den beschriebenen Upgradefehler nur dann, wenn sein Zeitstempel zum Upgrade und zum Ausfall passt; ein alter Eintrag beweist keinen aktuellen Fehler.

Bleibt die Ausgabe leer, fehlt das erforderliche Bestätigungssignal. Der Cleanup wird dann nicht auf Verdacht ausgeführt. Zuerst sind DNS, SPN, Domain Join, Redirection Location, Browser-Trust und die normale Kerberos-/NTLM-Konfiguration zu prüfen; passen Upgradepfad und Symptome weiterhin, wird Sophos Support einbezogen.

NASM gezielt bereinigen

Beim Firmwarewechsel erstellt SFOS die NASM-Verzeichnisse passend zur verwendeten Samba-Version neu. Beim betroffenen Upgrade kann dieser Schritt unvollständig bleiben. Das neue NASM lädt dann ältere, nicht kompatible Samba-Komponenten und AD SSO fällt aus.

Vor der Änderung werden aktuelle Firmwareversion, Zeitpunkt des Ausfalls und die Ausgabe aus nasm.log dokumentiert. Für den Fall, dass die Authentifizierung während der Arbeit nicht verfügbar ist, sollte ein lokaler oder alternativer Administratorzugang bestehen.

Für eine Firewall, die aktuell unter SFOS 22.0 GA läuft, nennt Sophos den Cleanup als bevorzugte Lösung. In der Advanced Shell ausführen:

opcode -ds nosync nasm_cleanup

Der Befehl erzwingt Cleanup und Neuerstellung der NASM-Umgebung passend zu Samba 4.22.1; danach ist normalerweise kein Neustart erforderlich. Sophos nennt dafür weder eine bestimmte Erfolgsmeldung noch einen Rückgängig-Befehl. Deshalb wird der Erfolg nicht anhand einer einzelnen Shell-Ausgabe, sondern mit einer neuen AD-SSO-Anmeldung geprüft. Bei einem unerwarteten Ergebnis wird der Befehl nicht wiederholt, sondern der dokumentierte Ausgangszustand unter Angabe von KBA-000048429 an Sophos Support übergeben.

AD SSO mit echtem Benutzertraffic kontrollieren

Nach dem Cleanup reicht ein erneuter Test connection nicht aus. Die Kontrolle erfolgt mit einem Domain-Benutzer und einer tatsächlich benutzerbasierten Regel:

1. Auf einem Domain-Client eine neue Browser-Verbindung öffnen, die AD SSO und eine benutzerbasierte Firewall-Regel verwendet.
2. Unter Current activities > Live users prüfen, ob der Domain-Benutzer wieder erscheint.
3. Oben rechts Log viewer öffnen, im Module Selector Authentication wählen und in Log Comp kontrollieren, ob Kerberos oder NTLM verwendet wird. Kerberos authentication initialized successfully und NTLM authentication channel established successfully bestätigen eine erfolgreiche Initialisierung.
4. Im Firewall-Log prüfen, ob Benutzer, Gruppe und Firewall Rule ID der vorgesehenen Regel entsprechen.
5. Die Anwendung oder das Ziel testen, das vor dem Cleanup nicht erreichbar war.

Erst wenn Benutzeridentität und Regel-Match stimmen, ist der Fehler behoben. Zeigt das Authentication-Log stattdessen Cannot initialize Kerberos authentication oder Cannot establish NTLM authentication channel, ist der AD-Kanal noch nicht funktionsfähig. Wird nur wieder eine Captive-Portal-Anmeldung angezeigt oder erscheint der Benutzer weiterhin nicht, gehören auch SPN, DNS-Auflösung, Redirection Location und Browser-Trust in die Prüfung. Die Zuordnung weiterer Authentifizierungsdateien steht unter Sophos Firewall Services und Logs.

Dauerhafte Lösung und Alternative ohne Advanced Shell

Auf eine behobene SFOS-Version aktualisieren

Die KBA nennt SFOS v22.0.1 MR-1 als behobene Version; trotz der Abweichung zwischen NC-176853 und NC-176039 weisen beide aktuellen Ledger SFOS 22.0 MR1 Build 490 als Zielversion mit Korrektur aus. Zum Redaktionsstand 4. September 2026 ist SFOS 22.0 MR2 Build 546 die aktuelle 22.0-Version. Vor der Änderung wird dieser dynamische Stand mit dem SFOS-22-Upgrade-Check erneut geprüft. Installiert wird die neueste für das eigene Modell und den vorhandenen Upgradepfad freigegebene Maintenance Release, nicht gezielt eine inzwischen überholte Zwischenversion. Dort werden vor dem Firmwarewechsel auch Upgradepfad, Backup, Speicher, HA und Rückweg geprüft.

Tritt dasselbe Symptom auf MR1 Build 490 oder einer neueren Version neu auf, passt der hier beschriebene GA-Upgradefehler nicht mehr eindeutig. Dann wird nicht wiederholt bereinigt, sondern die normale AD-SSO-Diagnose durchgeführt und bei Bedarf Sophos Support eingeschaltet.

Wenn die Advanced Shell nicht erreichbar ist

Wenn die Advanced Shell nicht erreichbar ist, kann stattdessen ein erneuter Firmwarewechsel die NASM-Verzeichnisse neu erstellen:

• Läuft die Firewall bereits wieder unter SFOS 21.5, wird erneut in SFOS 22.0 GA gestartet.
• Läuft die Firewall unter SFOS 22.0 GA, wird zuerst in den vorhandenen SFOS-21.5-Firmware-Slot und danach wieder in SFOS 22.0 GA gestartet.

Dieser Roundtrip stösst die Erstellung der NASM-Verzeichnisse erneut an. Er verursacht Ausfallzeit und ist nicht dasselbe wie ein normaler Neustart. In WebAdmin liegt der Ablauf unter Backup and firmware > Firmware; beim inaktiven Slot wird Boot firmware image gewählt. Beide Firmware-Partitionen halten getrennte Konfigurationen. Solange SFOS 21.5 läuft, ist der frühere Konfigurationsstand aktiv; nach der Rückkehr zur 22.0-Partition wird wieder deren zugehörige Konfiguration aktiv. Während des Umwegs dürfen keine produktiven Konfigurationsänderungen erfolgen, weil die Partitionen sie nicht teilen.

Vor dem Start werden ein Wartungsfenster geplant, ein aktuelles Backup extern gespeichert und Kompatibilität sowie Verfügbarkeit der inaktiven Firmware geprüft. Konsolenzugriff ist eine sinnvolle Absicherung. Nach jedem Boot wird im Control Center kontrolliert, welche Version tatsächlich aktiv ist. Für HA-Cluster ist keine HA-spezifische Reihenfolge der Nodes vorgegeben; deshalb wird dort jeder der beiden Lösungswege mit Sophos Support abgestimmt. Wenn diese Voraussetzungen fehlen, ist das direkte Upgrade auf eine behobene Version oder ein abgestimmter Ablauf mit Sophos Support sicherer.

Wann der Cleanup nicht die richtige Lösung ist

nasm_cleanup wird nicht als allgemeiner Reparaturbefehl verwendet. Ein anderer Diagnoseweg ist nötig, wenn:

• die Firewall bereits auf SFOS 22.0 MR1 Build 490 oder neuer läuft
• das Problem schon vor dem Upgrade bestand
• Test connection zum AD-Server fehlschlägt
• nur einzelne Benutzer, Gruppen oder Browser betroffen sind
• STAS, Microsoft Entra ID SSO, RADIUS oder eine normale LDAP-Anmeldung betroffen ist
• DNS, SPN, Domain Join, Zertifikate oder Browser-Trust nicht sauber funktionieren
• der Upgradepfad oder der Zeitpunkt des Ausfalls nicht zum beschriebenen Fehler passt
• ein HA-Cluster betroffen ist; für die Nodes ist keine HA-spezifische Reihenfolge vorgegeben

In diesen Fällen verhindert ein Cleanup keine Fehlkonfiguration und kann die eigentliche Ursache verdecken. Zuerst wird der betroffene Authentifizierungsweg eingegrenzt; bei unklarem oder abweichendem Verhalten ist Sophos Support der richtige Eskalationspunkt.