Przejdz do tresci
Avanet

Skonfiguruj logowanie jednokrotne Microsoft Entra ID dla portalu przechwytującego Sophos Firewall

Dzięki Microsoft Entra ID SSO dla Captive Portal, Sophos Firewall może uwierzytelniać użytkowników za pomocą Microsoft Entra ID za pośrednictwem przeglądarki, zanim reguły zapory oparte na użytkownikach zaczną obowiązywać. Jest to szczególnie interesujące w przypadku sieci BYOD, stref gościnnych lub partnerskich, urządzeń bez przezroczystej detekcji AD lub środowisk, w których STAS nie pasuje do wszystkich klientów.

Ważne jest rozróżnienie: Captive Portal nie jest VPN Portal ani zdalnym dostępem. Użytkownik jest już w sieci lokalnej lub Wi-Fi i loguje się w przeglądarce, aby firewall mógł przypisać późniejszy ruch do tożsamości użytkownika. W przypadku zdalnego dostępu za pomocą Sophos Connect odpowiedni jest osobny artykuł Konfigurowanie Microsoft Entra ID SSO dla Sophos Connect i VPN Portal.

Jeśli Microsoft Entra ID SSO jest już skonfigurowane dla VPN Portal lub Sophos Connect, nie trzeba automatycznie tworzyć całkowicie nowego projektu Entra. W wielu przypadkach można ponownie użyć tego samego obiektu serwera Microsoft Entra ID na firewallu. Captive Portal nadal wymaga poprawnego Captive portal URL jako Redirect URI, przypisania w Authentication > Services oraz osobnego testu późniejszej reguły użytkownika.

Kiedy Captive Portal z Entra ID SSO ma sens

Portal przechwytujący z Entra ID SSO ma sens, jeśli użytkownicy i tak logują się za pomocą Microsoft 365, a zapora sieciowa potrzebuje tożsamości użytkownika w niektórych sieciach.

Typowe zastosowania:

  • Sieci BYOD lub WiFi bez dołączania do domeny.
  • Goście lub użytkownicy zewnętrzni z kontrolowanym dostępem do kilku miejsc docelowych.
  • Reguły internetowe oparte na użytkownikach bez STAS lub SATC.
  • Sieci, w których przejrzyste uwierzytelnianie jest zawodne.
  • Scenariusze przejścia, w których należy ograniczyć lokalne uwierzytelnianie usługi AD.

W przypadku w pełni zarządzanych klientów Windows w klasycznej domenie Captive Portal nie jest automatycznie najlepszym rozwiązaniem. Tam STAS, AD SSO lub inne transparentne procedury mogą być bardziej ergonomiczne, ponieważ użytkownicy nie muszą aktywnie uruchamiać logowania w przeglądarce. Captive Portal jest raczej rozwiązaniem awaryjnym albo specjalnym dla urządzeń niezarządzanych.

Oddzielny portal przechwytujący, portal VPN i portal użytkowników

Dzięki Entra ID SSO terminy portalowe szybko ulegają pomieszaniu. Separacja ma kluczowe znaczenie dla konfiguracji.

  • Captive Portal: Użytkownicy sieci lokalnej logują się w przeglądarce, aby zadziałały reguły oparte na tożsamości użytkownika. Entra ID SSO służy do logowania w przeglądarce i przypisania użytkownika.
  • Portal VPN: Użytkownicy zdalnego dostępu pobierają Sophos Connect lub konfiguracje VPN. Entra ID SSO służy tutaj do dostępu zdalnego i logowania do portalu.
  • Portal użytkownika: Ten portal zawiera funkcje użytkownika, takie jak OTP lub starsze opcje osobiste. W zależności od środowiska może nadal służyć do obsługi tokenów lub opcji użytkownika.

Ogólny przegląd portali dostępny jest w Portale Sophos: SophosID, Central, Support i dostęp do firewalla. W przypadku Captive Portal należy przede wszystkim sprawdzić, z której strefy źródłowej można uzyskać dostęp do lokalnej usługi firewalla i która reguła firewalla przetwarza następnie rzeczywisty ruch użytkowników. Klasyczną konfigurację bez ścieżki specyficznej dla Microsoft opisuje artykuł Konfiguracja i testowanie Captive Portal w Sophos Firewall, od Device Access i DNS po regułę użytkownika oraz Live users. W przypadku Entra ID SSO dochodzą następnie rejestracja aplikacji, Redirect URI oraz kontrole OAuth/OIDC opisane w tym artykule.

Wymagania

Przed konfiguracją należy wyjaśnić następujące punkty:

  • Sophos Firewall w wersji SFOS obsługującej Microsoft Entra ID SSO.
  • Najemca Microsoft Entra z pozwoleniem na rejestrację aplikacji, przekierowania URI, uprawnienia API, zgodę administratora i sekret klienta.
  • FQDN i certyfikat dla portalu przechwytującego, aby użytkownicy nie widzieli niepotrzebnych ostrzeżeń przeglądarki.
  • Dostępność punktów końcowych logowania Microsoft z sieci klienckiej, której dotyczy problem.
  • Portal przechwytujący jest dozwolony w Administracja > Dostęp do urządzenia dla właściwej strefy.
  • Użytkownicy lub grupy są utrzymywane w przejrzysty sposób w Microsoft Entra ID.
  • Reguły zapory sieciowej korzystają z oczekiwanych użytkowników lub grup.
  • Dostępny jest użytkownik testowy i dostęp awaryjny.
  • Czas i NTP na zaporze i klientach są prawidłowe, ponieważ protokół OAuth/OIDC jest zależny od czasu.
  • Jeśli w Microsoft Entra ID jest aktywna opcja Wymagane przypisanie, wymagani użytkownicy lub grupy są przypisani do aplikacji korporacyjnej.

⚠️ Portal przechwytujący to obszar logowania na zaporze sieciowej. Powinien być dostępny tylko w tych strefach, gdzie jest naprawdę potrzebny. Dostęp do urządzenia i lista ACL usług lokalnych to tutaj elementy kontroli bezpieczeństwa, a nie tylko ustawienia połączenia.

Zabezpieczanie dostępu do zapory Sophos: Skonfiguruj dostęp do urządzenia nadaje się do wzmacniania lokalnych usług firewall. W tym projekcie MFA jest zaimplementowane w Microsoft Entra ID, na przykład poprzez dostęp warunkowy. Lokalne MFA zapory Sophos nie zastępuje współczynnika logowania Microsoft przez Entra ID SSO. Zwykle jest to lepsze z punktu widzenia użytkownika, ponieważ używana jest ta sama usługa MFA, co Microsoft 365, ale należy ją dokładnie zaplanować i przetestować w dzierżawie.

Zaplanuj architekturę przed umeblowaniem

Przed konfiguracją techniczną należy zdecydować, jakie zadanie portal przechwytujący ma konkretnie rozwiązać. W przeciwnym razie szybko otrzymasz login, który działa, ale nie uruchamia odpowiedniej reguły zapory sieciowej.

Ważne pytania projektowe:

  • Która strefa korzysta z portalu przechwytującego?: Dostęp do urządzenia i źródło reguł zależą od strefy.
  • Która grupa użytkowników może się zalogować?: Grupa Entra musi być zgodna z późniejszą regułą zapory.
  • Jakie cele można osiągnąć po zalogowaniu?: Portal Captive nie zastępuje czystej segmentacji.
  • Jak długo sesje powinny być ważne?: Zbyt długie sesje rozrzedzają przydział użytkowników, a zbyt krótkie zakłócają operacje.
  • Co się stanie w przypadku awarii Entra lub Internetu?: W przypadku kluczowych zadań należy zapewnić wyraźne rozwiązanie awaryjne.
  • W jaki sposób uruchamiane jest logowanie?: Użytkownicy potrzebują dostępnego adresu URL portalu przechwytującego lub czystego przekierowania.

Portalu przechwytującego nie należy używać jako zamiennika sieci VLAN, stref ani minimalnych reguł zapory sieciowej. Zapora sieciowa zna użytkownika lepiej po zalogowaniu, ale architektura sieci musi nadal pozostać czysta. Do podstawowej logiki stref odpowiednia jest Skonfiguruj strefę i interfejsy zapory Sophos.

Utwórz serwer Microsoft Entra ID

Konfiguracja składa się z dwóch części: Najpierw przygotowywana jest rejestracja aplikacji w Microsoft Entra ID. Ta aplikacja jest następnie rejestrowana jako serwer uwierzytelniania w zaporze sieciowej Sophos.

Przygotuj rejestrację aplikacji w Microsoft Entra ID

W Microsoft Entra ID należy utworzyć osobną rejestrację aplikacji dla zapory sieciowej. Oznacza to, że identyfikatory URI przekierowań, uprawnienia i sekrety klienta pozostają wyraźnie oddzielone od innych aplikacji.

Typowy proces:

  1. Otwórz centrum administracyjne Microsoft Entra.
  2. Otwórz Rejestracje aplikacji > Nowa rejestracja.
  3. Podaj sensowną nazwę, np. Sophos-Firewall-SSO.
  4. Z reguły jako obsługiwany typ konta wybieraj własnego najemcę.
  5. Skorzystaj z Platformy Web.
  6. Zanotuj ID aplikacji (klienta) i ID katalogu (dzierżawy).
  7. Utwórz klucz tajny klienta w obszarze Certyfikaty i sekrety i natychmiast bezpiecznie zapisz wartość sekretu.
  8. W obszarze Uprawnienia API dodaj wymagane uprawnienia Microsoft Graph, zazwyczaj User.Read.All i Group.Read.All.
  9. Udziel zgody administratora na uprawnienia.
  10. Jeśli używana jest opcja Wymagane przypisanie, przypisz dozwolonych użytkowników lub grupy do aplikacji korporacyjnej.

Bez odpowiednich uprawnień API i zgody administratora login może przedostać się do loginu Microsoft, ale zapora nie może wówczas poprawnie ocenić danych użytkownika lub grupy. W praktyce często wygląda to na problem z portalem przechwytującym, mimo że przyczyną jest Microsoft Entra ID.

Utwórz lub użyj ponownie serwera Entra ID na Sophos Firewall

Ścieżka menu w zaporze Sophos to:

Authentication > Servers

Podstawowy proces:

  1. Otwórz Dodaj.
  2. Wybierz opcję Microsoft Entra ID SSO jako Typ serwera.
  3. Nadaj nazwę opisową, np. Entra-SSO-Firewall.
  4. Wprowadź ID aplikacji (klienta) z aplikacji Entra.
  5. Wpisz ID katalogu (dzierżawcy).
  6. Wpisz Sekret klienta.
  7. Świadomie ustaw grupę rezerwową i staraj się, aby była ona jak najbardziej restrykcyjna.
  8. Sprawdź połączenie.
  9. Zapisz.

Grupa fallback nie powinna mieć szerokiego dostępu do internetu ani sieci. To zabezpieczenie, a nie skrót omijający autoryzację.

⚠️ Client secrets są produkcyjnymi danymi dostępowymi. Data ważności, rotacja i odpowiedzialność powinny być udokumentowane. Wygasły secret z perspektywy użytkownika często wygląda jak zwykły problem logowania, ale w rzeczywistości jest problemem konfiguracji lub eksploatacji.

Wprowadź poprawnie identyfikatory URI przekierowania

Podczas rejestracji aplikacji w Microsoft Entra ID należy wprowadzić identyfikator URI przekierowania zgodny z zaporą sieciową. Bardzo ważne jest, aby nazwa FQDN, certyfikat, port i ścieżka były dokładnie zgodne. Niewielkie różnice w nazwie hosta, porcie, protokole lub ukośniku wystarczą, aby proces OAuth/OIDC zakończył się niepowodzeniem.

Zapora Sophos wyświetla wymagane adresy URL usług na serwerze Entra ID. Adres URL portalu Captive jest szczególnie istotny w przypadku tego artykułu. Jeśli używane jest również WebAdmin lub Remote Access z Entra ID SSO, usługi te mają własne adresy URL:

  • Adres URL konsoli administracyjnej: Entra ID SSO dla konsoli WebAdmin.
  • Adres URL portalu przechwytującego: Entra ID SSO dla Captive Portal w sieci lokalnej.
  • Portal VPN i adres URL dostępu zdalnego: Entra ID SSO dla portalu VPN i Sophos Connect.

Jeśli ten sam serwer Entra ID jest już używany dla Remote Access, dodaj Captive portal URL do istniejących Redirect URIs w aplikacji Entra. Captive Portal nadal trzeba przetestować osobno, ponieważ ścieżka logowania, Device Access, dopasowanie grup i późniejsza reguła firewall mają inne typowe błędy niż Sophos Connect lub VPN Portal.

Ustaw metodę uwierzytelniania portalu przechwytującego

Po utworzeniu serwera Entra metoda uwierzytelniania dla Captive Portal musi wskazywać właściwy serwer.

Odpowiedni obszar znajduje się pod:

Authentication > Services

Aby sprawdzić:

  1. Otwórz obszar Firewall authentication methods.
  2. Dodaj lub przeciągnij serwer Microsoft Entra ID na właściwą pozycję.
  3. Zachowaj inne serwery uwierzytelniające tylko wtedy, gdy służą one celowo jako rezerwa.
  4. Zastosuj zmianę za pomocą Zastosuj.
  5. Wykonaj logowanie testowe z jednym użytkownikiem.

Jeżeli równolegle aktywnych jest kilka metod uwierzytelniania, musi być jasne, który serwer odpowiada za którą grupę użytkowników. Dla tego samego użytkownika należy w miarę możliwości używać tylko jednego źródła uwierzytelniania. W wersji firmware objętej NC-167128 firewall może odrzucić sesję z komunikatem no permission, jeśli użytkownik przejdzie z Entra ID SSO na lokalne logowanie AD, a następnie ponownie wykorzysta wcześniejszy token Entra. Taki tryb mieszany jest trudniejszy do przetestowania i powinien być stosowany oraz dokumentowany wyłącznie świadomie.

Dodatkowo należy sprawdzić w zakładce Uwierzytelnianie > Uwierzytelnianie sieciowe w jaki sposób otwierany jest portal przechwytujący w przeglądarce. HTTPS jest ważny dla Entra ID SSO. Opcja Użyj niebezpiecznego protokołu HTTP zamiast HTTPS nie powinna być aktywowana, ponieważ przepływ Entra-OAuth przez HTTP nie jest prawidłowo obsługiwany i byłby niepotrzebnie niebezpieczny.

Poniższe informacje są pomocne w obsłudze:

  1. Otwórz Captive Portal w nowym oknie przeglądarki.
  2. Podczas sesji nie zamykaj okna portalu przechwytującego.
  3. Świadomie poproś użytkowników o wylogowanie się za pośrednictwem portalu przechwytującego, jeśli powiązanie ma zostać zakończone.
  4. Po zalogowaniu sprawdź w zakładce Aktualności > Użytkownicy aktywni czy użytkownik jest widoczny.

W zależności od interfejsu i certyfikatu, standardowy adres URL https://<Firewall-IP>:8090 może również pomóc w testowaniu. Czysta nazwa FQDN z odpowiednim certyfikatem jest znacznie przyjemniejsza w produktywnym działaniu.

Sprawdź dostęp do urządzenia i dostępność portalu

Captive Portal to lokalna usługa zapory sieciowej. Sama zwykła reguła zapory sieciowej nie pozwala na taki dostęp. Dostępność jest kontrolowana w Administracja > Dostęp do urządzenia dla odpowiedniej strefy.

Powinieneś sprawdzić:

  • Portal przechwytujący jest dozwolony tylko w wymaganych strefach.
  • Oznacza to, że WebAdmin i SSH nie są przypadkowo również szeroko dostępne.
  • Certyfikat i nazwa FQDN odpowiadają adresowi URL użytkownika.
  • DNS w sieci klienta poprawnie rozpoznaje nazwę portalu.
  • Reguły wyjątków ACL usług lokalnych są ustawiane tylko wtedy, gdy są naprawdę konieczne.

Jeśli Portal przechwytujący nie jest dostępny z sieci, nie należy najpierw tworzyć normalnej reguły Zezwalaj. Przyczyną często jest dostęp do urządzenia, lokalna usługa ACL, DNS, certyfikat lub nieprawidłowe mapowanie stref.

Uwzględnij logowanie Microsoft i filtr internetowy

Podczas logowania klient musi uzyskać dostęp do stron logowania Microsoft i powiązanych zasobów. W przeciwnym razie w sieciach z restrykcyjnymi ograniczeniami przepływ SSO może zostać zatrzymany w punkcie, który w oczach użytkowników będzie wyglądał jak błąd zapory sieciowej lub przeglądarki.

Aby sprawdzić:

  • Rozpoznawanie DNS dla domen logowania Microsoft działa.
  • Dozwolony jest protokół HTTPS do punktów końcowych logowania Microsoft.
  • Filtr sieciowy, inspekcja TLS lub proxy nie blokują strony logowania.
  • Czas na zaporze i kliencie jest wiarygodny.
  • Pliki cookie przeglądarki nie stają się bezużyteczne w wyniku rygorystycznych zasad.

W restrykcyjnych środowiskach należy wyraźnie sprawdzić login Microsoft i punkty końcowe Entra. W zależności od najemcy, przeglądarki i ścieżki logowania Microsoft istotne są te domeny m.in.:

  • login.microsoftonline.com
  • *.login.microsoftonline.com
  • *.microsoftonline.com
  • *.msauth.net
  • *.msftauth.net
  • aadcdn.msauth.net
  • aadcdn.msftauth.net
  • aadcdn.msftauthimages.net
  • graph.microsoft.com

Jeśli filtr sieciowy, inspekcja proxy lub TLS zacznie działać przed zalogowaniem, cele te nie powinny być niepotrzebnie odszyfrowywane ani blokowane. Należy sprawdzić Zezwalaj na sekcję URL documentacji Entra ID pod kątem bardzo restrykcyjnych zasad.

Jeżeli włączona jest Ochrona WWW lub Inspekcja TLS, w przeglądarce logów należy obserwować logowanie użytkownika testowego. Czasami problemem nie jest sam portal Captive, ale zasady sieciowe, wyjątek TLS lub sieć kliencka, która nie dociera w pełni do punktów końcowych Microsoft.

Przetestuj grupy użytkowników i reguły zapory sieciowej

Po pomyślnym zalogowaniu się do portalu przechwytującego rzeczywista reguła zapory musi widzieć użytkownika lub grupę w ruchu. To najważniejszy sprawdzian praktyczny.

Typowy proces:

  1. Sprawdź użytkowników w Microsoft Entra ID.
  2. Porównaj nazwę UPN, adres e-mail i członkostwo w grupie.
  3. Sprawdź grupę Entra na zaporze Sophos.
  4. W regule użytkownika włącz Match known users i Use web authentication for unknown users.
  5. Wykonaj logowanie do portalu przechwytującego za pomocą użytkownika testowego.
  6. Następnie uruchom rzeczywisty ruch użytkowników, na przykład HTTPS, do dozwolonego miejsca docelowego.
  7. W przeglądarce logów sprawdź, czy użytkownik, grupa, strefa źródłowa, sieć źródłowa i identyfikator reguły odpowiadają oczekiwanej regule.

Pomyślne logowanie do przeglądarki potwierdza jedynie uwierzytelnienie. Nie dowodzi to, że obowiązuje późniejsza reguła użytkownika. Jeżeli licznik reguł pozostaje na poziomie 0 lub w przeglądarce logów nie widać żadnego użytkownika, należy skorzystać z przepływu z Regula zapory sieciowej Sophos nie działa: Sprawdź wystąpienie.

Dopasowanie grup i wcześniejsze ograniczenie Primary Group

W regułach użytkownika zamierzona grupa Entra musi być obecna na zaporze. Po zalogowaniu należy sprawdzić w Current activities > Live users oraz w Log Viewer, do której grupy przypisano użytkownika i która Rule ID przetwarza ruch.

W SFOS 20.0 GA Build 222 istniało znane ograniczenie: w przypadku NC-167130 dostęp do Internetu przez dodatkową grupę Entra nie działał; reguła musiała zawierać Primary Group albo konkretnego użytkownika. Sophos wskazuje SFOS 21.5 MR2 Build 323 i SFOS 22.0 MR1 Build 490 jako wersje z poprawką. W aktualnych buildach Primary Group nie jest już ogólnym wymaganiem projektowym.

Dlatego przed wdrożeniem należy zapisać dla każdego użytkownika testowego następujące informacje:

  • Grupa Entra: Znane są grupa docelowa i członkostwo użytkownika.
  • Grupa na zaporze sieciowej Sophos: Ta sama grupa została poprawnie zaimportowana lub zmapowana.
  • Reguła zapory: Zamierzona grupa jest uwzględniona w warunku użytkownika lub grupy.
  • Ruch testowy po zalogowaniu: Log Viewer pokazuje użytkownika, grupę, Rule ID i oczekiwaną akcję.
  • Starszy build objęty problemem: Użyć Primary Group lub reguły testowej dla konkretnego użytkownika i zaplanować aktualizację.

Nie ma to wpływu na Sophos Connect VPN z Microsoft Entra ID SSO. W przypadku dostępu zdalnego należy zatem sprawdzić oddzielny proces dla Microsoft Entra ID SSO dla Sophos Connect i portal VPN.

Walidacja po wdrożeniu

Aby zatwierdzić wdrożenie, nie wystarczy sprawdzić, czy pojawia się strona logowania Microsoft.

  • Otwórz adres Captive Portal z sieci klienckiej: Przeglądarka wyświetla oczekiwane logowanie Entra lub przekierowanie Sophos.
  • Zaloguj się z dozwolonym użytkownikiem: Logowanie powiodło się, użytkownik pojawia się na zaporze.
  • Zaloguj się z niedozwolonym użytkownikiem: Dostęp jest zrozumiale zabroniony.
  • Test reguły grupowej: Użytkownik testowy spełnia oczekiwaną regułę użytkownika.
  • Ruch użytkowników po zalogowaniu: poprawna reguła zapory sieciowej zgodna z referencją użytkownika.
  • Przebieg sesji: Po upływie limitu czasu musisz zalogować się ponownie.
  • Logowanie Microsoft zablokowane: Przeglądarka dzienników lub dzienniki internetowe pokazują zrozumiały powód.
  • Scenariusz awaryjny: Administrator wie, jak sprawdzić lub tymczasowo zmienić dostęp w przypadku zakłócenia działania Entra.

Szczególnie w przypadku sieci BYOD należy przeprowadzić testy na wielu przeglądarkach i urządzeniach. Tryby przeglądania prywatnego, zablokowane pliki cookie innych firm, stare zapisane loginy lub wiele kont Microsoft na tym samym urządzeniu mogą dawać różne wyniki.

Rozwiązywanie problemów

Portal przechwytujący nie jest osiągalny

Najpierw sprawdź Administracja > Dostęp do urządzenia dla dotkniętej strefy. Następnie sprawdź DNS, certyfikat, nazwę FQDN portalu, listę ACL usług lokalnych i mapowanie stref. Jeśli dostęp przechodzi do samej zapory, normalna reguła zapory nie jest pierwszym punktem kontrolnym.

Logowanie do Microsoft rozpoczyna się, ale nie wraca

Porównaj identyfikator URI przekierowania, nazwę FQDN, certyfikat i port. Dokładny adres URL używany przez zaporę Sophos w portalu przechwytującym musi być zapisany w identyfikatorze Microsoft Entra ID. Zasady kontroli proxy lub TLS mogą również zakłócać zwrot.

Gdy Microsoft wyświetla błąd AADSTS50011, identyfikator URI przekierowania w rejestracji aplikacji zwykle nie jest zgodny z adresem URL używanym przez zaporę sieciową. Następnie należy dokładnie porównać protokół, nazwę FQDN, port i ścieżkę.

Po zalogowaniu się Microsoft pojawia się błąd wewnętrzny

500 Internal Server Error lub podobny błąd ogólny po pomyślnym zalogowaniu się do Microsoft często wskazuje na brak uprawnień Microsoft Graph, brak zgody administratora lub problem z kluczem tajnym klienta. Następnie sprawdź uprawnienia API, zgodę administratora, ważność sekretu i przypisanie aplikacji korporacyjnej w Microsoft Entra ID.

Nazwa użytkownika i hasło nie działają bezpośrednio

Entra ID SSO to przeglądarka i przepływ OAuth/OIDC. Użytkownicy nie logują się bezpośrednio do zapory przy użyciu klasycznych poświadczeń, ale są przekierowywani do firmy Microsoft. Jeśli klient lub przepływ obsługuje tylko nazwę użytkownika i hasło bez przekierowania przeglądarki, ta metoda nie pasuje.

MFA nie pojawia się lub wygląda inaczej niż oczekiwano

W przypadku Entra ID SSO, MFA jest kontrolowane w Microsoft Entra ID. Lokalna zapora MFA nie jest właściwym punktem kontrolnym dla tego przepływu logowania jednokrotnego. Jeśli wymagane jest MFA, należy sprawdzić dostęp warunkowy, grupy użytkowników, wykluczenia i przetestować użytkowników w Microsoft Entra ID.

Użytkownik widzi no permission lub zostaje odrzucony po dłuższej operacji

Ten błąd odpowiada NC-167128 w SFOS 21.0 GA Build 169: jeśli ten sam użytkownik najpierw korzysta z Entra ID SSO, następnie z lokalnego AD w sieci wewnętrznej, a potem ponownie używa starego tokenu Entra, może pojawić się komunikat no permission. Problem naprawiono w SFOS 21.5 MR2 Build 323 oraz SFOS 22.0 MR1 Build 490.

W wersji objętej problemem najpierw należy usunąć pliki cookie przeglądarki. Jeśli problem występuje w Sophos Connect, należy wykonać Force SSO re-login; ścieżkę opisano w artykule Konfigurowanie Microsoft Entra ID SSO dla Sophos Connect i VPN Portal. Docelowo należy konsekwentnie używać Entra ID albo lokalnego AD dla tego samego użytkownika i zaktualizować firewall do poprawionej wersji firmware.

Logowanie działa, ale reguła użytkownika nie pasuje

Wtedy portal przechwytujący nie będzie już prawdopodobnie jedynym problemem. Sprawdź strefę źródłową, sieć źródłową, grupę użytkowników, pozycję reguły i przeglądarkę logów. Często bardziej ogólna reguła jest nadrzędna wobec reguły użytkownika lub ruch pochodzi z innej sieci niż oczekiwano.

Należy również sprawdzić, czy zamierzona grupa Entra jest zaimportowana i czy użytkownik został do niej przypisany na zaporze. Tylko w SFOS 20.0 GA Build 222, którego dotyczy NC-167130, reguła musi w przypadku tego błędu zawierać Primary Group albo konkretnego użytkownika.

Dotyczy to tylko indywidualnych użytkowników

Porównaj nazwę UPN, adres e-mail, nazwę wyświetlaną, członkostwo w grupie i zaimportowaną grupę. W przypadku Entra ID SSO nie należy zakładać, że widoczna nazwa i identyfikator techniczny są identyczne. Jeśli adres e-mail i nazwa UPN w przeszłości się różnią, łatwo pojawiają się błędy mapowania.

Które logi są pomocne?

W przypadku Captive Portal z Entra ID SSO szczególnie ważny jest oauth_sso_captive.log. Pomocne są również Log Viewer z modułem Authentication, access_server.log, a w zależności od późniejszego problemu także logi Web, firewalla lub uwierzytelniania. Przypisanie najważniejszych plików opisano w Rozwiązywanie problemów z zaporą Sophos: usługi i logi.

Lista kontrolna

  • Przypadek użycia portalu Captive jest jasny: BYOD, goście, urządzenia niezarządzane lub rozwiązanie awaryjne.
  • Nazwa FQDN i certyfikat portalu przechwytującego są czyste.
  • Udokumentowano aplikację Microsoft Entra ID z identyfikatorem URI przekierowania, identyfikatorem klienta, identyfikatorem dzierżawcy i kluczem klienta.
  • Ustawiono uprawnienia Microsoft Graph API i zgodę administratora.
  • Przypisania aplikacji dla przedsiębiorstw są sprawdzane, jeśli opcja Wymagane przypisanie jest aktywna.
  • Sekret Klienta ma datę ważności, właściciela i proces rotacji.
  • URI przekierowania portalu Captive został przejęty przez zaporę sieciową i wprowadzony dokładnie do Entra ID.
  • Uwierzytelnianie > Usługi używa prawidłowego serwera Entra dla Captive Portal.
  • Uwierzytelnianie > Uwierzytelnianie internetowe wykorzystuje protokół HTTPS i odpowiednie ustawienia okna przeglądarki.
  • Administracja > Dostęp do urządzenia pozwala na portal przechwytujący tylko w wymaganych strefach.
  • Z sieci klienckiej można uzyskać dostęp do punktów końcowych logowania Microsoft.
  • Filtrowanie sieci i inspekcja TLS nie blokują przepływu SSO.
  • MFA i dostęp warunkowy są planowane i testowane w Microsoft Entra ID.
  • Dopasowanie grupy Entra i grupy zapory ogniowej.
  • Zamierzona grupa Entra jest zaimportowana i faktycznie uwzględniana dla użytkownika testowego.
  • Użytkownik testowy może się zalogować, a następnie trafić na oczekiwaną regułę zapory sieciowej.
  • Przeglądarka logów pokazuje użytkownika, identyfikator reguły i akcję.
  • oauth_sso_captive.log i access_server.log są znane ze spraw wsparcia.
  • Udokumentowano awarię w przypadku awarii Entra lub Portalu.

Często zadawane pytania

Czy Captive Portal z Entra ID SSO to to samo, co Sophos Connect SSO?

Nie. Captive Portal uwierzytelnia użytkowników w sieci lokalnej za pośrednictwem przeglądarki, dzięki czemu mogą obowiązywać reguły oparte na użytkownikach. Sophos Connect SSO jest częścią Portalu Dostępu Zdalnego i VPN.

Czy portal przechwytujący musi być publicznie dostępny?

Nie. Portal Captive jest zwykle przeznaczony dla stref wewnętrznych lub stref Wi-Fi. Dostępność powinna być ustawiona tak wąsko, jak to możliwe poprzez Dostęp do urządzenia.

Dlaczego reguła użytkownika nie pasuje pomimo udanego logowania?

Logowanie potwierdza jedynie uwierzytelnienie. Następnie strefa źródłowa, sieć źródłowa, zaimportowana grupa Entra, pozycja reguły i rzeczywisty ruch muszą odpowiadać regule. W SFOS 20.0 GA Build 222 należy dodatkowo sprawdzić znane ograniczenie Primary Group; poprawiono je w SFOS 21.5 MR2 i 22.0 MR1.

Który plik dziennika jest ważny dla Entra Captive Portal SSO?

oauth_sso_captive.log jest ważny dla przepływu logowania jednokrotnego OAuth w portalu przechwytującym. Dodatkowo powinieneś sprawdzić przeglądarkę logów i access_server.log.

Czy możesz równolegle używać Entra ID i lokalnego uwierzytelniania AD?

W zależności od projektu może to działać, ale zwiększa ryzyko błędów. Jeśli ci sami użytkownicy są uwierzytelniani równolegle poprzez Entra ID SSO i lokalne AD, sesje, grupy i ścieżki logowania powinny być testowane szczególnie czysto.