Sophos Firewall: AD SSO nie działa po aktualizacji SFOS 22

Po aktualizacji z SFOS 21.5 lub starszego do SFOS 22.0 GA mechanizm Active Directory Single Sign-On z Kerberos i NTLM może natychmiast przestać działać. Firewall nadal przekazuje pozostały ruch, ale nie rozpoznaje użytkowników domeny, których dotyczy problem. W rezultacie reguły firewalla oparte na użytkownikach nie są stosowane zgodnie z założeniem.

⚠️ Operację cleanup wolno wykonywać wyłącznie w Advanced Shell i tylko wtedy, gdy ścieżka aktualizacji oraz objawy odpowiadają opisanej sytuacji. Jeśli firewall działa już w wersji MR1 Build 490 lub nowszej, błąd występował przed aktualizacją albo problem dotyczy klastra HA, polecenia nie należy wykonywać bez indywidualnej oceny.

Jeśli firewall nadal działa w wersji SFOS 22.0 GA, a w pliku nasm.log znajduje się odpowiadający czasowo błąd z tekstem unknown option, można celowo przebudować NASM. Poniższe kontrole zapobiegają użyciu operacji cleanup w przypadku zwykłego problemu z DNS, SPN lub dołączeniem do domeny.

Dla tej awarii udokumentowano dwa różne identyfikatory: NC-176853 i NC-176039. Sama KBA-000048429 nie podaje identyfikatora NC. Ten artykuł bezpośrednio podaje konkretny stan wersji: oba rejestry wskazują SFOS 22.0 MR1 Build 490 jako wersję z poprawką; KBA określa ją jako SFOS v22.0.1 MR-1. Dlatego żaden z identyfikatorów nie jest uznawany za jedyny kanoniczny. Przed zmianą dynamiczne dane o zatwierdzonych buildach, aktualnej maintenance release i ścieżce aktualizacji należy sprawdzić za pomocą kontroli przed aktualizacją do SFOS 22. Operacja cleanup jest ukierunkowaną naprawą opisanego przypadku aktualizacji do wersji GA, a nie ogólnym rozwiązaniem każdego problemu z AD SSO.

Kiedy ta procedura ma zastosowanie

Procedura jest przeznaczona dla następującego przypadku:

• aktualizacja z SFOS 21.5 lub starszego do SFOS 22.0 GA
• AD SSO z Kerberos i NTLM działało przed aktualizacją
• po aktualizacji użytkownicy domeny nie mogą uwierzytelnić się przez AD SSO
• reguły oparte na tożsamości nie rozpoznają już użytkowników
• inne funkcje firewalla i logowania niezależne od AD nadal działają

Pomyślne wykonanie Test connection w Authentication > Servers nie wyklucza tego błędu. Test potwierdza połączenie z kontrolerem domeny i dane logowania, ale nie cały przebieg AD SSO.

Jeśli już Test connection kończy się niepowodzeniem, przyczyną jest prawdopodobnie osiągalność, DNS, port, certyfikat lub konto serwisowe. Podstawy te wyjaśnia artykuł Active Directory z Sophos Firewall: konfiguracja.

Sprawdzanie błędu w nasm.log

Zalogować się do firewalla przez SSH i otworzyć 5. Device Management > 3. Advanced Shell. Dostęp SSH do Sophos Firewall opisano oddzielnie.

Następnie wyszukać sygnał potwierdzający właściwy dla tego problemu:

grep "unknown option" /log/nasm.log

Ten wpis potwierdza opisany błąd aktualizacji tylko wtedy, gdy znacznik czasu odpowiada aktualizacji i wystąpieniu awarii; stary wpis nie potwierdza aktualnego błędu.

Jeśli polecenie nie zwraca wyniku, brakuje wymaganego sygnału potwierdzającego. Nie należy wtedy wykonywać operacji cleanup na podstawie przypuszczenia. Najpierw trzeba sprawdzić DNS, SPN, Domain Join, Redirection Location, zaufanie przeglądarki i standardową konfigurację Kerberos/NTLM; jeśli ścieżka aktualizacji i objawy nadal odpowiadają opisowi, należy skontaktować się z Sophos Support.

Ukierunkowane czyszczenie NASM

Podczas zmiany firmware SFOS ponownie tworzy katalogi NASM odpowiednio do używanej wersji Samba. Przy aktualizacji, której dotyczy problem, ten etap może pozostać niekompletny. Nowy NASM ładuje wtedy starsze, niezgodne komponenty Samba, a AD SSO przestaje działać.

Przed zmianą należy udokumentować aktualną wersję firmware, czas wystąpienia awarii i wynik z nasm.log. Na wypadek niedostępności uwierzytelniania podczas prac powinien istnieć lokalny lub alternatywny dostęp administratora.

Sophos wskazuje operację cleanup jako preferowane rozwiązanie dla firewalla działającego obecnie w SFOS 22.0 GA. W Advanced Shell wykonać:

opcode -ds nosync nasm_cleanup

Polecenie wymusza cleanup i ponowne utworzenie środowiska NASM zgodnego z Samba 4.22.1; ponowne uruchomienie zwykle nie jest potem potrzebne. Sophos nie określa konkretnego komunikatu powodzenia ani polecenia cofającego. Dlatego wyniku nie należy oceniać na podstawie pojedynczej odpowiedzi powłoki, lecz przez nowe logowanie AD SSO. Jeśli wynik jest nieoczekiwany, nie należy powtarzać polecenia; trzeba przekazać Sophos Support informacje zapisane przed zmianą, podając KBA-000048429.

Kontrola AD SSO z rzeczywistym ruchem użytkownika

Po operacji cleanup ponowne Test connection nie wystarcza. Kontrolę należy przeprowadzić z użytkownikiem domeny i rzeczywistą regułą opartą na użytkowniku:

1. Na kliencie domenowym otworzyć nowe połączenie przeglądarki, które korzysta z AD SSO i reguły firewalla opartej na użytkowniku.
2. W Current activities > Live users sprawdzić, czy użytkownik domeny jest ponownie widoczny.
3. Otworzyć Log viewer w prawym górnym rogu, wybrać Authentication w selektorze modułów i sprawdzić w Log Comp, czy używany jest Kerberos lub NTLM. Komunikaty Kerberos authentication initialized successfully i NTLM authentication channel established successfully potwierdzają pomyślną inicjalizację.
4. W dzienniku firewalla sprawdzić, czy użytkownik, grupa i Firewall Rule ID odpowiadają zamierzonej regule.
5. Przetestować aplikację lub cel, który nie był dostępny przed operacją cleanup.

Błąd jest usunięty dopiero wtedy, gdy tożsamość użytkownika i dopasowanie reguły są prawidłowe. Jeśli dziennik Authentication pokazuje Cannot initialize Kerberos authentication lub Cannot establish NTLM authentication channel, kanał AD nadal nie działa. Jeśli ponownie wyświetla się tylko logowanie Captive Portal albo użytkownik nadal się nie pojawia, należy również sprawdzić SPN, rozwiązywanie DNS, Redirection Location i zaufanie przeglądarki. Przypisanie innych plików uwierzytelniania opisano w Sophos Firewall Troubleshooting: Services i Logs.

Trwałe rozwiązanie i alternatywa bez Advanced Shell

Aktualizacja do poprawionej wersji SFOS

KBA wskazuje SFOS v22.0.1 MR-1 jako wersję z poprawką; mimo rozbieżności między identyfikatorami NC-176853 i NC-176039 oba aktualne rejestry wskazują SFOS 22.0 MR1 Build 490 jako docelową wersję z poprawką. Na 4 września 2026 r. SFOS 22.0 MR2 Build 546 jest aktualną wersją 22.0. Przed zmianą należy ponownie sprawdzić ten dynamiczny stan za pomocą kontroli przed aktualizacją do SFOS 22. Należy zainstalować najnowszą maintenance release zatwierdzoną dla danego modelu i ścieżki aktualizacji, zamiast celowo wybierać nieaktualną wersję pośrednią. Ta sama kontrola obejmuje również ścieżkę aktualizacji, kopię zapasową, wolne miejsce, HA i drogę powrotu przed zmianą firmware.

Jeśli ten sam objaw pojawia się po raz pierwszy w wersji MR1 Build 490 lub nowszej, opisany tutaj błąd aktualizacji do GA nie jest już jednoznacznym wyjaśnieniem. Nie należy wtedy ponownie wykonywać operacji cleanup, lecz przeprowadzić standardową diagnostykę AD SSO i w razie potrzeby skontaktować się z Sophos Support.

Gdy Advanced Shell jest niedostępna

Gdy Advanced Shell jest niedostępna, ponowna zmiana firmware może odtworzyć katalogi NASM:

• Jeśli firewall działa już ponownie w SFOS 21.5, należy jeszcze raz uruchomić SFOS 22.0 GA.
• Jeśli firewall działa w SFOS 22.0 GA, należy najpierw uruchomić dostępny slot firmware SFOS 21.5, a następnie ponownie SFOS 22.0 GA.

Taka operacja ponownie uruchamia tworzenie katalogów NASM. Powoduje przestój i nie jest tym samym co zwykłe ponowne uruchomienie. W WebAdmin należy przejść do Backup and firmware > Firmware i wybrać Boot firmware image dla nieaktywnego slotu. Obie partycje przechowują oddzielne konfiguracje. Podczas pracy SFOS 21.5 aktywna jest wcześniejsza konfiguracja; po powrocie do partycji 22.0 ponownie uaktywnia się odpowiadająca jej konfiguracja. Podczas tego przejścia nie należy zmieniać konfiguracji produkcyjnej, ponieważ partycje nie współdzielą zmian.

Przed rozpoczęciem należy zaplanować okno serwisowe, zapisać aktualną kopię zapasową poza firewallem oraz potwierdzić zgodność i dostępność nieaktywnego firmware. Dostęp do konsoli jest rozsądnym zabezpieczeniem. Po każdym uruchomieniu należy sprawdzić aktywną wersję w Control Center. Nie określono sekwencji przeznaczonej dla węzłów HA; w klastrze HA oba rozwiązania trzeba uzgodnić z Sophos Support. Jeśli te warunki nie są spełnione, bezpieczniejsza jest bezpośrednia aktualizacja do poprawionej wersji lub procedura uzgodniona z Sophos Support.

Kiedy cleanup nie jest właściwym rozwiązaniem

Polecenia nasm_cleanup nie należy używać jako ogólnego polecenia naprawczego. Inna ścieżka diagnostyczna jest konieczna, jeśli:

• firewall działa już w SFOS 22.0 MR1 Build 490 lub nowszej wersji
• problem występował przed aktualizacją
• Test connection z serwerem AD kończy się niepowodzeniem
• problem dotyczy tylko pojedynczych użytkowników, grup lub przeglądarek
• problem dotyczy STAS, Microsoft Entra ID SSO, RADIUS lub standardowego logowania LDAP
• DNS, SPN, Domain Join, certyfikaty lub zaufanie przeglądarki nie działają prawidłowo
• ścieżka aktualizacji lub czas wystąpienia awarii nie odpowiada opisanemu błędowi
• problem dotyczy klastra HA; nie określono sekwencji przeznaczonej dla węzłów HA

W takich przypadkach operacja cleanup nie usuwa błędnej konfiguracji i może ukryć właściwą przyczynę. Najpierw należy zawęzić problem do danego sposobu uwierzytelniania; przy niejasnym lub odmiennym zachowaniu właściwym punktem eskalacji jest Sophos Support.