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: Portal Captive nie jest portalem VPN ani dostępem zdalnym. Użytkownik jest już w sieci lokalnej lub Wi-Fi i loguje się do przeglądarki, aby zapora sieciowa mogła przypisać kolejny ruch do tożsamości użytkownika. W przypadku zdalnego dostępu za pomocą Sophos Connect odpowiedni jest osobny artykuł Skonfiguruj logowanie jednokrotne Microsoft Entra ID dla Sophos Connect i portal VPN.

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 STASZ 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 domenie klasycznej Captive Portal nie jest automatycznie najlepszym rozwiązaniem. Tam STASZ, AD SSO lub inne przejrzyste procedury mogą być bardziej ergonomiczne, ponieważ użytkownicy nie muszą aktywnie uruchamiać logowania w przeglądarce. Portal przechwytujący to raczej rozwiązanie awaryjne lub specjalne 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.

Ogólny przegląd portalu dostępny jest w Portale Sophos: SophosID, Central, Support i dostęp do firewalla. W przypadku portalu przechwytującego należy przede wszystkim sprawdzić, z której strefy można uzyskać dostęp do lokalnej usługi zapory ogniowej i która reguła zapory sieciowej przetwarza następnie rzeczywisty ruch użytkowników.

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:

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 identyfikatorów Microsoft Entra

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-Captive-Portal.
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 serwer Entra ID na zaporze Sophos

Ś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-Captive-Portal.
4. Wprowadź ID aplikacji (klienta) z aplikacji Entra.
5. Wpisz ID katalogu (dzierżawcy).
6. Wpisz Sekret klienta.
7. W zależności od projektu aktywuj opcję Dopasuj znanych użytkowników, jeśli mają być mapowani istniejący lokalni użytkownicy lub grupy.
8. Opcji Użyj uwierzytelniania sieciowego dla nieznanych użytkowników używaj tylko wtedy, gdy nieznani użytkownicy mają być celowo obsługiwani za pośrednictwem grupy awaryjnej.
9. Świadomie ustaw grupę rezerwową i staraj się, aby była ona jak najbardziej restrykcyjna.
10. Sprawdź połączenie.
11. Zapisz.

Grupa rezerwowa nie powinna mieć dostępu do szerokiego Internetu ani udostępniania sieci. Przede wszystkim jest to zabezpieczenie, dzięki któremu użytkownik nie uzyska w sposób niekontrolowany większego dostępu, niż planował.> ⚠️ Sekrety klienta to produktywne dane dostępowe. Należy udokumentować datę ważności, rotację i odpowiedzialność. Z punktu widzenia użytkownika wygasły sekret często wydaje się normalnym problemem z logowaniem, ale w rzeczywistości jest to problem konfiguracyjny lub operacyjny.

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:

W przypadku portalu przechwytującego w tym przepływie należy testować tylko identyfikator URI przekierowania portalu przechwytującego. Adres URL VPN jest częścią projektu zdalnego dostępu i jest omówiony w osobnym artykule na temat Microsoft Entra ID SSO dla Sophos Connect i portal VPN.

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 dla Metod uwierzytelniania portalu przechwytującego.
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. Mieszane działanie Entra ID i lokalnego uwierzytelniania AD może działać, ale znacznie zwiększa wysiłek związany z rozwiązywaniem problemów. Lista znanych problemów Sophos dokumentuje przypadki Entra SSO, w których mieszane sesje Entra i lokalne sesje AD mogą prowadzić do błędów podobnych do no permission.

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.

Weź pod uwagę login Microsoft i filtr sieciowyPodczas 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. Wykonaj logowanie do portalu przechwytującego za pomocą użytkownika testowego.
5. Następnie uruchom rzeczywisty ruch użytkowników, na przykład HTTPS, do dozwolonego miejsca docelowego.
6. 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.

Uwaga Grupa podstawowa dla portalu przechwytującego Entra

W przypadku portali przechwytujących z Microsoft Entra ID SSO należy szczególnie sprawdzić, która grupa jest faktycznie oceniana przez zaporę sieciową pod kątem kolejnej reguły użytkownika. W przypadku użytkowników Entra-ID SSO dostęp do Internetu poprzez Captive Portal może działać tylko wtedy, gdy w regule zapory używana jest Grupa podstawowa użytkownika. Grupy dodatkowe nie zachowują się tak samo, jak w przypadku klasycznych lokalnych użytkowników usługi AD.

W praktyce oznacza to: Użytkownik może pomyślnie zalogować się do portalu przechwytującego i nadal nie spełnić oczekiwanej reguły, jeśli reguła wskazuje jedynie na drugorzędną grupę Entra. Ten błąd szybko wygląda na problem z portalem przechwytującym, OAuth lub przeglądarką, mimo że sam login był poprawny.

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

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 to zaakceptować, należy nie tylko sprawdzić, czy pojawi się strona logowania Microsoft.| test | Oczekiwany wynik | | — | — | | Otwórz adres URL portalu przechwytującego z sieci klienta | Przeglądarka pokazuje 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 grupy podstawowej | 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

Wyczyść pliki cookie przeglądarki i sprawdź, czy ten sam użytkownik jest używany równolegle przez Entra ID SSO i lokalne uwierzytelnianie AD. Mieszając Entra i On-Prem AD dla tego samego użytkownika, projekt uwierzytelniania powinien zostać uproszczony lub przynajmniej przejrzyście udokumentowany.

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.

W przypadku Entra ID SSO za pośrednictwem Captive Portal należy również sprawdzić, czy reguła zapory sieciowej korzysta z podstawowej grupy użytkownika. Jeśli w regule znajduje się tylko grupa dodatkowa, logowanie może zakończyć się pomyślnie, podczas gdy rzeczywisty dostęp do Internetu lub miejsca docelowego nie przechodzi przez oczekiwaną regułę 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 dzienniki są pomocne?oauth_sso_captive.log jest szczególnie istotne w przypadku portalu przechwytującego z Entra ID SSO. Dodatkowo logują się przeglądarki z modułem Authentication, access_server.log oraz, w zależności od późniejszego problemu, pomagają logi sieciowe, firewall lub uwierzytelniające. Podział najważniejszych plików znajdziesz w Rozwiązywanie problemów z zaporą Sophos: usługi i dzienniki.

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.
• Reguły portalu przechwytującego z Entra ID SSO uwzględniają podstawową grupę użytkownika testowego.
• Użytkownik testowy może się zalogować, a następnie kliknąć 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