Systematyczne rozwiązywanie błędów uwierzytelniania na Sophos Firewall

Błąd uwierzytelniania na Sophos Firewall może powstać na bardzo różnych etapach. Serwer może być osiągalny, ale nie być wybrany dla danej usługi. Logowanie może działać, podczas gdy grupa główna, limit lub reguła firewall blokuje dostęp. Firewall może też w ogóle nie rozpoznawać użytkownika i przetwarzać ruch wyłącznie na podstawie adresu IP.

Bezpieczna szybka ścieżka celowo rozdziela te warstwy:

1. Zanotować użytkownika, źródłowy adres IP, daną usługę, czas i oczekiwany wynik.
2. Sprawdzić osiągalność portalu lub usługi uwierzytelniania z rzeczywistej strefy źródłowej.
3. W Authentication > Services sprawdzić, czy właściwy serwer jest wybrany dla danej usługi i znajduje się na planowanej pozycji.
4. Uruchomić Test connection na serwerze uwierzytelniania, ale uznać go wyłącznie za potwierdzenie poświadczeń i łączności z serwerem.
5. Wygenerować nowe logowanie i w Current activities > Live users sprawdzić użytkownika, źródłowy adres IP oraz Client Type.
6. W Authentication > Users sprawdzić status, grupę główną, pozostałe grupy, wyjątki użytkownika oraz User ID.
7. Access Time, limity, MFA i Sign-in Restrictions sprawdzać tylko dla faktycznie dotkniętego użytkownika lub jego skutecznej grupy.
8. Dopiero po potwierdzeniu tożsamości przetestować rzeczywistym ruchem oczekiwaną regułę firewall, Rule ID, politykę web lub VPN, NAT i routing.

⚠️ Nie zmieniać szeroko serwerów uwierzytelniania, kolejności grup, limitów ani Device Access na podstawie przypuszczeń. Restart usługi, Purge AD users lub reguła Any nie są normalnym pierwszym krokiem diagnostycznym. Najpierw trzeba wykazać, na której warstwie proces się zatrzymuje.

Pięć warstw zamiast jednego błędu logowania

W praktyce pomaga prosty model. Dostęp użytkownika przechodzi nie jedną, lecz co najmniej pięć oddzielnych kontroli:

1. Osiągalność: klient i firewall docierają do portalu, proxy lub serwera uwierzytelniania zamierzoną ścieżką.
2. Usługa i metoda: właściwy serwer uwierzytelniania jest wybrany w Authentication > Services dokładnie dla tej usługi.
3. Tożsamość: firewall rozpoznaje oczekiwanego użytkownika i pokazuje go z poprawnym źródłowym adresem IP oraz właściwym Client Type.
4. Autoryzacja: status użytkownika, grupa, grupa główna, Access Time, limit, MFA i uprawnienia właściwe dla usługi są zgodne.
5. Dalszy ruch: reguła firewall, polityka web lub polityka VPN zezwala na wymagane miejsca docelowe, a ścieżka powrotna działa.

Takie rozdzielenie zapobiega dwóm częstym błędnym wnioskom. Zielony Test connection nie dowodzi działania logowania SSO. Z kolei użytkownik widoczny w Live users nie dowodzi jeszcze, że jego ruch trafia do zamierzonej reguły lub polityki.

Zdefiniowanie powtarzalnego przypadku testowego

Przed pierwszą zmianą należy określić jeden przypadek testowy. Bezpieczne wartości dokumentacyjne to na przykład:

• Użytkownik: auth-pilot@example.com
• Adres IP klienta: 192.0.2.25
• Strefa źródłowa: LAN
• Usługa: Firewall authentication, User portal, VPN portal, SSL VPN lub Web admin console
• Czas testu: lokalny czas firewalla z datą i minutą
• Oczekiwana grupa: Internet-Standard
• Oczekiwana reguła: LAN-Users-to-WAN
• Oczekiwany wynik: udane logowanie i dostęp HTTPS do określonego celu testowego

example.com i 192.0.2.0/24 są wartościami dokumentacyjnymi. Nazwę użytkownika, źródłowy adres IP, strefę, grupę, regułę i cel należy zastąpić rzeczywistymi wartościami pilota. Pilot powinien używać tego samego źródła uwierzytelniania i grupy uprawnień co dotknięty użytkownik, ale bez zbędnych uprawnień administracyjnych.

Jeśli to możliwe, należy także przetestować działającego użytkownika porównawczego z tego samego źródła. Jeśli obaj zawodzą, przyczyna leży raczej w usłudze, serwerze lub osiągalności. Jeśli zawodzi tylko jeden użytkownik, bardziej prawdopodobne są obiekt użytkownika, grupy, limity, MFA lub Sign-in Restrictions.

Sprawdzenie usługi, osiągalności i serwera

Kontrola Device Access tylko dla wymaganej usługi

Portale i lokalne usługi uwierzytelniania nie są udostępniane przez zwykłe reguły firewall. W Administration > Device access albo przez precyzyjną Local service ACL exception rule wymagana usługa musi być osiągalna z planowanej strefy źródłowej lub znanych sieci źródłowych.

W zależności od testu znaczenie mogą mieć różne pozycje, na przykład Captive portal, User portal, VPN portal, SSL VPN, AD SSO lub Client Authentication. Sprawdzać należy tylko faktycznie potrzebną usługę. Szerokie zezwolenie dla LAN lub WAN ukryłoby błąd i mogłoby wystawić dodatkowe usługi zarządzania lub portale. Device Access i Local Service ACL na Sophos Firewall wyjaśnia bezpieczne rozgraniczenie.

Sama osiągalność nie jest jeszcze uwierzytelnianiem. Widoczna strona portalu potwierdza jedynie, że klient dociera do lokalnej usługi. Nazwa użytkownika, hasło, token SSO, grupa i późniejsza reguła firewall nie zostały jeszcze sprawdzone.

Sprawdzenie metody uwierzytelniania dla każdej usługi

W Authentication > Services każda usługa ma własny wybór serwerów. Nie wystarczy więc sprawdzić, czy istnieje serwer AD, LDAP, RADIUS lub Entra. Trzeba potwierdzić, że jest wybrany dla danej usługi:

• Firewall authentication methods dla ruchu użytkowników i klasycznego uwierzytelniania firewalla;
• User portal authentication methods dla User Portal;
• VPN portal authentication methods dla VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods dla tych logowań VPN;
• Administrator authentication methods dla nazwanych administratorów;
• SSL VPN authentication methods dla SSL VPN.

Firewall obsługuje łącznie maksymalnie 20 serwerów uwierzytelniania; dla każdej metody uwierzytelniania można również wybrać maksymalnie 20 serwerów. Brak kolejnego serwera podczas dodawania lub na liście wyboru nie oznacza więc automatycznie błędu połączenia. Najpierw trzeba sprawdzić łączną liczbę, wybór i rzeczywistą potrzebę każdego serwera.

User Portal i VPN Portal mogą przejąć listę serwerów uwierzytelniania firewalla przez Set authentication methods same as firewall. SSL VPN może analogicznie użyć Same as VPN lub Same as firewall. Takie dziedziczenie jest wygodne, ale rozszerza wpływ późniejszych zmian wyboru lub kolejności serwerów. Dlatego podczas diagnozy zawsze trzeba udokumentować faktycznie odziedziczoną listę. Administrator authentication methods nie obowiązuje ponadto lokalnego superadministratora admin; jego ścieżkę odzyskiwania dostępu zachowuje się i testuje oddzielnie.

Globalne limity sesji należy sprawdzać oddzielnie: Maximum session timeout kończy uwierzytelnioną sesję po osiągnięciu maksymalnego czasu. SFOS sprawdza autoryzację co trzy minuty; Access Policies, Surfing Quota, Data Transfer Limit i maksymalny czas sesji mogą wcześniej ograniczyć dostęp. Globalna wartość Simultaneous logins obowiązuje tylko użytkowników utworzonych po jej ustawieniu.

W SFOS 22 i SFOS 23 należy również oddzielnie sprawdzić wartości właściwe dla poszczególnych metod w Authentication > Services: sekcje AD SSO settings (NTLM and Kerberos) i Web client settings (iOS, Android and API) mają własne ustawienia Inactivity time i Data transfer threshold. Jeśli w ustawionym czasie przesłano mniej niż minimalną ilość danych, użytkownik jest uznawany za nieaktywnego; Inactivity time określa, po jakim czasie nieaktywności zostanie wylogowany. W przypadku nieoczekiwanego wylogowania najpierw udokumentować używany Client Type, obie wartości z odpowiedniej sekcji oraz rzeczywisty ruch w tym samym przedziale czasu. Nie zmieniać zamiast tego globalnego ustawienia Maximum session timeout ani liczników czasu STAS lub Captive Portal.

Przy wielu serwerach ważna jest również kolejność. Nie należy przedwcześnie przesuwać serwera na początek. Najpierw trzeba udokumentować bieżącą kolejność, Default Group oraz działającego użytkownika porównawczego. W przeciwnym razie zmiana może wpłynąć na innych użytkowników lub usługi. W przypadku zewnętrznych administratorów TACACS+ dla WebAdmin Sophos Firewall dodatkowo rozdziela uwierzytelnianie serwera, lokalny profil administratora i bezpieczny fallback chroniący przed utratą dostępu.

Zastąpić eDirectory przed aktualizacją: Natywna integracja eDirectory dotyczy SFOS 22. Przed aktualizacją do SFOS 23.0 lub nowszego należy zweryfikować obsługiwane rozwiązanie zastępcze dla wszystkich dotkniętych usług i usunąć natywną konfigurację eDirectory; pozostawienie jej spowoduje niepowodzenie aktualizacji. Nie usuwać uwierzytelniania produkcyjnego przed sprawdzeniem logowania przez nowe rozwiązanie, grup, polityk i niezależnego lokalnego dostępu awaryjnego. Bezpieczna migracja eDirectory opisuje kontrolowane przełączenie i przywracanie dostępu.

Właściwa interpretacja Test connection

W Authentication > Servers funkcja Test connection sprawdza poświadczenia i połączenie między firewallem a serwerem. Jeśli test zawodzi, najpierw należy poprawić DNS, routing, port, zabezpieczenie połączenia, łańcuch certyfikatów, konto usługi lub hasło.

Udany test jest jednak tylko pierwszą warstwą. W przypadku AD SSO nie sprawdza Kerberos, NTLM, SPN, Redirection Location, zaufania przeglądarki ani rzeczywistego dostępu użytkownika. Także dla logowań do portalu i VPN wybór usługi, grupę, MFA i politykę trzeba przetestować oddzielnie. Łączenie Active Directory z Sophos Firewall opisuje pełną konfigurację podstawową AD.

Użycie Live Users jako pierwszego potwierdzenia tożsamości

Po nowym logowaniu otworzyć Current activities > Live users. Istotne są co najmniej trzy wartości:

Limit pojemności: SFOS 22 obsługuje maksymalnie 32,000 aktywnych użytkowników. Użytkownicy i grupy współdzielą zakres User ID; w diagnostyce widoczny identyfikator do 65535 włącznie jest prawidłowy. W bardzo dużych środowiskach limit ten należy sprawdzać oddzielnie od pojedynczego nieudanego logowania. Nie należy niekontrolowanie usuwać sesji ani obiektów użytkowników.

Dla Client Authentication Agent typ klienta musi mieć wartość Authentication agent. Oddzielnie należy też sprawdzić ścieżkę do 1.2.3.4:9922, Authentication Server CA oraz rzeczywiste dopasowanie reguły firewall.

• User: czy wykryty użytkownik to rzeczywiście konto pilota?
• IP address: czy adres odpowiada obserwowanemu połączeniu klienta?
• Client Type: czy użyto oczekiwanej ścieżki, na przykład AD SSO Kerberos, AD SSO NTLM, STAS, Multi-host client, Captive portal, RADIUS SSO lub typu VPN?

Typ należy interpretować według jego źródła, a nie jako ogólne logowanie. Sesje Captive Portal w przeglądarce i sesje gości są wyświetlane jako Web client, Android web client lub iOS web client. Mapowania inicjowane przez klienta obejmują STAS, Thin client, Heartbeat i API, natomiast SSO inicjowane przez serwer obejmuje RADIUS SSO i Chromebook SSO. eDirectory SSO znajduje się na liście tylko w SFOS 22; w SFOS 23 usunięto natywne eDirectory SSO i ten typ nie jest już wymieniany. Wpisy VPN rozróżniają IPsec VPN, SSL VPN, L2TP VPN i PPTP VPN. Zaobserwowany typ musi odpowiadać zamierzonemu mechanizmowi.

Clientless Users stanowią wyjątek od testu z nowym logowaniem: pojawiają się na liście od razu po skonfigurowaniu, ponieważ SFOS uwierzytelnia ich na podstawie adresu IP, a po ustawieniu statusu Inactive nie są wyświetlani.

Jeśli użytkownika brakuje, warstwa tożsamości nie zakończyła się powodzeniem. Nie należy wtedy diagnozować późniejszej reguły użytkownika. Jeśli zamiast zalogowanego użytkownika pojawia się nazwa komputera, usługa systemu operacyjnego, taka jak Windows Update, mogła wysłać poświadczenia NTLM urządzenia. Rzeczywiste interaktywne logowanie użytkownika i nowe żądanie web pozwalają odgraniczyć ten przypadek.

Zewnętrzny użytkownik AD, LDAP lub RADIUS zwykle pojawia się w Authentication > Users dopiero po pierwszym udanym logowaniu do usługi firewalla. Brak lokalnego rekordu użytkownika nie dowodzi zatem, że konta brakuje w katalogu. Dla konta zarządzanego bezpośrednio w SFOS tworzenie i zarządzanie zwykłymi lokalnymi użytkownikami opisuje natomiast cały proces dotyczący konta, usługi, testów i offboardingu.

Aby czysto powtórzyć test, należy wybrać istniejącą zwykłą sesję w Live users, kliknąć Disconnect, w razie potrzeby zmienić tekst powiadomienia i potwierdzić przez Disconnect. Po ręcznym rozłączeniu sesji AD SSO mogą upłynąć do trzech minut, zanim użytkownik będzie mógł zalogować się ponownie. Powiadomienie otrzymują wyłącznie użytkownicy zalogowani przy użyciu Authentication agent, Android client, iOS client lub Chromebook SSO.

Clientless Users nie wylogowuje się opcją Disconnect. Zamiast tego należy ustawić danego użytkownika na Inactive w Authentication > Clientless users. Jeśli opcja Disconnect została już użyta wobec Clientless User i trzeba przywrócić dostęp, należy zmienić jego status na Inactive, a następnie na Active.

Sprawdzenie obiektu użytkownika, grupy głównej i ograniczeń

Gdy użytkownik jest widoczny lub istnieje już lokalny rekord, przejść do Authentication > Users. Nie zmieniać wartości w ciemno, lecz najpierw udokumentować skuteczne właściwości:

• status Active lub Inactive;
• pole Group jako grupa główna użytkowników AD;
• Other group memberships;
• indywidualne wyjątki polityk użytkownika;
• Access Time i Sign-in Restriction;
• Surfing Quota i Network Traffic Quota;
• przypisanie MFA dla danej usługi;
• dodatkowa właściwość User ID.

Nie utożsamiać grupy głównej z innymi grupami

Użytkownik AD może należeć do kilku grup. Sophos Firewall pokazuje skuteczną grupę główną w polu Group, a pozostałe członkostwa oddzielnie. Reguły firewall, polityki web i niektóre inne funkcje mogą uwzględniać wiele grup. Access Time, limity, MFA i kilka funkcji dostępu zdalnego wykorzystują natomiast wyłącznie grupę główną lub jawne przypisanie użytkownika.

Dlatego nie należy zmieniać kolejności grup jako szybkiej poprawki. Najpierw trzeba ustalić, która funkcja zawodzi i jaką logikę grup obsługuje. Po planowanej zmianie ponownie uwierzytelnić użytkownika i jeszcze raz sprawdzić grupę główną.

Pełną procedurę eksploatacyjną od utworzenia grup i Default Group po Reorder, wiele grup, wyjątki użytkowników i wycofanie opisuje artykuł Prawidłowe zarządzanie grupami użytkowników i grupą główną w Sophos Firewall.

Traktowanie Access Time, limitów i MFA jako osobnych przyczyn

Nieoczekiwany Captive Portal lub odrzucone logowanie może też wynikać z zablokowanego Access Time, wyczerpanej Surfing Quota lub Network Traffic Quota albo braku rejestracji MFA. Należy porównać te ustawienia dla użytkownika i jego skutecznej grupy.

Odpowiednie kontrole i ścieżki przywracania opisano w Access Time dla użytkowników i grup, Surfing i Network Traffic Quota oraz MFA dla Sophos Firewall. Nie resetować limitu ani nie rozszerzać polityki Access Time przed wykazaniem jej faktycznego przypisania.

Jeśli zawodzi tylko MFA, należy sprawdzić Issued tokens, status tokena oraz czas firewalla i telefonu. Synchronize token time offset pozwala wykryć i skorygować rozbieżność czasu. SFOS 22 obsługuje SHA1, SHA256 i SHA512; aplikacja uwierzytelniająca musi obsługiwać skonfigurowany algorytm. Zmiana algorytmu lub usunięcie tokena nie jest testem diagnostycznym, lecz planowaną migracją albo ponowną rejestracją.

Przypisanie limitu User ID dopiero po zobaczeniu wartości

W Show additional properties można wyświetlić User ID. Wartość powyżej 65535 wykracza poza obsługiwany zakres; użytkownik nie może wtedy zostać uwierzytelniony ani stać się Live User. Sama liczba widocznych użytkowników nie wystarcza do tej diagnozy, ponieważ grupy korzystają z tego samego zakresu ID.

Jeżeli ID jest prawidłowe lub użytkownika nadal całkowicie brakuje, należy kontynuować ogólną diagnostykę. Purge AD users należy stosować tylko w potwierdzonym przypadku czyszczenia. Bezpieczna procedura specjalistyczna znajduje się w Sprawdzanie limitu User ID Sophos Firewall.

Dalsze sprawdzanie używanej metody

Gdy usługa i warstwa błędu są znane, należy pogłębić tylko odpowiednią ścieżkę metody. Dzięki temu diagnostyka pozostaje wąska i nie zmienia jednocześnie kilku systemów uwierzytelniania.

Klasyczne logowanie i Captive Portal

Przy logowaniu ręcznym sprawdzić bezpośredni adres URL portalu, Device Access, wybraną metodę uwierzytelniania, status użytkownika, hasło i MFA. Przy Captive Portal dodatkowo sprawdzić, czy nieznane połączenie trafia do zamierzonej reguły z Use web authentication for unknown users i czy DNS działa przed logowaniem. Nazwa użytkownika i hasło mogą mieć najwyżej po 50 znaków.

Pełną konfigurację, w tym port 8090, Live Users, regułę użytkownika i wylogowanie, opisano w Konfiguracja i testowanie Sophos Firewall Captive Portal.

AD SSO z Kerberos lub NTLM

Udany test połączenia AD nie wystarcza dla SSO. Poprawne muszą być również nazwa hosta lub FQDN, rozwiązywanie DNS, Redirection Location, certyfikat, zaufanie przeglądarki, Domain Join oraz, dla Kerberos, właściwy HTTP SPN. Jeśli Kerberos przechodzi na NTLM lub Captive Portal, najpierw sprawdzić tę ścieżkę nazw i zaufania.

nasm.log ma znaczenie dla błędów NTLM i Kerberos. Nie zmieniać w ciemno SPN ani Domain Join; najpierw zabezpieczyć istniejący stan na firewallu i kontrolerze domeny.

Jeśli /log/nasm.log pokazuje błąd KVNO, po ponownym dołączeniu firewalla do domeny klient może nadal mieć bilet Kerberos ze starą wersją klucza. Najpierw zablokować i odblokować klienta Windows albo wylogować i ponownie zalogować użytkownika, aby pobrać nowy bilet. Jeśli błąd pozostaje, sprawdzić Key Version Number, obiekt komputera firewalla i SPN na kontrolerze domeny; kolejne wykonanie Domain Join nie jest pierwszym krokiem.

STAS, SATC i hosty wielu użytkowników

W przypadku Synchronized User ID Authentication tożsamość domenowa Windows i adres IP klienta docierają przez Security Heartbeat. Stan endpointu, domena UPN, sAMAccountName, weryfikacja AD i Live users muszą być zgodne; sam zielony heartbeat nie potwierdza reguły użytkownika.

W przypadku STAS ten sam adres IP klienta musi być śledzony przez zdarzenia Windows, STA Agent, Collector i firewall. Jeśli użytkownika brakuje tylko w Live Users, sprawdzić osiągalność Collectora, monitorowane sieci, Exclusion List i Client Authentication. Pełna procedura znajduje się w Konfiguracja STAS na Sophos Firewall.

Legacy SATC Client nie jest już obsługiwany. Sophos zaleca migrację instalacji SATC do Sophos Server Protection w Sophos Fusion. Przed diagnostyką należy ustalić, który klient SATC jest faktycznie zainstalowany; zmiana reguł firewalla lub grup nie naprawi przestarzałego klienta legacy.

Wielu równoczesnych użytkowników za jednym adresem IP serwera terminali wymaga modelu sesji. SATC dla Remote Desktop Services może przypisać wiele protokołów do sesji. Per-Connection AD SSO dla hostów wielu użytkowników dotyczy natomiast tylko połączeń HTTP i HTTPS przez Direct Web Proxy. Zwykłe mapowanie oparte na IP nie potrafi niezawodnie odróżnić wielu użytkowników za tym samym adresem.

RADIUS SSO, Entra ID i VPN

RADIUS SSO wymaga zdarzeń accounting z prawidłowym adresem IP klienta; udany test dostępu RADIUS nie dowodzi tej ścieżki accounting. RADIUS SSO z accounting opisuje konfigurację i kontrolę Framed-IP-Address. VPN Portal nie obsługuje uwierzytelniania RADIUS z MFA typu challenge, więc odrzucony tam przepływ challenge nie oznacza błędu kolejności serwerów.

SFOS 22: W przypadku Microsoft Entra ID SSO należy dodatkowo sprawdzić przepływ OAuth właściwy dla usługi. Captive Portal, VPN Portal i WebAdmin używają różnych Redirect URIs, metod uwierzytelniania i plików logów. Udane logowanie do jednej z tych usług nie dowodzi działania pozostałych.

SFOS 23.0: W Authentication > Servers typem serwera jest OpenID Connect; IdP vendor rozróżnia Microsoft Entra ID i Google Workspace. Dla faktycznie dotkniętej usługi użyć procedur weryfikacji odpowiednich dla wersji: Entra WebAdmin, Entra VPN Portal i dostęp zdalny lub Google Workspace OIDC. Redirect URI, przypisanie usługi, grupy lub mapowanie administratora, MFA oraz testy pozytywne, negatywne i lokalnego dostępu awaryjnego pozostają osobnymi kontrolami. Udane logowanie u IdP nie nadaje automatycznie uprawnień administratora.

W przypadku VPN po uwierzytelnieniu trzeba także sprawdzić, czy użytkownik lub jego grupa znajduje się we właściwej polityce dostępu zdalnego. Zielony status tunelu nie dowodzi jeszcze dostępu do wewnętrznych celów.

Uwierzytelnianie działa, ale ruch nadal jest blokowany

Gdy użytkownik jest widoczny w Live users z oczekiwanym adresem IP, diagnostyka przechodzi do autoryzacji i ścieżki pakietów. Rzeczywisty przepływ testowy musi pokazać:

1. Która Firewall Rule ID przetwarza połączenie?
2. Czy reguła zawiera oczekiwanego użytkownika lub obsługiwaną grupę?
3. Czy Log firewall traffic jest włączone?
4. Czy reguła wybiera właściwą politykę web, Application, IPS lub Traffic Shaping?
5. Czy cel, usługa, NAT, route i ścieżka powrotna są zgodne?

Ogólna reguła IP nad regułą użytkownika może już przetwarzać ruch. Podobnie właściwa reguła użytkownika może pasować, podczas gdy polityka web, TLS Inspection, DNS, routing lub system docelowy blokuje późniejszy dostęp. Dlatego zmiany uwierzytelniania nie należy używać jako naprawy potwierdzonego błędu routingu lub polityki.

Prawidłowe testowanie reguły Sophos Firewall opisuje pełną weryfikację za pomocą Log Viewer, Policy tester i Packet Capture.

Korelacja Log Viewer i plików logów

W Log viewer sprawdzić moduł Authentication dla zanotowanego użytkownika, źródłowego adresu IP i wąskiego przedziału testowego. Następnie znaleźć ten sam czas w module firewall lub VPN. Pozwala to ustalić, czy zawodzi samo logowanie, czy dopiero późniejszy przepływ danych jest blokowany.

Dla klasycznego uwierzytelniania, autoryzacji i accounting pierwszym sprawdzanym plikiem jest access_server.log. W Advanced Shell następujące polecenia są tylko do odczytu:

cd /log
tail -n 200 access_server.log

Dodać tylko plik odpowiedni dla danej metody:

tail -n 200 nasm.log

Poniższe przykłady odczytu logów Entra właściwych dla usługi dotyczą tylko SFOS 22, nie 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 dotyczy NTLM i Kerberos.
• SFOS 22: oauth_sso_captive.log dotyczy przepływu Entra SSO dla Captive Portal.
• SFOS 22: oauth_sso_webadmin.log dotyczy Entra SSO dla WebAdmin.
• SFOS 22: oauth_sso_vpn.log dotyczy Entra SSO dla VPN Portal, IPsec i SSL VPN.

SFOS 23.0: Sprawdzić przepływ logowania OIDC w /log/oauth_sso_svc.log. Dla Entra błąd TLS funkcji Test connection należy natomiast sprawdzić w /log/sfos-macro-cfg.log. W Log viewer używać modułu Admin dla WebAdmin oraz Authentication dla Captive Portal, VPN Portal, IPsec i SSL VPN. Procedury dostawców podlinkowane powyżej dopasowują weryfikację i diagnostykę do faktycznej usługi; ta diagnostyka tylko do odczytu nie wymaga restartu.

Polecenia odczytują tylko ostatnie 200 wierszy. Nie włączają debugowania i nie restartują usług. Pliki takie jak vpnportal.log, sslvpn.log, strongswan.log, chromebook-sso-backend.log lub csd.log dodawać dopiero po wybraniu metody. Logi usług Sophos Firewall wyjaśniają przypisanie.

W klastrze HA każdy węzeł przechowuje logi i raporty wyłącznie dla ruchu, który sam przetwarza. Należy zanotować rolę, czas testu i węzeł przetwarzający, a następnie sprawdzić pliki na tym węźle. Pusty plik na drugim urządzeniu nie obala błędu.

Zawężanie błędu według objawu

Test connection działa, ale SSO nie

Serwer uwierzytelniania i jego poświadczenia są osiągalne. Następnie sprawdzić Authentication > Services, Device Access, Live Users oraz ścieżkę SSO właściwą dla metody. W przypadku AD obejmuje to szczególnie DNS, FQDN, Redirection Location, SPN, zaufanie przeglądarki, Domain Join i nasm.log.

Captive Portal pojawia się zamiast przezroczystego logowania

Najpierw ustalić, czy AD SSO lub STAS powinno rozpoznać użytkownika przed dostępem web. Następnie sprawdzić Client Type w Live Users, moduł Authentication, Access Time, limity i poświadczenia. Portal jest objawem brakującej lub odrzuconej tożsamości, a nie automatycznie błędem portalu.

Zamiast nazwy użytkownika pojawia się nazwa komputera

Usługa systemowa może wysłać poświadczenia NTLM endpointu, mimo że żaden użytkownik nie zalogował się jeszcze interaktywnie. Zalogować rzeczywistego użytkownika, otworzyć nową sesję przeglądarki i powtórzyć test. Jeśli nazwa komputera pozostaje, sprawdzić ścieżkę przeglądarki lub proxy, metodę SSO i nasm.log.

Użytkownika brakuje w Live Users

Najpierw sprawdzić wybór usługi, Device Access i konkretną metodę. W STAS Collector i firewall muszą widzieć ten sam adres IP; przy Captive Portal logowanie musi rzeczywiście się zakończyć; dla serwerów zewnętrznych lokalny rekord użytkownika jest tworzony dopiero po udanym logowaniu. User ID, Sign-in Restriction i limity sprawdzać tylko wtedy, gdy istnieje odpowiedni rekord użytkownika.

Użytkownik jest widoczny, ale grupa lub polityka jest niewłaściwa

W Authentication > Users porównać grupę główną, Other group memberships i wyjątki użytkownika. Następnie sprawdzić, czy dana funkcja obsługuje wiele grup. Kolejność grup zmieniać tylko w planowanym oknie serwisowym, ponieważ może to również przesunąć MFA, limity, Access Time, VPN i inne polityki.

Logowanie działa, ale internet lub cel VPN pozostaje nieosiągalny

Uwierzytelnianie nie jest już pierwszą warstwą błędu. Za pomocą rzeczywistego przepływu sprawdzić Firewall Rule ID, kolejność reguł, logging, politykę web lub VPN, NAT, route i ścieżkę powrotną. Zarówno tożsamość użytkownika, jak i ścieżka pakietów muszą być prawidłowe.

Błąd występuje tylko po przełączeniu HA lub sporadycznie

Zanotować build firmware, zmianę ról, aktywną rolę węzła, czas logowania i metodę uwierzytelniania. Po przełączeniu przetestować nowe logowanie i nowe połączenie. Następnie sprawdzić logi na węźle, który obsłużył próbę. Nie uznawać istniejącej sesji za dowód nowego udanego uwierzytelnienia.

Warunki zatrzymania i dane dla wsparcia

Nie wprowadzać dalszych zmian w konfiguracji produkcyjnej, gdy:

• nie można jednoznacznie określić danej usługi lub metody uwierzytelniania;
• Test connection zawodzi, a DNS, route, port, TLS lub poświadczenia pozostają niewyjaśnione;
• użytkownik pilota pojawia się z nieoczekiwanym Client Type lub błędnym źródłowym adresem IP;
• nie można wyjaśnić przypisania grupy głównej, wyjątku użytkownika lub limitu;
• test negatywny niespodziewanie uzyskuje dostęp;
• tylko szerokie zezwolenie Device Access lub firewall pozornie umożliwia test;
• problemu HA nie można przypisać do węzła przetwarzającego i czasu.

Przed eskalacją zabezpieczyć co najmniej:

• model urządzenia, wersję SFOS i pełny build;
• w HA obie role i węzeł przetwarzający;
• źródło uwierzytelniania i daną usługę;
• użytkownika testowego, źródłowy adres IP, Client Type i przedział czasu;
• kolejność serwerów w Authentication > Services;
• wynik Test connection wraz z jego ograniczonym znaczeniem;
• status, grupę główną, inne grupy, wyjątki i User ID;
• zdarzenie uwierzytelniania, Firewall Rule ID i wynik rzeczywistego przepływu testowego;
• odpowiednie logi uwierzytelniania, portalu, VPN i firewalla.

Nazwy użytkowników i grup mogą zawierać informacje wrażliwe. Pakiet należy udostępniać wyłącznie przewidzianym kanałem wsparcia. Przed restartem usług, debugowaniem lub czyszczeniem danych utworzyć Consolidated Troubleshooting Report i ukierunkowany eksport logów.

Lista kontrolna

• Przypadek testowy zawiera użytkownika, źródłowy adres IP, usługę, czas i oczekiwany wynik.
• Lokalna usługa jest osiągalna tylko z planowanej strefy lub źródła.
• Właściwy serwer jest wybrany w Authentication > Services dla danej usługi.
• Test connection nie został pomylony z pełnym testem SSO.
• Live Users pokazuje użytkownika, IP i oczekiwany Client Type.
• Sprawdzono status, grupę główną, inne grupy, wyjątki i User ID.
• Access Time, limity, Sign-in Restriction i MFA oceniono tylko dla skutecznej ścieżki użytkownika.
• Powodzenie uwierzytelniania i późniejszy przepływ firewall, web lub VPN przetestowano oddzielnie.
• Log Viewer i pasujący plik logu skorelowano w tym samym przedziale czasu.
• W HA sprawdzono węzeł przetwarzający.
• Nie użyto ogólnego restartu, purge ani szerokiego zezwolenia jako szybkiej poprawki.
• Dane dla wsparcia zabezpieczono przed dalszymi zmianami.

Często zadawane pytania