Konfiguracja Microsoft Entra ID SSO dla WebAdmin Sophos Firewall

Konfiguracja Microsoft Entra ID SSO dla WebAdmin wymaga czterech pasujących do siebie elementów: grupy Entra lub roli aplikacji, lokalnego profilu Device Access, dokładnego adresu Web admin console URL jako Redirect URI oraz serwera Entra w sekcji Administrator authentication methods. Dopiero ten łańcuch sprawia, że użytkownik poprawnie uwierzytelniony w Entra staje się administratorem firewalla z przewidzianymi uprawnieniami.

Jeśli środowisko używa TACACS+ zamiast OAuth do centralnego zarządzania urządzeniami, obowiązuje oddzielna procedura TACACS+ dla administratorów Sophos Firewall. W przeciwieństwie do Entra Role Mapping TACACS+ nie przypisuje w tym przepływie automatycznie lokalnego profilu.

⚠️ Przed aktywacją: Pozostaw otwartą istniejącą lokalną sesję administratora, przetestuj lokalne konto admin z sieci zarządzającej i upewnij się, że znasz sposób dostępu przez konsolę lub Device Console. SSO i Entra MFA nie uzasadniają szerokiego udostępnienia WebAdmin ze strefy WAN. Dopóki logowanie pilotażowe, uprawnienia i lokalna droga powrotna nie działają, Entra nie powinna być ustawiana jako priorytetowa metoda produkcyjna.

WebAdmin SSO w ośmiu krokach

SFOS 22

Sprawdź FQDN WebAdmin, DNS, certyfikat, czas systemowy i ograniczoną dostępność z sieci zarządzającej.
Przygotuj wymagane profile administratorów w Profiles > Device access.
W Microsoft Entra ID utwórz oddzielną aplikację single-tenant z administratorem pilotażowym, rolą aplikacji lub Security Group oraz monitorowanym Client Secret.
W Authentication > Servers utwórz serwer typu Microsoft Entra ID SSO albo rozszerz istniejący serwer.
Ustaw User type na Administrator i zmapuj role lub grupy Entra na lokalne profile we właściwej kolejności.
Wprowadź wyświetlony przez firewall Web admin console URL jako dokładny Redirect URI aplikacji Entra i pomyślnie wykonaj Test connection.
Aktywuj serwer Entra w Authentication > Services > Administrator authentication methods, przesuń go wyżej i wybierz Apply.
W prywatnym oknie przeglądarki osobno przetestuj administratora pilotażowego, użytkownika bez mapowania, faktyczne uprawnienia oraz lokalny fallback.

Dotychczasowe ścieżki w interfejsie, pola User type i Role mapping oraz logi właściwe dla poszczególnych usług w tym artykule odnoszą się do SFOS 22. Dla SFOS 23.0 obowiązuje poniższa procedura OIDC. Bezpieczne ścieżki zarządzania, lokalne profile, przypisania aplikacji oraz testy MFA, pozytywne, negatywne i fallbacku nadal są wymagane. Pomoc SFOS 23 nie stanowi potwierdzenia terminu ogólnej dostępności (GA).

SFOS 23.0: serwer OIDC i mapowanie administratorów

W Authentication > Servers > Add wybierz Server type: OpenID Connect i IdP vendor: Microsoft Entra ID. Przed zmianami udokumentuj istniejący obiekt Entra wraz z przypisaniami usług i Redirect URI; sam nowy formularz nie jest powodem do tworzenia drugiej aplikacji Entra.
Ustaw Server name, w Client ID wpisz Application (client) ID, a w Client secret wartość sekretu aplikacji. W OpenID Connect URLs > Issuer URL zgodnie z konfiguracją Entra wpisuje się Directory (tenant) ID, a nie samodzielnie skonstruowany adres URL. Pozostałe ustawienia URL nie dotyczą tego dostawcy.
W Redirect URIs wybierz Use firewall URL albo Enter manually. Przy konfiguracji pojedynczego firewalla przez Sophos Fusion ustaw nazwę hosta urządzenia ręcznie, zamiast przejmować adres Reverse SSO. Otwórz Show URLs i w aplikacji Entra dodaj dokładny Web admin console URL jako Redirect URI typu Web. DNS i certyfikat muszą pasować do tej nazwy.
W User attributes zachowaj wartości domyślne Display name: name, Username: upn i Email address: email, chyba że używany token ma potwierdzoną, inną i obsługiwaną strukturę. Fallback group dla usług użytkowników nadal nie zastępuje profilu administratora.
Włącz IdP authentication for firewall administrators. Dla samych usług użytkowników przełącznik ten jest domyślnie wyłączony i w SFOS 23 zastępuje dotychczasowy wybór User type: Administrator.
W IdP attribute wybierz Roles albo Groups, w IdP value wpisz dokładną skonfigurowaną wartość roli lub grupy, a w Device access profile ustaw lokalny profil. W dotychczasowym przykładzie sfosAdminReadOnly jest mapowane na Entra-WebAdmin-ReadOnly. Dodaj kolejne mapowania i sprawdź ich kolejność: pierwszy pasujący wpis określa profil.
Pomyślnie wykonaj Test connection, zapisz konfigurację i wybierz serwer w Authentication > Services > Administrator authentication methods. W SFOS 23 dla jednej metody można wybrać tylko jeden serwer IdP OpenID Connect, a nie po jednym dla każdego dostawcy. Udokumentuj kolejność, zachowaj lokalny fallback i wybierz Apply.
Przy nowym logowaniu do WebAdmin sprawdź rolę pilotażową, rzeczywiste uprawnienia do menu, odmowę dostępu osobom nieuprawnionym oraz lokalny dostęp awaryjny. Logowanie do VPN lub Captive Portal uwierzytelnia użytkownika, ale nie tworzy ani nie aktualizuje obiektu administratora. Zmiany ról, grup lub przypisań profili Entra są synchronizowane przez logowanie do WebAdmin.

Przy odbieraniu uprawnień nadal istotna jest opisana poniżej szczególna zasada: istniejący lokalny obiekt administratora nie staje się zwykłym użytkownikiem wyłącznie w wyniku obniżenia uprawnień w Entra. Nadal wymagane są kontrolowane usunięcie obiektu na firewallu i negatywny test WebAdmin. Po aktualizacji należy ponownie zweryfikować pola OIDC, callback, przypisanie usługi i te uprawnienia przed zamknięciem otwartej lokalnej sesji.

Tylko automatyzacja API: kontrola odpowiedzi przy przejściu z SFOS 22 na 23

Jeśli dodajesz lub edytujesz serwer Microsoft Entra ID SSO przez API, sprawdź interpretację wyników niezależnie od powyższej procedury UI/OIDC. Dokumentacja referencyjna API podaje następujące wiersze statusu dla tych operacji:

SFOS 22, Add i Edit: 200/500/502/503.
SFOS 23, Add: 200/400/401/403/409/500.
SFOS 23, Edit: 200/400/401/403/404/500.

Zatem 409 występuje tylko dla Add, a 404 tylko dla Edit; dotychczasowe wiersze 502/503 nie występują w dokumentacji SFOS 23. To zmiana dokumentacji, a nie zachowanie sprawdzone tutaj w działającym systemie: wiersze te nie potwierdzają faktycznie zwracanych statusów transportu HTTP, kodów wyniku XML ani dokładnych komunikatów podczas wykonania. Nie wynika z nich również reguła ponawiania prób. Przed uznaniem autoryzowanej operacji zapisu za poprawnie wykonaną lub zmianą automatycznego klasyfikatora wyników sprawdź API help zainstalowanej kompilacji; następnie zweryfikuj odpowiedź operacji i zamierzony stan obiektu docelowego. W kwestii bezpiecznej obsługi żądań, sekretów i kontroli odpowiedzi stosuj istniejący przewodnik bezpiecznego dostępu do API.

Niezmieniony przykład XML w dokumentacji nie jest potwierdzonym schematem OIDC dla SFOS 23. Nie zmieniaj nazwy AzureADSSO na OIDC tylko ze względu na nowy interfejs i nie przenoś do produkcji bez weryfikacji szerokich ustawień przykładowych Administrator i Open Group. Wymagania tego artykułu dotyczące zarządzania, minimalnych uprawnień, testów negatywnych i odzyskiwania dostępu nadal obowiązują.

Za co odpowiadają poszczególne warstwy

WebAdmin SSO łączy kilka mechanizmów kontroli, które łatwo ze sobą pomylić:

Device Access i Local Service ACL określają, z których sieci dostępna jest konsola WebAdmin.
Microsoft Entra ID uwierzytelnia użytkownika i przekazuje w tokenie informacje o rolach lub grupach.
Role mapping na firewallu przypisuje pierwszą pasującą wartość tokenu do lokalnego profilu administratora.
Profil Device Access określa, których menu administrator nie może używać, może używać tylko do odczytu albo również do zapisu.
Administrator authentication methods aktywuje serwer Entra dla logowania do WebAdmin.

Zwykła reguła firewalla nie udostępnia WebAdmin. Z kolei dostępna strona logowania nie oznacza jeszcze uprawnień administratora. Bezpieczne udostępnienie sieciowe opisuje artykuł Device Access i Local Service ACL na Sophos Firewall.

Gdy brakuje pasującego Role mapping, logowanie w Entra ID może zakończyć się powodzeniem. SFOS utworzy jednak konto tylko jako zwykłego użytkownika i odmówi dostępu do WebAdmin. Nie jest to błąd przeglądarki, lecz brak przypisania uprawnień administracyjnych.

Grupy Entra czy role aplikacji

SFOS obsługuje oba warianty:

Security Groups są proste, gdy organizacja już zarządza uprawnieniami za pomocą jednoznacznie nazwanych grup. Nazwa grupy w mapowaniu musi być identyczna.
App roles dotyczą konkretnie aplikacji firewalla. W mapowaniu używa się dokładnej wartości Value roli, a nie tylko jej nazwy wyświetlanej.

W nowych integracjach administracyjnych role specyficzne dla aplikacji są łatwe do prześledzenia. Security Groups pozostają dobrą alternatywą, jeśli członkostwa są już starannie zatwierdzane, kontrolowane i dokumentowane. Nie należy łączyć obu modeli bez jasnych zasad.

SFOS ocenia mapowania od góry do dołu i stosuje pierwsze trafienie. Przypisania Full Access i Read-only muszą więc wzajemnie się wykluczać. Jeśli wykryto nakładanie, najpierw koryguje się przypisania w Entra, a następnie ponownie testuje obie role. Kolejność mapowania nie powinna służyć jako model uprawnień.

Planowanie przykładu i wymagań

Poniższy przykład wykorzystuje wartości dokumentacyjne. Należy zastąpić je danymi własnego środowiska:

FQDN WebAdmin: fw01.example.com
Aplikacja Entra: Sophos Firewall - FW01 - WebAdmin
Rola aplikacji Full Access: sfosAdminFull
Rola aplikacji Read-only: sfosAdminReadOnly
Lokalny profil Full Access: Administrator
Lokalny profil Read-only: Entra-WebAdmin-ReadOnly

example.com jest domeną zarezerwowaną do przykładów. Produkcyjny FQDN musi z sieci zarządzającej wskazywać właściwy firewall i pasować do używanego certyfikatu WebAdmin. Jeśli cykle uprawnień i zmian mają być rozdzielone, najbardziej przejrzysta jest oddzielna aplikacja Entra z własnym obiektem serwera firewalla dla każdej integracji WebAdmin. Wspólna aplikacja jest możliwa, ale wiąże administratorów, użytkowników VPN i portali z tymi samymi przypisaniami aplikacji.

Przed zmianą należy również potwierdzić:

Drugi lokalny administrator lub lokalne konto admin działa niezależnie od Entra ID.
Hasło, sposób odzyskiwania i dostęp konsolowy do konta awaryjnego są udokumentowane. Jeśli ta droga nie została jeszcze sprawdzona, artykuł Odzyskiwanie hasła administratora Sophos Firewall pomoże ją bezpiecznie przygotować.
Istniejąca sesja administratora pozostaje otwarta podczas zmiany.
Firewall ma prawidłowy czas i może po DNS i HTTPS dotrzeć do wymaganych endpointów Microsoft.
Firewall i przeglądarka administratora mogą dotrzeć do miejsc docelowych Microsoft wymaganych przez przepływ SSO. Pełna lista FQDN i wyjątki Direct Web Proxy znajdują się w liście dozwolonych adresów logowania Microsoft Entra.
FQDN WebAdmin używa zaufanego certyfikatu z pełnym łańcuchem.
WebAdmin jest dostępny tylko z sieci zarządzających, przez VPN lub z konkretnie dozwolonych źródeł.
Właściciel i data wygaśnięcia Client Secret są udokumentowane.
Użytkownicy z tej samej domeny nie są równocześnie synchronizowani przez Active Directory i Microsoft Entra ID. Oba serwery mogą istnieć, ale przed zmianą musi być jasne, który katalog zarządza tymi użytkownikami na firewallu.
SFOS 22: Tenant nie jest środowiskiem Microsoft 365 Government Community Cloud High (GCC High), ponieważ ta integracja SSO nie jest dla niego obsługiwana. Pomoc SFOS 23 nie wymienia już tego ograniczenia, ale nie stanowi to potwierdzenia obsługi. Obsługę GCC High należy wyjaśnić oddzielnie przed wdrożeniem SFOS 23.

Przy konfiguracji czasu i certyfikatów pomogą artykuły Konfiguracja czasu systemowego i NTP oraz Importowanie i przypisywanie certyfikatów.

Przygotowanie profili Device Access

Profile tworzy się przed przełączeniem SSO, aby każda wartość Entra od razu wskazywała zdefiniowane uprawnienia. Ogólną strukturę i bezpieczną walidację lokalnych profili administratorów opisuje artykuł Bezpieczna konfiguracja administratorów i profili Sophos Firewall; tutaj przedstawiono wyłącznie mapowanie właściwe dla Entra.

Do pełnego dostępu można użyć wbudowanego profilu Administrator. Powinien on należeć wyłącznie do najmniejszej koniecznej grupy osób. Dla obsługi, audytu lub helpdesku zwykle lepszy jest własny profil:

Otwórz Profiles > Device access.
Wybierz Add.
Jako nazwę wpisz na przykład Entra-WebAdmin-ReadOnly.
Dla każdego wymaganego menu ustaw Read-only.
Niepotrzebne obszary pozostaw na None.
Uprawnienie Read-write przydzielaj tylko tam, gdzie zadanie rzeczywiście go wymaga.
Zapisz profil i ponownie porównaj go z faktyczną rolą zespołu.

Sama nazwa Read-only nie zabezpiecza profilu przed zapisem. Decydują ustawienia None, Read-only i Read-write w macierzy uprawnień. Podmenu można skonfigurować bardziej szczegółowo po ich rozwinięciu.

Przygotowanie aplikacji Entra i ról administratorów

Jeśli istnieje już dobrze udokumentowana aplikacja Entra dla VPN lub Captive Portal, tego samego serwera Entra ID można użyć również dla WebAdmin. Redirect URI, role administratorów i testy nadal pozostają właściwe dla danej usługi. Wspólną bazę aplikacji i serwera opisuje Entra ID SSO dla Sophos Connect i VPN Portal, a dla lokalnych użytkowników przeglądarki obowiązuje oddzielna procedura Entra ID SSO dla Captive Portal.

W przypadku wspólnej aplikacji przed aktywacją Assignment required należy przypisać wszystkie uprawnione grupy administratorów, VPN i portali, a następnie przetestować wszystkie używane usługi. Dla niezależnych uprawnień administracyjnych, wymiany sekretu i wdrożeń bardziej przejrzysta jest dedykowana aplikacja WebAdmin z własnym obiektem serwera Entra.

Dla nowej integracji obecna konfiguracja Sophos obejmuje:

W Microsoft Entra ID > App registrations utwórz oddzielną aplikację single-tenant dla firewalla.
Dodaj delegowane uprawnienia Microsoft Graph User.Read.All i Group.Read.All.
Do importowania grup dodaj również Group.Read.All jako Application Permission.
Udziel Admin Consent dla tych uprawnień.
W Certificates & secrets utwórz Client Secret, natychmiast bezpiecznie zapisz jego Value i monitoruj datę wygaśnięcia.
W App roles utwórz na przykład sfosAdminReadOnly, a tylko w razie potrzeby sfosAdminFull.
W powiązanej Enterprise Application, w Users and groups, przypisz administratora pilotażowego lub kontrolowaną grupę pilotażową do odpowiedniej roli.
Dla dedykowanej aplikacji WebAdmin włącz Assignment required jako dodatkową kontrolę dostępu i przypisz wyłącznie przewidzianych administratorów pilotażowych lub grupy administratorów. Jest to zalecenie bezpieczeństwa Avanet, a nie wymóg techniczny SFOS.

Zamiast ról aplikacji można użyć dedykowanych Security Groups, takich jak SFOS-FW01-WebAdmin-Full i SFOS-FW01-WebAdmin-ReadOnly. Ogólne grupy IT lub Microsoft 365 są zbyt szerokie do nadawania uprawnień administratora firewalla i utrudniają późniejsze przeglądy.

MFA dla tego logowania jest wymuszane przez Identity Provider. Sophos Firewall MFA nie można dodatkowo nałożyć na ten sam przepływ Entra SSO. Conditional Access należy więc przetestować konkretnie dla aplikacji firewalla, a nie tylko ogólnie dla Microsoft 365. Różnice względem Sophos OTP opisuje artykuł MFA dla Sophos Firewall.

SFOS 22: Konfiguracja serwera Entra ID na firewallu

W Authentication > Servers otwórz istniejący serwer Microsoft Entra ID albo utwórz nowy przez Add > Microsoft Entra ID SSO.

Konfiguracja serwera i Redirect URI

Wprowadź jednoznaczny Server name.
Wklej Application (client) ID z App Registration.
Wklej Directory (tenant) ID.
Wprowadź wcześniej zapisany Client secret Value.
Świadomie wybierz Fallback user group. Steruje ona usługami użytkowników i nie zastępuje profilu administratora.
W sekcji Redirect URI sprawdź lub ustaw ręcznie FQDN WebAdmin.
Skopiuj w całości wyświetlony Web admin console URL.

Redirect URI nie należy samodzielnie składać z nazwy hosta, portu i przypuszczalnej ścieżki callback. W aplikacji Entra otwórz App registrations > [nazwa aplikacji] > Authentication > Add a platform > Web i dodaj dokładnie adres URL wyświetlony przez SFOS.

Jeśli pojedynczy firewall jest konfigurowany przez Sophos Fusion (dawniej Sophos Central), jego nazwa hosta musi zostać ustawiona ręcznie. Automatycznie wyświetlany adres Central Reverse SSO nie jest adresem WebAdmin Redirect URI appliance.

Następnie uruchom Test connection. Test sprawdza połączenie sieciowe, uprawnienia aplikacji oraz walidację certyfikatu TLS. Dopóki kończy się niepowodzeniem, nie należy przełączać uwierzytelniania administratorów.

Mapowanie ról lub grup na profile

Ustaw User type na Administrator. Ustawienie User włącza tylko usługi użytkowników i nie wystarcza do WebAdmin.
W Role mapping wybierz Identifier type:
- Roles dla dokładnej wartości App Role, na przykład sfosAdminReadOnly;
- Groups dla dokładnej nazwy grupy Entra.
W Value wpisz niezmienioną wartość roli lub nazwę grupy.
W Profile wybierz lokalny profil, na przykład Entra-WebAdmin-ReadOnly.
Dodaj kolejne mapowania i świadomie sprawdź ich kolejność.
Zapisz.

Mapowania są oceniane od góry do dołu i obowiązuje pierwsze trafienie. Członkostwa sfosAdminFull i sfosAdminReadOnly muszą się więc wzajemnie wykluczać. W przypadku podwójnego członkostwa należy najpierw poprawić przypisanie w Entra i ponownie przetestować administratora pilotażowego, zamiast używać kolejności jako reguły uprawnień. Kolejność listy nadal trzeba dokumentować, ponieważ przy każdym nieoczekiwanym wielokrotnym dopasowaniu określa ona zastosowany profil.

Aktywacja Entra SSO dla administratorów

Serwer Entra ID stanie się metodą logowania do WebAdmin dopiero po przypisaniu go do usługi administratorów:

Otwórz Authentication > Services.
Przejdź do Administrator authentication methods.
Wybierz serwer Microsoft Entra ID.
Przesuń serwer wyżej na liście.
Zachowaj istniejące uwierzytelnianie lokalne jako świadomy fallback dla lokalnych administratorów.
Wybierz Apply.

Dla jednej metody uwierzytelniania można wybrać tylko jeden serwer Microsoft Entra ID. Ustawienia w Administrator authentication methods nie dotyczą domyślnego superadministratora admin. Konto pozostaje więc lokalnym dostępem awaryjnym i nie jest zastępowane przez mapowanie ról Entra.

Wycofanie zmian bez ryzyka blokady

Jeśli logowanie pilotażowe, test profilu lub lokalny fallback nie powiedzie się, zatrzymaj wdrożenie:

Użyj już otwartej lokalnej sesji administratora; nie wylogowuj się ani nie przechodź do wadliwej sesji SSO.
W Authentication > Services > Administrator authentication methods ponownie usuń serwer Entra.
Wybierz Apply, a następnie przetestuj lokalne konto admin z sieci zarządzającej w nowym prywatnym oknie przeglądarki.
Zamknij starą sesję dopiero wtedy, gdy logowanie i oczekiwane uprawnienia działają. Zachowaj obiekt serwera Entra do diagnostyki zamiast usuwać go pod presją czasu.

Bezpieczne testowanie logowania i uprawnień

Sam poprawny dialog Entra nie oznacza jeszcze zaliczonego testu. Firewall musi zastosować właściwy profil, odrzucić nieuprawnionego użytkownika i nadal zapewniać lokalną drogę powrotu.

Test pozytywny z administratorami pilotażowymi

Pozostaw otwartą dotychczasową lokalną sesję administratora.
W prywatnym oknie przeglądarki otwórz udokumentowany FQDN WebAdmin.
Zaloguj się przez Entra ID jako administrator pilotażowy Read-only.
Przejdź zgodnie z planem przez Entra MFA i Conditional Access.
Sprawdź, czy widoczne są tylko udostępnione menu i rzeczywiście brakuje możliwości zapisu.
W Authentication > Users sprawdź, czy konto zostało utworzone jako administrator z oczekiwanym profilem.
Jeśli potrzebny jest Full Access, przetestuj oddzielnego administratora pilotażowego z rolą Full Access.

Test Full Access nie jest wykonywany na tym samym koncie, które ma jednocześnie otrzymać Read-only. Dwa jednoznaczne konta testowe pokazują, czy role, kolejność mapowania i lokalne profile rzeczywiście działają niezależnie.

Test negatywny i test fallbacku

Przy włączonej opcji Assignment required użytkownik nieprzypisany do Enterprise Application nie może pomyślnie zakończyć przepływu SSO.
Użytkownik przypisany, ale niezmapowany nie może uzyskać dostępu do WebAdmin.
Administrator Read-only nie może zapisać zmiany konfiguracji.
Lokalne konto admin musi nadal działać z przewidzianej sieci zarządzającej.
Dostęp z niedozwolonej sieci musi zostać zablokowany już przez Device Access lub Local Service ACL.

Jeśli test negatywny daje dostęp, błędne jest przypisanie, członkostwo w grupie lub kolejność mapowania. Faza pilotażowa pozostaje wtedy wstrzymana. Nie omija się problemu przez szerszą rolę ani udostępnienie z WAN.

Eksploatacja, odebranie uprawnień i HA

Entra SSO przenosi tożsamość i MFA do Identity Provider. Lokalne uprawnienia administratora nadal trzeba kontrolować na firewallu.

Świadome dokończenie zmiany roli

Gdy użytkownik Entra zostaje administratorem firewalla, SFOS przejmuje zmianę przy następnym logowaniu. Kierunek odwrotny nie działa automatycznie: po obniżeniu administratora w Entra do zwykłego użytkownika lokalny obiekt administratora na firewallu początkowo pozostaje.

Bezpieczna procedura obniżenia uprawnień:

Potwierdź drugiego lokalnego administratora i drogę powrotu.
Usuń rolę lub grupę administratora w Entra albo dostosuj przypisanie aplikacji.
W Authentication > Users w kontrolowany sposób usuń odpowiedni lokalny obiekt administratora.
Tylko jeśli użytkownik nadal ma korzystać z usług użytkowników, zezwól na nowe logowanie. SFOS utworzy konto ponownie jako użytkownika na podstawie aktualnego tokenu.
Negatywnie przetestuj nowe logowanie do WebAdmin i nie zakładaj, że istniejące sesje zostały automatycznie zakończone.

Jeśli konto nie ma już korzystać z żadnej usługi firewalla, nie należy go ponownie przypisywać. Samo usunięcie z grupy nie powinno być dokumentowane jako natychmiastowe odebranie już działających lokalnych praw administratora.

Monitorowanie sekretu, logów i zmian

SFOS 23.0: Przepływ OIDC sprawdza się w /log/oauth_sso_svc.log, a błąd TLS przy Test connection w /log/sfos-macro-cfg.log. W Log Viewer WebAdmin korzysta z modułu Admin. Poniższe odwołania do oauth_sso_webadmin.log i przykładowe polecenie tylko do odczytu odnoszą się do SFOS 22.

Monitoruj datę wygaśnięcia Client Secret wraz z właścicielem i odpowiednim wyprzedzeniem.
Sprawdzaj Entra Sign-in Logs według aplikacji, użytkownika, MFA i Conditional Access.
Na firewallu używaj oauth_sso_webadmin.log do analizy przepływu WebAdmin SSO.
Zmiany administratorów, profili i uwierzytelniania śledź w Audit Trail.
Regularnie przeglądaj łącznie grupy administratorów, App Roles i profile Device Access.

W Advanced Shell poniższe polecenie tylko do odczytu wyświetla ostatnie wpisy usługi WebAdmin SSO:

tail -n 200 /log/oauth_sso_webadmin.log

Ogólne przypisanie plików logów i bezpieczne sposoby ich odczytu opisuje artykuł Usługi i logi Sophos Firewall.

Uwzględnienie ograniczenia HA

W klastrze HA Entra ID SSO obecnie nie działa dla WebAdmin urządzenia Auxiliary. Bezpośredni dostęp do peera, odzyskiwanie i prace serwisowe wymagają więc lokalnej procedury. Mapowanie Entra na HAProfile nie znosi tego ograniczenia produktu.

Przed testem HA należy udokumentować obie ścieżki zarządzania, lokalne dane dostępowe i role. Po zmianie roli osobno ponownie sprawdza się dostęp do Primary, lokalne zarządzanie peerem oraz SSO.

Rozwiązywanie problemów

Logowanie Entra działa, ale WebAdmin odmawia dostępu

Najczęściej brakuje pasującego mapowania administratora. Sprawdź User type: Administrator, Identifier Type, dokładną wartość roli lub nazwę grupy oraz przypisany profil. Konto utworzone jako zwykły użytkownik w Authentication > Users oznacza, że żadne mapowanie administratora nie zadziałało.

Administrator otrzymuje niewłaściwy profil

Role mapping jest oceniany od góry do dołu. Sprawdź członkostwa w grupach i App Roles konta, usuń podwójne przypisania i ponownie przetestuj kolejność podczas nowego logowania. Nie poszerzaj po prostu uprawnień restrykcyjnego profilu.

Redirect kończy się stroną błędu

Porównaj znak po znaku Web admin console URL z firewalla z Redirect URI w App registrations > Authentication > Web. FQDN, port, ścieżka, DNS i certyfikat WebAdmin muszą być częścią tego samego testu. Przy konfiguracji przez Central nie wolno używać adresu Reverse SSO.

Test connection kończy się niepowodzeniem

SFOS 23.0: Po sprawdzeniu DNS, czasu, uprawnień i certyfikatów najpierw ponownie wykonaj Test connection. Tylko jeśli test nadal kończy się niepowodzeniem po poprawieniu łańcucha CA i zaakceptowano przerwę w działaniu używanych usług logowania OIDC, w oknie serwisowym zrestartuj wspólną usługę w Advanced Shell:

service oauth_sso_svc:restart -ds nosync

Następnie osobno wykonaj Test connection, nowe logowanie pilotażowe do WebAdmin i testy wszystkich pozostałych używanych usług OIDC. Wspólna usługa nie ogranicza się do WebAdmin. Poniższe polecenie service oauth_sso_webadmin:restart -ds nosync i powiązany plik logu właściwy dla tej usługi dotyczą SFOS 22.

Sprawdź dostęp do login.microsoftonline.com i graph.microsoft.com, DNS, czas systemowy, Tenant ID, Client ID, Client Secret, uprawnienia Microsoft Graph oraz Admin Consent. Nowy Redirect URI nie naprawi wygasłego sekretu.

Jeśli oauth_sso_webadmin.log pokazuje x509: certificate signed by unknown authority, może brakować Root CA lub Intermediate CA dla faktycznie przedstawionego łańcucha certyfikatów Microsoft. Łańcuch widziany przez firewall odczytuje się w jego Advanced Shell:

openssl s_client -connect login.microsoftonline.com:443 -showcerts

Komputer testowy może posłużyć do porównania, ale nie dowodzi, jaki łańcuch widzi sam firewall. Importuj wyłącznie CA, której brakuje w sposób potwierdzony i która pochodzi z zaufanego źródła. Nie używaj certyfikatu serwera jako CA i nie restartuj usługi SSO jako pierwszego kroku rozwiązywania problemu.

Jeśli Test connection nadal nie powiedzie się po poprawieniu łańcucha CA, udokumentowany przez Sophos lokalny dla węzła restart usługi WebAdmin SSO jest opcjonalnym ostatnim krokiem w oknie serwisowym:

service oauth_sso_webadmin:restart -ds nosync

Następnie ponownie wykonuje się Test connection i nowe logowanie SSO. Restart nie zastępuje DNS, czasu, uprawnień aplikacji, Admin Consent ani kompletnego łańcucha certyfikatów.

SSO działa na Primary, ale nie na Auxiliary

Jest to udokumentowane ograniczenie HA. WebAdmin urządzenia Auxiliary wymaga przetestowanego dostępu lokalnego. Nowa rola Entra, szersze udostępnienie Device Access ani inny Redirect URI nie usuną tego ograniczenia.

Lista kontrolna

Lokalne konto admin, drugi administrator i dostęp konsolowy działają.
WebAdmin jest dostępny tylko z przewidzianych sieci zarządzających lub źródeł.
FQDN, DNS, certyfikat i czas systemowy są prawidłowe.
App Registration, uprawnienia, Admin Consent i wygaśnięcie sekretu są udokumentowane.
Dla dedykowanej aplikacji WebAdmin aktywowano Assignment required i przypisano wyłącznie grupę administratorów pilotażowych. Dla wspólnej aplikacji uwzględniono i przetestowano wszystkie uprawnione grupy administratorów, VPN i portali.
Profile Device Access zawierają zamierzone uprawnienia.
SFOS 22: User type: Administrator i Role mapping są uporządkowane prawidłowo. SFOS 23: IdP authentication for firewall administrators jest włączone, a IdP attribute, IdP value i Device access profile zostały sprawdzone.
Dokładny Web admin console URL jest wpisany jako Entra Redirect URI.
Test connection kończy się powodzeniem.
Entra jest aktywna w Administrator authentication methods.
Testy Read-only, Full Access, negatywny i lokalnego fallbacku zakończyły się powodzeniem.
Sprawdzono Entra Sign-in Logs i plik logu właściwy dla wersji firmware: SFOS 22 oauth_sso_webadmin.log, SFOS 23 oauth_sso_svc.log; w Log Viewer moduł Admin.
Odebranie roli, wymiana sekretu i ograniczenie HA są udokumentowane operacyjnie.