Konfiguracja Synchronized User ID Authentication na Sophos Firewall

Synchronized User ID Authentication łączy logowanie na zarządzanym endpoincie z Sophos Firewall. Sophos Endpoint przesyła tożsamość przez Security Heartbeat. W procesie AD dla SFOS 22 firewall weryfikuje użytkownika domenowego przez Active Directory; pomoc SFOS 23 opisuje dodatkowo Microsoft Entra ID z rozpoznawaniem UPN i pobieraniem grup. Pomyślnie przypisani użytkownicy pojawiają się w Current activities > Live users.

To rozwiązanie nadaje się do zarządzanych stacji roboczych, na których działają już Sophos Endpoint i Security Heartbeat. Nie wymaga dodatkowego agenta uwierzytelniania na kliencie ani serwerze. Sam Sophos Endpoint pozostaje jednak wymagany.

⚠️ Pomoc SFOS 22 potwierdza starszy proces AD dla Windows 10 i wyklucza inne usługi katalogowe. Nie można odnosić tego stwierdzenia ogólnie do SFOS 23: udokumentowano tam osobny proces Entra ID. Użytkownicy lokalni i urządzenia z Server Protection pozostają wykluczeni. Strona dotycząca SFOS 23 nie wymienia konkretnej wersji systemu operacyjnego; ani na tej podstawie, ani na podstawie udanego pilota nie należy wnioskować o dopuszczeniu dodatkowych systemów operacyjnych.

SFOS 23: tożsamość Entra przez Security Heartbeat

Ta ścieżka opisuje logowanie na endpoincie, a nie interaktywne logowanie SSO do VPN Portal lub WebAdmin. Integracja Entra musi być już prawidłowo skonfigurowana. Wspólna konfiguracja podstawowa Entra wyjaśnia aplikację, uprawnienia, serwer uwierzytelniania i import grup; samo logowanie VPN nie jest warunkiem tego pilota Heartbeat. W przypadku dostępu administratora obowiązuje osobno Entra ID dla WebAdmin.

Minimalne wymagania i rozpoznawanie tożsamości

Przed pilotem sprawdzić następujące wymagania:

• Firewall działa na przewidzianej kompilacji SFOS 23, jest połączony z Sophos Central lub Sophos Fusion i ma działający Security Heartbeat. Zachowane poniżej informacje licencyjne pochodzą wyraźnie z pomocy SFOS 22; nie dowodzą nowego ani zmienionego obowiązku licencyjnego w SFOS 23. Osobno sprawdzić uprawnienia dla rzeczywiście używanej wersji.
• Sophos Endpoint 2025.1 lub nowszy jest zainstalowany na zarządzanym urządzeniu pilotażowym. Pomoc SFOS 23 wymaga Endpoint na urządzeniach przyłączonych do domeny; nie należy z tego wywodzić dodatkowego dopuszczenia dowolnych modeli przyłączania ani systemów operacyjnych.
• Konto użytkownika używa tego samego adresu e-mail w Sophos Central/Fusion, na firewallu i w skonfigurowanym katalogu. Zalogowany użytkownik Entra musi dać się jednoznacznie przypisać.
• Microsoft Entra ID jest pomyślnie skonfigurowany na firewallu jako serwer uwierzytelniania. W Authentication > Servers sprawdzić serwer Entra i Test connection; skontrolować synchronizację czasu, osiągalność, uprawnienia aplikacji i import grup zgodnie z podlinkowaną konfiguracją podstawową.
• Endpoint przesyła prawidłowy UPN zalogowanego użytkownika Entra przez Heartbeat. Od Endpoint 2025.1 przesyłane są nazwa logowania, nazwa domeny i UPN; starsze wersje nie wysyłają UPN. Bez UPN firewall nie może przypisać Heartbeat do użytkownika Entra. Sam zielony Heartbeat zatem nie wystarcza.

⚠️ Nie synchronizować użytkowników jednej domeny jednocześnie przez AD i Entra ID. Wymagania Entra wykluczają takie połączenie. Nie traktować istniejącej ścieżki AD jako automatycznej migracji: najpierw ustalić odpowiedzialność katalogów i drogę powrotu; w przypadku niewyjaśnionego podwójnego przypisania zatrzymać pilota.

Proces Entra składa się z pięciu kroków:

1. Użytkownik loguje się kontem Entra ID na urządzeniu chronionym przez Sophos Endpoint.
2. Endpoint wysyła informacje o tożsamości do firewalla przez Security Heartbeat.
3. Firewall rozpoznaje użytkownika Entra na podstawie jego UPN. W odróżnieniu od ścieżki AD kluczem przypisania Entra nie jest tutaj sAMAccountName.
4. Firewall pobiera członkostwa w grupach Entra i aktywuje użytkownika z odpowiednimi politykami użytkownika i grup oraz odpowiednimi politykami Synchronized Security.
5. Użytkownik pojawia się w Current activities > Live users. Firewall nie używa ani nie udostępnia przy tym haseł.

Weryfikacja pilota Entra i autoryzacji

Przykładowe wartości dokumentacyjne to anna.muster@example.com, adres IP klienta 10.20.30.101, grupa pilotażowa Entra SFOS-Internet-Users i reguła LAN_User_Internet. UPN, IP i grupę zastąpić wartościami własnego pilota. Świadomie ograniczyć grupę do potrzebnych użytkowników testowych; sama nazwa nie dowodzi członkostwa ani uprawnień.

1. Udokumentować stan początkowy przypisania katalogowego, obiektów użytkowników i grup, reguł oraz węzłów HA, a także niezależny dostęp administracyjny. Używać zatwierdzonego klienta testowego i kont testowych; nie blokować ani nie usuwać kont produkcyjnych.
2. Zaimportować potrzebną grupę Entra zgodnie z konfiguracją podstawową i wybrać ją w ściśle ograniczonej, logowanej regule w Rules and policies > Firewall rules, używając Match known users i Users or groups. Ograniczyć źródło, cel i usługi do pilota; opisana dalej reguła pilotażowa pokazuje te pola.
3. Całkowicie wylogować użytkownika na urządzeniu pilotażowym i zalogować go ponownie kontem Entra. Sprawdzić łącznie Heartbeat i Current activities > Live users: oczekiwany użytkownik, adres IP klienta i Client Type: Heartbeat muszą odpowiadać logowaniu testowemu. Udokumentować faktycznie wyświetlaną tożsamość, nie zakładać konkretnej nazwy wyświetlanej.
4. Wygenerować nowy, dozwolony przepływ testowy i porównać w Log viewer użytkownika, źródło, cel, usługę, działanie, czas i Firewall Rule ID. Dopiero właściwy przepływ potwierdza działanie reguły; sam wpis w Live users nie potwierdza autoryzacji grupowej.
5. Sprawdzić tę samą ścieżkę docelową przy użyciu osobnego użytkownika testowego spoza grupy pilotażowej. Nie może on uzyskać dostępu przez regułę grupy pilotażowej. Nadal może zadziałać inna dozwolona reguła: udokumentować jej Rule ID zamiast oczekiwać ogólnej blokady całego dostępu.
6. Zweryfikować brak lub nieprawidłowy UPN, nieistniejące albo nieaktywne konto testowe Entra oraz brak osiągalności Entra z firewalla jako negatywne przypadki testowe. Zakłócenia wywoływać tylko w izolowanym, zatwierdzonym środowisku testowym, nie przez blokady obejmujące cały tenant ani globalne blokady sieciowe. Bez takiego środowiska udokumentować te przypadki jako otwarte, a nie jako pomyślnie przetestowane. Przy braku UPN nie oczekiwać przypisania Entra; dla błędów konta i osiągalności nie obiecywać konkretnego komunikatu błędu ani natychmiastowego wylogowania istniejących sesji.
7. W kontrolowany sposób sprawdzić utratę Heartbeat oraz uśpienie i wybudzenie. Przy braku Heartbeat zsynchronizowany użytkownik zostaje wylogowany; inne metody uwierzytelniania mogą nadal działać, a ruch może być przerwany do ponownego logowania. Poniższa sekwencja sprawdzania Heartbeat obowiązuje również tutaj.

Brak użytkownika Entra lub nieprawidłowa grupa

Przy zielonym Heartbeat bez pasującej tożsamości najpierw sprawdzić wersję Endpoint i faktycznie zgłaszany UPN. Następnie skontrolować, czy konto Entra istnieje i jest aktywne, czy usługi firewalla mogą dotrzeć do Entra i czy konfiguracja Entra została pomyślnie ukończona. W Authentication > Servers ponownie wykonać Test connection. Sam pomyślny test połączenia nie potwierdza ani UPN endpointu, ani autoryzacji grupowej.

Jeśli tożsamość jest widoczna, ale grupa lub reguła jest nieprawidłowa, porównać członkostwo Entra, zaimportowaną grupę firewalla, przypisanie użytkownika i kolejność reguł. Zachować dane dotyczące problematycznego przepływu wraz z Rule ID i czasem. Nie poszerzać reguł, nie usuwać obiektów użytkowników ani nie restartować usług zapobiegawczo. Na potrzeby eskalacji zachować kompilację SFOS, wersję Endpoint, zanonimizowany UPN, stan Heartbeat, adres IP klienta, przedział czasu i przetwarzający węzeł HA razem z wymienionymi poniżej logami.

HA i droga powrotu dla pilota Entra

Pomoc SFOS 23 również opisuje Synchronized User ID jako domyślnie aktywny i wymaga włączania lub wyłączania na obu urządzeniach HA. Zmiana stanu nie jest zapisywana w kopii zapasowej. Zachowane poniżej polecenia shell są udokumentowane również w SFOS 23; przełączają całą funkcję, a nie tylko Entra. Taki restart usługi nie jest więc nieszkodliwym wycofaniem pilota.

Failover testować tylko w zatwierdzonym oknie serwisowym z niezależnym dostępem administracyjnym. Na węźle przetwarzającym ruch po przełączeniu ponownie zweryfikować Heartbeat, nowe logowanie Entra, Live users, regułę grupową i nowy przepływ testowy. Nie zakładać bezprzerwowego przejęcia stanu użytkownika ani sesji; wymienione poniżej poprawki SFOS 22 nie stanowią nowej gwarancji failover dla SFOS 23.

W ramach drogi powrotu najpierw przywrócić udokumentowany stan początkowy reguły pilotażowej i przypisań pilotażowych, a następnie sprawdzić dotychczasową ścieżkę uwierzytelniania przy użyciu nowego logowania i rzeczywistego ruchu. Nie usuwać ani nie wyłączać globalnie aplikacji Entra, serwerów, uprawnień i grup współdzielonych przez VPN, portal lub WebAdmin w ramach porządkowania po teście. Jeśli w oknie serwisowym zmieniono również globalny stan Synchronized User ID, jawnie przywrócić zamierzony stan na obu węzłach i sprawdzić go osobno po przywróceniu z kopii. Drogę powrotu do AD aktywować ponownie dopiero wtedy, gdy synchronizacja Entra tej samej domeny zostanie zakończona w kontrolowany sposób.

Poniższe kroki i przykłady AD pozostają osobną, starszą ścieżką SFOS 22. Rozpoznawanie tożsamości AD jest opisane również w pomocy SFOS 23, ale nie zastępuje tam weryfikacji Entra.

SFOS 22 z AD: Synchronized User ID w ośmiu krokach

1. Wybrać jako pilota jednego klienta domenowego Windows 10 z Sophos Endpoint.
2. Sprawdzić Sophos Fusion (dawniej Sophos Central), Security Heartbeat i licencję firewalla.
3. Połączyć Active Directory jako serwer uwierzytelniania firewalla.
4. Porównać domenę UPN, sAMAccountName, adres e-mail i profil użytkownika pomiędzy AD, Sophos Fusion i firewallem.
5. Przygotować ściśle ograniczoną, logowaną regułę użytkownika dla grupy pilotażowej.
6. Zalogować się ponownie do Windows na urządzeniu pilotażowym i potwierdzić zielony heartbeat.
7. Sprawdzić użytkownika, adres IP i Client Type w Current activities > Live users oraz rzeczywisty ruch w Log Viewer.
8. Przetestować utratę heartbeat, zachowanie HA i kontrolowaną drogę powrotu przed dodaniem kolejnych endpointów.

Kiedy Synchronized User ID jest właściwym wyborem

Synchronized User ID nie zastępuje ogólnie każdej metody uwierzytelniania Sophos. Zachowana ścieżka AD dla SFOS 22 pasuje, gdy zarządzany endpoint z Windows 10 należy zwykle do dokładnie jednego użytkownika AD, a Sophos Endpoint wysyła już Security Heartbeat. Dla użytkowników Entra w SFOS 23 obowiązują wymagania i weryfikacja opisane powyżej w osobnej ścieżce.

Inne modele działania wymagają innych metod:

• STAS na Sophos Firewall przypisuje logowania Windows z kontrolerów domeny, STA Agent i Collector do adresu IP klienta.
• SATC dla Remote Desktop Services rozróżnia wiele sesji za jednym adresem IP RDS lub Citrix.
• Per-Connection AD SSO rozróżnia połączenia HTTP i HTTPS wielu użytkowników przez Direct Web Proxy.
• Captive Portal lub Client Authentication Agent pasują, gdy potrzebne jest interaktywne logowanie.

Nie należy wymuszać scenariusza serwera lub serwera terminalowego za pomocą Synchronized User ID. Sophos wyraźnie wskazuje, że Server Protection nie jest obsługiwany. Jeśli wielu użytkowników współdzieli ten sam adres IP albo połączenia inne niż webowe trzeba przypisywać według sesji, lepiej pasuje SATC.

Jeśli Synchronized User ID i STAS są skonfigurowane jednocześnie, według Sophos serwer uwierzytelniania używa mechanizmu, którego żądanie logowania nadejdzie jako pierwsze. Nie należy traktować tej współpracy jako stałego priorytetu. Trzeba jednoznacznie ograniczyć pilota i przy każdej weryfikacji sprawdzać Client Type.

Jak działa przypisanie AD

Proces składa się z czterech oddzielnych warstw:

1. Użytkownik loguje się na kliencie domenowym Windows.
2. Sophos Endpoint przesyła użytkownika domenowego do firewalla przez Security Heartbeat.
3. Firewall odczytuje domenę z UPN, a nazwę użytkownika z sAMAccountName.
4. Firewall weryfikuje użytkownika przez odpowiedni serwer Active Directory i aktywuje go dla reguł opartych na użytkownikach.

Funkcja nie uwierzytelnia lokalnych użytkowników Windows i nie zastępuje połączenia z AD. Jeśli domena UPN, serwer katalogowy lub profil użytkownika nie są zgodne, zielony endpoint może nadal nie mieć użytecznej tożsamości użytkownika.

Sophos Firewall nie udostępnia ani nie wykorzystuje w tym procesie informacji o haśle. Heartbeat przenosi dane domeny i użytkownika potrzebne do przypisania, natomiast weryfikacja odbywa się na skonfigurowanym serwerze AD.

Przykład AD i wartości do zastąpienia

Proces wykorzystuje następujące wartości dokumentacyjne:

• Firewall: fw01.example.com
• Domena AD i sufiks UPN: example.com
• Klient Windows: WS-101
• Adres IP klienta: 10.20.30.101
• Nazwa użytkownika: anna.muster
• UPN: anna.muster@example.com
• sAMAccountName: anna.muster
• Grupa AD: SFOS-Internet-Users
• Reguła pilotażowa: LAN_User_Internet

example.com, WS-101, 10.20.30.101, użytkownik i grupa są przykładami i należy je zastąpić rzeczywistymi wartościami. Decydująca nie jest nazwa obiektu, lecz jednoznaczne przypisanie tego samego użytkownika przez Sophos Fusion, Windows, Active Directory i firewall.

Przygotowanie wymagań

Sprawdzenie Sophos Fusion i Security Heartbeat

Firewall musi być połączony z Sophos Fusion i mieć ważną subskrypcję Network Protection. Pilot wymaga Sophos Central Endpoint Protection w wersji próbnej lub z pełną licencją. Te wymagania licencyjne pochodzą z pomocy SFOS 22 dotyczącej Security Heartbeat; rejestrację i bazowy stan heartbeat opisuje Połączenie Sophos Firewall z Sophos Fusion.

W System > Sophos Fusion rejestracja i Security Heartbeat muszą być aktywne. Pilot powinien być widoczny z wiarygodnym stanem w Control Center i Sophos Fusion. Najpierw należy ustalić ten stan bazowy, a potem sprawdzić przypisanie tożsamości.

Według pomocy SFOS 22 dotyczącej Security Heartbeat endpoint i firewall wymieniają dane heartbeat przez szyfrowane połączenie TLS z 52.5.76.173 na porcie TCP 8347. Zielony stan oznacza, że ochrona Sophos działa prawidłowo i nie wykryto aktywnego ani nieaktywnego złośliwego oprogramowania ani PUA. Nie potwierdza jeszcze weryfikacji użytkownika przez AD. Przy problemach z połączeniem należy sprawdzać transport, tenant Fusion i certyfikat endpointu oddzielnie od przypisania użytkownika.

Synchronized User ID jest domyślnie aktywny. Nie ma więc zwykłego przełącznika WebAdmin, który trzeba najpierw włączyć dla pilota. Opisane dalej polecenia shell służą wyłącznie do kontrolowanego wyłączenia lub ponownego włączenia.

Porównanie Active Directory i atrybutów użytkownika (ścieżka AD)

W Authentication > Servers musi istnieć i być osiągalny odpowiedni serwer Active Directory. Połączenie Active Directory z Sophos Firewall wyjaśnia LDAPS, bazę wyszukiwania, import grup i kolejność serwerów.

Następnie w Authentication > Services > Firewall authentication methods przenieść serwer AD do Selected authentication server. Pomoc SFOS 22 dotycząca Authentication Services potwierdza, że musi być wybrany co najmniej jeden serwer; jeśli jest ich kilka, firewall przetwarza je w wyświetlonej kolejności. Samo dodanie serwera w Servers nie wystarcza do uwierzytelniania firewalla.

Dla pilota co najmniej te wartości muszą być zgodne:

• Domena w UPN odpowiada domenie serwera AD używanego przez firewall.
• sAMAccountName jest unikalny w Active Directory i może zostać odnaleziony przez firewall.
• Profil użytkownika i adres e-mail są zgodne między AD, Sophos Fusion i lokalnym rekordem użytkownika na firewallu.
• Wymagana grupa AD jest zaimportowana i przypisana do właściwego profilu użytkownika firewalla.

Inny sufiks UPN, powielone wartości sAMAccountName w nieodpowiednich zakresach wyszukiwania lub niedopasowany serwer AD są sygnałami do zatrzymania. Nie należy kompensować ich szerszą regułą użytkownika.

Przygotowanie reguły pilotażowej

W Rules and policies > Firewall rules kliknąć Add firewall rule > New firewall rule i utworzyć ściśle ograniczoną regułę dla grupy pilotażowej albo w kontrolowany sposób użyć istniejącej reguły użytkownika. W sekcji tożsamości użytkownika włączyć Match known users przed wybraniem Users or groups:

• Source zones: rzeczywista strefa klienta
• Source networks and devices: sieć pilotażowa lub węższy zakres źródłowy
• Users or groups: SFOS-Internet-Users
• Destination zones: tylko wymagany kierunek docelowy
• Services: tylko usługi wymagane do testu
• Log firewall traffic: aktywne

Kolejność reguł, logowanie i test negatywny są ważniejsze niż szeroka reguła zezwalająca. Prawidłowe tworzenie reguł Sophos Firewall opisuje konfigurację.

Logowanie i weryfikacja pilota AD

1. Całkowicie wylogować istniejącego użytkownika z klienta pilotażowego.
2. Zalogować się ponownie do Windows jako anna.muster@example.com.
3. Sprawdzić zielony heartbeat w Sophos Fusion i na firewallu.
4. Wyszukać anna.muster i 10.20.30.101 w Current activities > Live users.
5. Potwierdzić wyświetlanie użytkownika, adresu IP i Client Type: Heartbeat.
6. Wywołać dozwolony test ruchu przez LAN_User_Internet.
7. Otworzyć Log viewer w prawym górnym rogu, wybrać moduł firewalla i porównać nazwę użytkownika, źródło, cel, usługę, Firewall Rule ID, działanie i czas.
8. Wykonać test negatywny z użytkownikiem spoza grupy pilotażowej.

Wpis w Live users potwierdza jedynie przypisanie tożsamości. Dopiero zalogowany przepływ testowy dowodzi, że zastosowano również właściwą regułę użytkownika. Jeśli log ruchu pokazuje tylko adres IP albo przepływ trafia do innej Rule ID, nie należy poszerzać reguły. Trzeba sprawdzić przypisanie i kolejność.

Świadomy test utraty heartbeat

Jeśli Security Heartbeat brakuje lub zostanie utracony podczas uśpienia i wybudzenia, firewall wylogowuje użytkownika wykrytego przez Synchronized User ID. Inne skonfigurowane metody uwierzytelniania mogą nadal działać, ale ruch oparty na użytkowniku może zostać przerwany do następnego logowania.

Dla kontrolowanego testu:

1. Najpierw udokumentować aktywnego użytkownika, IP, stan heartbeat i regułę.
2. Uśpić urządzenie pilotażowe i ponownie je wybudzić.
3. Ponownie sprawdzić stan heartbeat i Live users.
4. Wywołać nowy test ruchu i potwierdzić rzeczywiście użytego użytkownika oraz Rule ID.
5. W razie różnic sprawdzić endpoint, ścieżkę i logi zamiast zapobiegawczo wyłączać Synchronized User ID globalnie.

Missing Heartbeat nie oznacza automatycznie złośliwego oprogramowania. Systematyczna analiza alertów Missing Heartbeat opisuje pełną ścieżkę diagnostyczną.

Interpretacja informacji o wydaniach SFOS 22 i znanych ograniczeń

Podczas weryfikacji liczy się zainstalowany Maintenance Release, a nie tylko „SFOS 22”. Ten aktualny artykuł o Synchronized User ID bezpośrednio dokumentuje dwa konkretne twierdzenia NC. Kontrola przed aktualizacją do SFOS 22 odpowiada tutaj wyłącznie za sprawdzenie wersji i kompilacji, zatwierdzonej ścieżki aktualizacji oraz przygotowanie zmiany. Poprawki produktu to: MR1 Build 490 usuwa opóźnienie dostępu do internetu po ręcznie wywołanym przełączeniu HA przy uwierzytelnianiu heartbeat (NC-165361); MR2 Build 546 usuwa błędne zgłoszenia Missing Heartbeat, gdy dwa endpointy używają tej samej stacji dokującej lub interfejsu USB (NC-176012). Jeśli któryś z tych objawów wystąpi na starszej kompilacji 22.0, najpierw zapisać dokładny numer kompilacji i ocenić zatwierdzoną ścieżkę aktualizacji.

Runbook rozwiązywania problemów Missing Heartbeat obejmuje też NC-147863: przy dzielonym tunelowaniu SSL VPN do zewnętrznego firewalla nowy adapter VPN może przerwać połączenie heartbeat. Użytkownik traci wtedy uwierzytelnianie heartbeat i może wpaść w pętlę łączenia i rozłączania. Jeśli pilot obejmuje ten scenariusz, należy go przetestować oddzielnie. Jako obejście Sophos zaleca wyłączenie Match known users w regule VPN lokalnego firewalla albo użycie Captive Portal do uwierzytelniania. Zmianę należy najpierw ograniczyć do objętej problemem reguły VPN oraz udokumentować jej skutek i drogę powrotu.

Systematyczne zawężanie błędów

Endpoint nie pojawia się z zielonym heartbeat

Najpierw sprawdzić rejestrację Fusion, licencję endpointu, licencję Network Protection, powiązanie firewalla, DNS, czas i ścieżkę sieciową. Bez działającego Security Heartbeat Synchronized User ID nie może przesłać tożsamości.

Użytkownik nie pojawia się w Live users

Dla ścieżki AD sprawdzić łącznie logowanie Windows, UPN, sAMAccountName, serwer AD, zakres wyszukiwania i profil użytkownika. Zielony Heartbeat potwierdza połączenie endpointu, a nie automatycznie pomyślną weryfikację AD. W SFOS 23 dla użytkowników Entra zamiast tego stosować sprawdzanie UPN, konta i osiągalności opisane w ścieżce Entra.

Nieprawidłowy użytkownik lub grupa

Dla AD porównać domenę UPN, zakres wyszukiwania AD, zaimportowaną grupę, Main Group i lokalne obiekty użytkowników. Dla Entra w SFOS 23 obowiązują dodatkowo członkostwo Entra i przypisanie UPN opisane w osobnej ścieżce. Nie usuwać obiektów użytkowników przed sprawdzeniem zależności od VPN, portalu, reguł, limitów i raportowania.

Użytkownik jest widoczny, ale reguła nie działa

Sprawdzić strefę i sieć źródłową, użytkownika lub grupę, usługę, cel i kolejność reguł. W Log Viewer rzeczywisty przepływ musi pokazywać oczekiwaną Firewall Rule ID. Sama widoczna tożsamość nie potwierdza autoryzacji.

Serwer lub niepotwierdzona wersja Windows

Server Protection nie jest obsługiwany w obu ścieżkach. Pomoc SFOS 22 wyraźnie wymienia Windows 10 dla AD; strona dotycząca SFOS 23 nie określa konkretnej wersji systemu operacyjnego. Nie należy wnioskować o dopuszczeniu do produkcji innych systemów operacyjnych, modeli przyłączania lub nieznanych typów endpointów na podstawie dostępności dokumentacji ani zachowania pojedynczego pilota.

Odczyt odpowiednich logów

W Advanced Shell przydatne są następujące kontrole tylko do odczytu:

cd /log
tail -n 200 heartbeatd.log
tail -n 200 access_server.log
tail -n 200 hbtrust.log

heartbeatd.log pokazuje zdarzenia heartbeat, access_server.log pomaga przy uwierzytelnianiu i autoryzacji, a hbtrust.log przy relacji zaufania z Sophos Fusion. Pojedynczy log nie stanowi pełnego dowodu. Należy zachować razem przedział czasu, użytkownika, endpoint, IP, Rule ID i odpowiedni węzeł HA. Pliki logów i usługi Sophos Firewall opisuje więcej ścieżek.

Jeśli nadal nie wiadomo, czy zawodzi katalog, metoda, lokalny rekord użytkownika czy reguła, Systematyczne rozwiązywanie błędów uwierzytelniania przedstawia wspólną dla metod sekwencję diagnostyczną.

Kontrolowane wyłączenie funkcji

⚠️ Poniższe polecenia zmieniają stan uwierzytelniania i restartują access_server. Najpierw należy udokumentować aktywnych użytkowników, objęte reguły, alternatywną metodę dostępu i drogę powrotu. W HA oba węzły muszą być obsłużone świadomie.

Oficjalne instrukcje SFOS 22 i SFOS 23 podają następujące polecenia dla trwałego wyłączenia:

touch /content/no_userid
service access_server:restart -ds nosync

Ten wariant wyłącza funkcję tylko do następnego restartu firewalla:

touch /tmp/no_userid
service access_server:restart -ds nosync

Aby ponownie włączyć funkcję, usunąć trwały plik i zrestartować usługę:

rm /content/no_userid
service access_server:restart -ds nosync

Po każdej zmianie sprawdzić nowe logowanie Windows, Live users, rzeczywisty ruch i logi. Stan wyłączenia nie jest zapisywany w kopiach konfiguracji. Po przywróceniu ponownie sprawdzić zamierzony stan i w razie potrzeby ustawić go na obu węzłach HA.

HA, kopie zapasowe i eksploatacja

W klastrze HA Synchronized User ID włącza się lub wyłącza na obu urządzeniach. Każdy węzeł przechowuje tylko logi ruchu i zdarzeń, które sam przetwarza. W przypadku incydentu trzeba więc sprawdzić węzeł aktywny lub przetwarzający ruch w danym czasie.

Kontrolowany test HA wymaga nowego logowania Windows i nowego przepływu ruchu. Nie należy zakładać, że stan użytkownika lub aktywne sesje będą kontynuowane bez przerwy. Po failover trzeba ponownie zweryfikować co najmniej heartbeat, Live users, regułę użytkownika i logi.

Stan /content/no_userid nie jest częścią kopii zapasowej. Ten wyjątek musi być wyraźnie opisany w procedurach operacyjnych, testach przywracania i procesie RMA.

Wycofanie

1. Udokumentować bieżący stan heartbeat, użytkownika, reguły i HA.
2. Wyłączyć regułę pilotażową lub przywrócić jej udokumentowany wcześniejszy stan.
3. Tylko jeśli globalny stan funkcji został zmieniony w teście, w kontrolowany sposób przywrócić udokumentowany stan początkowy. W celu zamierzonego ponownego włączenia po trwałym wyłączeniu usunąć /content/no_userid i zrestartować access_server; nie włączać bezwarunkowo funkcji, która była wcześniej wyłączona. Według Sophos wariant tymczasowy kończy się przy następnym restarcie firewalla. Nie wykonywać restartu wyłącznie w celu porządkowania po teście poza zatwierdzonym oknem serwisowym.
4. Ustawić ten sam zamierzony stan na obu węzłach HA.
5. Zalogować się ponownie do Windows na urządzeniu pilotażowym i sprawdzić heartbeat oraz Live users.
6. Ponownie przetestować regułę użytkownika i alternatywną ścieżkę uwierzytelniania z rzeczywistym ruchem.
7. Dopiero potem usunąć tymczasowe obiekty testowe lub przypisania pilotażowe.

Lista kontrolna dla ścieżki AD w SFOS 22

• Pilot jest obsługiwanym klientem domenowym Windows 10 z Sophos Endpoint.
• Firewall, endpoint i Security Heartbeat są widoczne w Sophos Fusion.
• Licencje Network Protection i endpointu są ważne.
• Serwer AD, domena UPN, sAMAccountName, adres e-mail i profil użytkownika są zgodne.
• Grupa pilotażowa jest zaimportowana, a reguła użytkownika jest ściśle ograniczona i logowana.
• Live users pokazuje oczekiwanego użytkownika i prawidłowy adres IP klienta.
• Rzeczywisty ruch trafia do oczekiwanej Firewall Rule ID.
• Utrata heartbeat oraz uśpienie i wybudzenie zostały przetestowane w sposób kontrolowany.
• Węzły HA, logi, ograniczenie przywracania i droga powrotu są udokumentowane.
• Synchronized User ID nie został nadmiernie rozszerzony jako zamiennik SATC, STAS lub innych usług katalogowych.

Częste pytania