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.

Rozróżniać skończone limity API i Unlimited: Dokumentacja starszego XML API dla SFOS 22 i SFOS 23 podaje dla MaximumSessionTimeoutMinutes skończony zakres 3–1440 minut, a dla SimultaneousLogins zakres 1–99 jednoczesnych logowań. Przykład pokazuje natomiast Unlimited/{minutes} i Unlimited/{count}; tabela zawiera obok wierszy liczbowych INTEGER oddzielne wiersze STRING dla Unlimited. Opcja Unlimited oznacza brak ograniczenia, ale jej reprezentacja w atrybutach i treści żądania wymaga osobnego potwierdzenia. Sekwencje z ukośnikami nie są wartościami literalnymi do użycia w środowisku produkcyjnym. Puste kolumny wartości domyślnych lub opcjonalne pola nie oznaczają ani określonego zachowania przy pominięciu pola, ani tego, że zero lub pusta wartość oznacza Unlimited. Najpierw odczytać faktycznie zapisany wybór i obowiązujące limity użytkowników; globalny limit logowań nadal dotyczy wyłącznie użytkowników utworzonych później. Niejasności dotyczące automatyzacji wyjaśnić ze wsparciem technicznym dla konkretnego buildu przed operacją zapisu w środowisku produkcyjnym.

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.

NTLM: porównać minuty i bajty. Dokumentacja starszego API dla SFOS 22 i SFOS 23 podaje dla NTLMInActivtyTime wartość domyślną 6 minut i zakres 6–1440 minut, a dla NTLMDataTransferThreshold wartość domyślną 1024 bajty. Dla progu wyrażonego w bajtach podaje jedynie maksymalnie dziesięć cyfr, a nie pełny zakres liczbowy; nie należy na tej podstawie wywnioskować minimum ani maksimum. Pisownia InActivty została przejęta dosłownie z API, podobnie jak NTLMChallegeRedirect dla przekierowania challenge: nie zmieniać ich po cichu na klucze uznane za poprawne. Te wartości z dokumentacji nie są wartościami odczytanymi z własnego firewalla i nie stanowią powodu do przywracania wartości domyślnych w środowisku produkcyjnym ani wyłączania HTTP challenge redirect on intranet zone.

Klient web iOS: używać zakresu udokumentowanego dla tej metody. Ta sama dokumentacja starszego API podaje dla iOSWebClientInActivtyTime wartość domyślną 6 minut i zakres 6–1440 minut, a dla iOSWebClientDataTransferThreshold wartość domyślną 1024 bajty i zakres 1–4294967295 bajtów. Minuty to nie sekundy, a bajty to nie kilobajty. Również tutaj pisownia API InActivty pozostaje bez zmian. Operacja dla iOS nie potwierdza identycznych kluczy ani zakresów liczbowych dla Androida lub klientów API, mimo że GUI wymienia te typy klientów we wspólnej sekcji klienta web.

W przypadku tych limitów najpierw, wyłącznie w trybie odczytu, porównać zapisany stan w Authentication > Services, rzeczywisty Client Type, jednostki oraz — w przypadku nieudanej próby użycia API — żądanie i odpowiadającą mu odpowiedź, bez sekretów. Odrzucenie wartości nie dowodzi, że została zapisana; udokumentowana wartość domyślna nie dowodzi, że jest obecnie ustawiona. Za pomocą nowego logowania użytkownika pilotażowego, ruchu skorelowanego czasowo i opisanych poniżej logów uwierzytelniania sprawdzić, czy wylogowanie odpowiada faktycznie zapisanej parze wartości czasu i progu w bajtach. Przed zatwierdzoną korektą zabezpieczyć dotychczasowe wartości i sprawdzić lokalny dostęp do zarządzania, który nie zależy od badanej zewnętrznej ścieżki uwierzytelniania. Następnie ponownie sprawdzić zapisany stan, logowanie użytkownika pilotażowego, Client Type, test negatywny i dopasowanie reguły. W razie nieoczekiwanego działania przywrócić wyłącznie udokumentowane wartości objęte zmianą i ponownie odczytać stan, zamiast ogólnie używać Reset to default.

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.

Interpretacja list uwierzytelniania VPN w XML API

Przy zautomatyzowanych zmianach wybór usługi i listę serwerów sprawdza się oddzielnie. Poniższe ścieżki XML dotyczą źródła uwierzytelniania, a nie siły zabezpieczeń protokołu VPN, szyfrowania ani konfiguracji MFA.

• Dla SSL VPN selektor znajduje się pod ścieżką SSLVPNAuthentication/SSLVPNAuthenticationMethods. W SFOS 22 i SFOS 23 przykład i tabela parametrów są zgodne: SameAsVPN, SameAsFirewall i Custom to udokumentowane wartości. Pierwsze dwie przejmują odpowiednio listę uwierzytelniania VPN lub firewalla; Custom oznacza własny wybór serwerów pod ścieżką SSLVPNAuthentication/SSLVPNAuthenticationServerList/AuthenticationServer.
• Dla pozostałego uwierzytelniania VPN przykład pod ścieżką VPNAuthentication/VPNAuthenticationMethods pokazuje natomiast SameAsFirewall/Custom, z listą serwerów pod ścieżką VPNAuthentication/VPNAuthenticationServerList/AuthenticationServer. Tabela parametrów łączy jednak VPNAuthenticationMethods/UserPortalAuthenticationMethods i dopuszcza wyłącznie tokeny zapisane jako ''on'' i ''off''. Ta sprzeczność występuje w obu wersjach. Nie można z niej wywnioskować zweryfikowanego sposobu przeliczania wartości z przykładu na wartości z tabeli; nie potwierdza ona również istnienia aliasów ani zgodności selektorów z User Portal. Dlatego nie należy automatycznie zmieniać selektora VPN w środowisku produkcyjnym na podstawie tego przyporządkowania, lecz wyjaśnić sprzeczność ze wsparciem technicznym dla konkretnego buildu.

Dla obu list serwerów tabela opisuje AuthenticationServer jako opcjonalny ARRAY o typie danych STRING, dopuszczający wiele wartości. Nazwy serwerów muszą odpowiadać własnej konfiguracji. Selektor SSL VPN jest oznaczony jako opcjonalny SCALAR, a połączony wpis VPN/User Portal w tabeli jako obowiązkowy SCALAR. Kolumny wartości domyślnych są puste; nie potwierdza to żadnego zachowania w przypadku pominiętych lub pustych pól. Sekwencje rozdzielone ukośnikami w przykładzie nie są gotowymi wartościami do wysłania bez zmian.

Przed zatwierdzoną zmianą zabezpieczyć bieżący wybór, kolejność, faktycznie odziedziczoną listę i przetestowaną lokalną ścieżkę odzyskiwania dostępu. Następnie sprawdzić zapisany stan w Authentication > Services, nowe logowanie użytkownika pilotażowego, Client Type, test negatywny i rzeczywiste dopasowanie reguły. W razie nieoczekiwanego wyniku odczytać zapisany stan i odpowiednie logi, zamiast ponownie zapisywać w ciemno; w razie potrzeby przywrócić wyłącznie udokumentowaną konfigurację objętą zmianą.

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 i SFOS 23 obsługują 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, Web client, 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ć sesję użytkownika na kliencie 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.

Walidacja API przed diagnostyką sieciową accounting: Dokumentacja starszego XML API dla SFOS 22 i SFOS 23 ogranicza SharedSecret do 50 znaków. Dłuższy wygenerowany sekret może zatem wyjaśniać odrzucenie konfiguracji, a nie błąd sieciowy accounting. ClientIP jest tam udokumentowany jako wielowartościowy ARRAY o typie danych IPADDRESS i maksymalnej długości 15 znaków; pozycja w GUI to RADIUS client IPv4. Nie jest to potwierdzenie obsługi IPv6. Skopiowany opis iOS na stronie API RADIUS jest błędem dokumentacji, a nie informacją o zgodności RADIUS z iOS. Najpierw porównać rzeczywistego nadawcę z zapisanym dozwolonym adresem IP klienta i bezpiecznie sprawdzić zgodność konfiguracji sekretu po obu stronach; nigdy nie ujawniać rzeczywistych sekretów ani nie umieszczać ich w logach, na zrzutach ekranu lub w pakietach dla wsparcia. Nie skracać, nie osłabiać ani nie rotować sekretów produkcyjnych w celach diagnostycznych. W razie błędu API odczytać odpowiedź oczyszczoną z danych wrażliwych i faktycznie zapisany stan, zamiast ponownie zapisywać w ciemno. Konieczna zmiana poświadczeń jest zmianą wymagającą oddzielnego zatwierdzenia i koordynacji po obu stronach, z zabezpieczonym lokalnym dostępem do zarządzania i udokumentowaną ścieżką wycofania; następnie sprawdzić zapisaną konfigurację, zdarzenie accounting, użytkownika/IP w Live users i dopasowanie reguły.

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.

Kontrole właściwe dla metody przed zmianą konfiguracji

AD SSO: czas, DNS i bezpieczna diagnostyka

Porównaj zegary klienta, zapory i kontrolera domeny. Bilety Kerberos mają ograniczoną ważność; domyślna tolerancja wynosi pięć minut, ale decydują ustawienia zasad domeny. Sprawdź rozwiązywanie _ldap._tcp.dc._msdcs.<AD domain> i zapytania wyszukiwania AD. Odczyt grup katalogowych i dołączenie zapory do domeny wymagają różnych uprawnień: zachowaj konto z odpowiednio delegowanymi uprawnieniami do ponownego dołączenia po zmianach HA, aktualizacji lub zmianie serwera. Nie nadawaj zwykłemu użytkownikowi testowemu uprawnień Domain Admin.

Instrukcje diagnostyczne proponują tymczasowe użycie Plaintext na porcie 389, podczas gdy konfiguracja AD obsługuje STARTTLS na 389 lub SSL/TLS na 636. Nie wyłączaj szyfrowania produkcyjnej ścieżki uwierzytelniania w celu zlokalizowania usterki. Sprawdź łańcuch TLS, nazwę, port i logi serwera AD; nierozwiązany błąd bezpiecznego połączenia przekaż do wsparcia. W Authentication > Services sprawdź HTTP challenge redirect on intranet zone, zamiast wyłączać tę opcję, aby ominąć zaufanie przeglądarki. Diagnozuj nazwę przekierowania i zaufanie intranetowe zgodnie z procedurą AD.

SATC i STAS: rejestracja a osiągalność

Dla SATC opcja 4. Device Console udostępnia kontrolę rejestracji tylko do odczytu:

system auth thin-client show

Porównaj wyświetlone adresy z serwerami terminalowymi. Jeśli brakuje serwera, zastosuj procedurę konfiguracji i przywracania SATC, bez nieplanowanej zmiany rejestracji. Sprawdź wybrany serwer AD, miejsce docelowe zdarzeń SATC oraz to, czy proxy lub oprogramowanie zabezpieczające zmienia porty źródłowe. Niezgodność portów może pozostawić ruch nieuwierzytelniony mimo zarejestrowanego adresu.

Dla STAS sprawdź, czy host Collector i usługa działają, UDP 6060 i 6677 są dozwolone wyłącznie na wymaganych ścieżkach, zabezpieczenia nie zakłócają komunikacji, a Collector z wieloma kartami NIC jest powiązany z właściwym interfejsem. Przez IPsec sprawdź źródło SNAT ruchu generowanego przez system. Podczas oczekiwania na identyfikację z Collectora SFOS może odrzucać ruch nieznanego użytkownika. Dwuminutowe opóźnienie portalu może wynikać z domyślnego okresu uczenia 120 sekund, a nie z awarii portalu. Nie skracaj go poniżej 20 sekund jako szybkiej naprawy. Zdarzenia Windows DCOM 10009 lub 10028 albo przypisania LogonType: 1 z niemonitorowanych sieci wymagają kontroli WMI i zgodności filtrów podsieci Agent/Collector. Zastosuj diagnostykę i kontrolowane przywracanie STAS; przed zmianami zapisz dotychczasowe filtry i czasomierze, a po wymaganym restarcie ponownie przetestuj użytkownika pilotażowego.

Chromebook SSO i SSL VPN

Chromebook SSO to inny mechanizm niż Google Workspace OIDC. W Authentication > Services > Chromebook SSO porównaj Domain, Port, Certificate i Logging level z konfiguracją zarządzanych urządzeń. Certyfikat wymaga klucza prywatnego, zainstalowanej powiązanej CA i CN zgodnego z zamierzoną nazwą bramy dla sieci użytkowników. Kontynuuj zgodnie z procedurą Chromebook SSO dotyczącą certyfikatu, rozszerzenia i reguł.

Dla SSL VPN porównaj użytkowników/grupy w zasadach dostępu zdalnego z Authentication > Multi-factor authentication i sprawdź dokładny błąd klienta. Nazwy użytkowników Sophos Connect muszą używać ASCII; sprawdź też nieobsługiwane sekwencje znaków specjalnych. Instrukcje SSL VPN wymieniają zarówno MFA przez połączenie/push, jak i <password><otp>; nie stanowią uniwersalnej procedury łączącej te metody. Dopisuj OTP tylko w skonfigurowanym przepływie hasło plus OTP, nie jako rozwiązanie nieudanego push lub połączenia. Potwierdź faktyczną metodę MFA i zgodność klienta/serwera w procedurze SSL VPN, bez wyłączania MFA.

W istniejących wdrożeniach L2TP/PPTP porównaj również wynegocjowany protokół: lokalnie i RADIUS obsługują PAP, CHAP lub MSCHAPv2; AD i LDAP używają PAP; TACACS+ obsługuje PAP lub CHAP. To kontrola zgodności, nie zalecenie wdrażania PPTP ani osłabiania szyfrowania. Po zatwierdzonej poprawce powtórz świeże logowanie, kontrolę typu klienta, test odmowy dostępu i dopasowanie reguły; jeśli poprawka nie pomaga, przywróć zapisaną konfigurację.

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