Konfigurowanie Microsoft Entra ID SSO dla Sophos Connect i VPN Portal

Dzięki Microsoft Entra ID SSO Sophos Firewall może uwierzytelniać użytkowników dla VPN Portal oraz Remote Access za pomocą Sophos Connect w oparciu o Microsoft Entra ID. Dla wielu środowisk Microsoft 365 jest to bardziej sensowne niż oddzielne lokalne hasła firewall, ponieważ tożsamość, Conditional Access i MFA są centralnie zarządzane w Identity Provider.

Jednak korzyść jest realna tylko wtedy, gdy cały łańcuch jest starannie zaplanowany: aplikacja Entra, Redirect URIs, VPN Portal, Sophos Connect, metody uwierzytelniania, grupy, Device Access i profile klientów muszą być zgodne. Ten artykuł opisuje praktyczny przebieg dla VPN Portal, SSL VPN i IPsec Remote Access z Sophos Connect.

Dla ogólnej konfiguracji Sophos Connect najpierw pasuje Konfigurowanie Sophos Connect na Sophos Firewall. Ten artykuł uzupełnia kroki specyficzne dla tożsamości i SSO.

Wybór wersji: Dotychczasowe ścieżki menu, nazwy pól i pliki logów poszczególnych usług w tym artykule dotyczą SFOS 22. Dla SFOS 23.0 należy użyć opisanej poniżej procedury OpenID Connect i wskazanych tam logów. Uprawnienia aplikacji, polityki VPN, provisioning, MFA oraz testy pilotażowe i przywracania dostępu pozostają częścią tego samego procesu; sama zmiana formularza serwera nie daje jeszcze dostępu do VPN. Dostępność pomocy dla SFOS 23 nie stanowi podstawy do określenia terminu GA.

Co robi Entra ID SSO na firewallu

Sophos Firewall integruje Microsoft Entra ID SSO za pomocą OAuth 2.0 i OpenID Connect. Firewall używa Entra ID jako serwera uwierzytelniającego i może logować użytkowników do wielu usług.

Dla Remote Access szczególnie istotne są te usługi:

• VPN Portal
• SSL VPN za pomocą Sophos Connect
• IPsec Remote Access za pomocą Sophos Connect

Dla Captive Portal obowiązuje inny przebieg: tam użytkownik loguje się już w lokalnej sieci przez przeglądarkę, aby mogły działać reguły oparte na użytkownikach. Ten przypadek jest opisany oddzielnie w Konfigurowanie Microsoft Entra ID SSO dla Sophos Firewall Captive Portal.

Bezpośrednie Microsoft Entra ID SSO nie obejmuje każdego klasycznego logowania do firewalla. W przypadku User Portal i Client Authentication Agent Sophos wskazuje Microsoft Entra ID Domain Services. Jest to odrębna architektura katalogowa zgodna z AD lub LDAP, a nie dodatkowy przełącznik w obiekcie serwera OAuth/OIDC. Jeżeli potrzebne są User Portal lub CAA, nie należy więc zakładać, że skonfigurowana tutaj aplikacja SSO automatycznie uwierzytelnia te usługi.

Ważne jest rozgraniczenie: Firewall nadal zarządza VPN, politykami, dopasowaniem grup użytkowników i dostępem przez reguły firewall. Entra ID przejmuje weryfikację tożsamości, SSO i Entra-based MFA.

Jeden serwer Entra ID, wiele usług

Serwer Microsoft Entra ID tworzy się na Sophos Firewall raz, w Authentication > Servers. Następnie ten sam obiekt serwera można wybrać w Authentication > Services dla różnych usług, na przykład VPN Portal, SSL VPN, IPsec Remote Access, Captive Portal albo logowania administratorów.

Nie oznacza to, że każda usługa działa automatycznie tak samo. Każda usługa wymaga odpowiedniego Redirect URI, właściwej metody uwierzytelniania i osobnego testu. Dla VPN Portal, SSL VPN i IPsec Remote Access najważniejszy jest VPN portal and remote access URL. Jeśli Captive Portal albo WebAdmin również używają Entra ID SSO, ich adresy usługowe także muszą zostać dodane w aplikacji Entra i przetestowane osobno.

Dla usługi administracyjnej potrzebne są dodatkowo role lub grupy Entra, lokalne profile uprawnień oraz przetestowany dostęp awaryjny. Oddzielną procedurę opisuje artykuł Konfiguracja Microsoft Entra ID SSO dla WebAdmin Sophos Firewall.

Dla jednej metody uwierzytelniania można użyć tylko jednego serwera Microsoft Entra ID. Przy Sophos Connect Provisioning VPN Portal, SSL VPN i IPsec powinny więc świadomie używać tego samego serwera Entra ID, aby wartość gateway, Redirect URI i profil klienta pasowały do siebie.

Kiedy Entra ID SSO jest sensowne

Entra ID SSO pasuje dobrze, gdy użytkownicy i tak pracują z Microsoft 365, a organizacja używa Conditional Access lub Entra-MFA jako centralnej kontroli bezpieczeństwa.

Typowe powody:

• Użytkownicy nie powinni zarządzać oddzielnymi hasłami firewall.
• MFA powinno działać przez Entra ID zamiast przez Sophos OTP.
• Remote Access powinien być bardziej związany ze statusem użytkownika, grupami i Conditional Access.
• Helpdesk i zespół bezpieczeństwa powinni zarządzać procesami tożsamości centralnie w Entra ID.
• Lokalni użytkownicy firewall powinni być zredukowani.

Nie każde środowisko powinno od razu przejść na nowy system. W małych instalacjach bez czystego modelu grup Entra, własne MFA Sophos może być prostsze. Dla klasycznej wersji OTP pasuje Aktywowanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access.

Wymagania i ograniczenia

Przed konfiguracją powinny być spełnione następujące punkty:

• Sophos Firewall z obsługiwaną wersją SFOS.
• Microsoft Entra Tenant z uprawnieniem do utworzenia rejestracji aplikacji.
• Publiczny FQDN dla VPN Portal lub dostępu Remote Access.
• Ważny certyfikat dla publicznej nazwy.
• VPN Portal jest dostępny z wymaganej strefy.
• Sophos Connect 2.4 lub nowszy na Windows, jeśli SSO ma być używane w kliencie.
• Użytkownicy lub grupy są poprawnie obecne w Entra ID.
• Firewall i Entra ID mają poprawny czas.
• URL-e logowania Microsoft są dostępne z klientów i, w zależności od ścieżki ruchu, z firewalla.

Ważne ograniczenia:

• Dla Sophos Connect SSO Sophos wymienia punkty końcowe Windows z Sophos Connect 2.4 lub nowszym.
• Jeśli używane jest Microsoft Entra ID SSO, MFA jest używane w Identity Provider. Własne MFA Sophos Firewall nie może być dodatkowo używane dla tej metody uwierzytelniania.
• W SFOS 22 dla każdej metody uwierzytelniania można wybrać tylko jeden serwer Microsoft Entra ID. W SFOS 23 ograniczenie dotyczy jednego serwera IdP OpenID Connect, a nie serwera Entra dodanego obok innego dostawcy OIDC.
• Użytkownicy z tej samej domeny nie powinni być jednocześnie synchronizowani przez AD i Microsoft Entra ID.
• W klastrach HA nie należy obecnie zakładać, że Microsoft Entra ID SSO działa dla WebAdmin pomocniczego firewalla.

⚠️ Conditional Access wymaga poprawionej wersji firmware: W SFOS 21.5 GA Build 171 Sophos Connect mógł ponownie użyć istniejącej sesji SSO bez ponownego sprawdzenia MFA i innych warunków Conditional Access. Samo rozłączenie i ponowne połączenie tunelu VPN nie zawsze wystarczało. Sophos oznacza problem jako NC-167126 i nie podaje oficjalnego obejścia. Problem jest naprawiony od SFOS 21.5 MR2 Build 323 lub SFOS 22.0 MR1 Build 490. Jeśli Conditional Access stanowi granicę bezpieczeństwa, najpierw należy zaktualizować system co najmniej do jednej z tych wersji. Force SSO re-login ogranicza ryzyko w starszych systemach, ale nie zastępuje poprawki.

⚠️ Aktualizacja do SFOS 22 może automatycznie włączyć SSO: Jeśli przed aktualizacją VPN Portal, Remote Access IPsec lub SSL VPN korzystały z opcji Same as firewall w Authentication > Services, SFOS 22.0 lub nowszy automatycznie włącza Microsoft Entra ID SSO dla tych usług. Przed aktualizacją należy udokumentować faktycznie używane metody. Jeśli Entra SSO jest zamierzone, trzeba następnie zapisać w aplikacji Entra dokładny adres VPN portal and remote access URL z obiektu serwera Entra i sprawdzić go przez rzeczywiste logowanie. Nie wolno używać adresu reverse SSO z Sophos Fusion (dawniej Sophos Central). Jeśli SSO nie jest zamierzone, należy jawnie ustawić właściwą metodę, zamiast bez sprawdzenia przyjmować odziedziczony stan.

Planowanie architektury

Przed techniczną konfiguracją należy określić, które usługi będą używać SSO.

• VPN Portal: Czy logowanie do portalu ma odbywać się przez Entra ID?
• SSL VPN: Czy SSL VPN ma być używane przez Sophos Connect z Entra SSO?
• IPsec Remote Access: Czy IPsec Remote Access ma być używane przez Sophos Connect z Entra SSO?
• Plik provisioningowy: Czy używany jest automatyczny plik provisioningowy?
• Grupy: Które grupy Entra mogą używać VPN?
• MFA: Jakie zasady Conditional Access i MFA obowiązują dla Remote Access?
• Fallback: Co się stanie, jeśli Entra ID lub dostęp do Internetu do Microsoft nie będzie dostępny?

Jeśli używany jest plik provisioningowy, wartość gateway w nim ustawiona musi pasować do FQDN lub IP, które w konfiguracji Microsoft Entra ID firewalla są używane jako Redirect URI. Po zmianach w Entra ID lub konfiguracji firewalla użytkownicy muszą ponownie zaimportować zaktualizowaną konfigurację.

Przed zmianą udokumentuj Authentication > Services, kolejność serwerów, grupy i polityki VPN, Device Access oraz rozdane profile. Zachowaj lokalnego administratora niezależnego od Entra ID jako chroniony, monitorowany i osobno testowany dostęp break-glass. Muszą być dostępne licencje Entra wymagane przez zasady Conditional Access. SFOS 22: Ta integracja SSO nie obsługuje Microsoft 365 Government Community Cloud High (GCC High). Pomoc dla SFOS 23 nie wymienia już tego ograniczenia; nie oznacza to jednak potwierdzonej obsługi GCC High w tym artykule. Dla takiego tenanta należy osobno potwierdzić obsługę przed wdrożeniem.

Przygotowanie aplikacji Entra dla firewalla

Sophos zaleca osobną aplikację. W App registrations > New registration utwórz aplikację Accounts in this organizational directory only z platformą Web, a następnie skopiuj Application (client) ID i Directory (tenant) ID. W API permissions > Microsoft Graph nadaj z Admin Consent delegowane uprawnienia User.Read.All i Group.Read.All; Group.Read.All jako Application permission dodaj tylko do importu grup SFOS. Utwórz Client secret, natychmiast bezpiecznie zapisz jego Value i zaplanuj wygaśnięcie oraz rotację.

W Enterprise application > Properties ustaw Assignment required? na Yes i przypisz tylko grupę pilotażową/VPN oraz niezbędnych administratorów. To pierwszy próg dostępu, a polityka SSL/IPsec pozostaje drugim. Microsoft opisuje przypisywanie użytkowników i grup oraz reguły Redirect URI. SFOS automatycznie odczytuje atrybuty z tokenu; wybierz Fallback user group bez szerokich praw VPN, aby brak zaimportowanej grupy nie rozszerzał dostępu.

Przypisywanie aplikacji na podstawie grup wymaga Microsoft Entra ID P1 lub P2 i nie obejmuje użytkowników należących wyłącznie przez grupę zagnieżdżoną. Bez tej licencji lub przy grupach zagnieżdżonych przypisz użytkowników pilotażowych bezpośrednio; w przeciwnym razie Entra odrzuci logowanie, choć członkostwo w grupie VPN może wyglądać poprawnie.

Dodawanie serwera Microsoft Entra ID na firewallu

SFOS 23.0: OpenID Connect z Microsoft Entra ID

W SFOS 23 Entra ID konfiguruje się jako dostawcę we wspólnym obiekcie serwera OpenID Connect. Istniejąca aplikacja Entra nadal jest potrzebna; sama zmiana nazwy formularza nie wymaga tworzenia drugiej aplikacji. Przed zmianą należy udokumentować istniejący obiekt serwera, jego przypisania do usług oraz Redirect URIs. Aktualizację można uznać za zweryfikowaną dopiero po ponownym teście portalu i tunelu.

1. Otwórz Authentication > Servers > Add i w Server type wybierz OpenID Connect.
2. Nadaj Server name i wybierz IdP vendor: Microsoft Entra ID.
3. W Client ID wprowadź Application (client) ID aplikacji Entra, a w Client secret wartość jej sekretu.
4. W OpenID Connect URLs > Issuer URL wprowadź Directory (tenant) ID. Dla tego dostawcy udokumentowane pole SFOS oczekuje identyfikatora tenanta; nie należy zastępować go samodzielnie zbudowanym adresem Issuer URL. Pozostałe ustawienia URL nie dotyczą Microsoft Entra ID.
5. W Redirect URIs wybierz Use firewall URL lub za pomocą Enter manually wprowadź docelowy FQDN albo adres IP firewalla. Przy zarządzaniu pojedynczym firewallem przez Sophos Fusion ustaw nazwę hosta ręcznie; adres reverse SSO nie jest adresem callback urządzenia.
6. Otwórz Show URLs i zapisz dokładny VPN portal and remote access URL jako Web Redirect URI w aplikacji Entra. Przy provisioningu wartość gateway musi pasować do używanego tutaj FQDN albo adresu IP firewalla. Zmiany wymagają ponownego importu konfiguracji klienta.
7. W User attributes zachowaj ustawienia domyślne Display name: name, Username: upn i Email address: email. Inne atrybuty są uzasadnione tylko wtedy, gdy token rzeczywiście ma inną, obsługiwaną strukturę.
8. Dla usług przeznaczonych wyłącznie dla użytkowników VPN pozostaw IdP authentication for firewall administrators wyłączone i wybierz Fallback group z ograniczonymi uprawnieniami. Mapowanie administratorów jest osobnym krokiem opisanym w artykule o WebAdmin.
9. Wykonaj Test connection, zapisz dopiero po pomyślnym teście i w Authentication > Services przypisz serwer do VPN Portal, SSL VPN oraz, w razie potrzeby, IPsec. Wykonaj Apply dla każdej usługi. SSL VPN i VPN Portal zawsze używają tego samego serwera; przy provisioningu dotyczy to również IPsec.

Po aktualizacji sprawdź również istniejącą uwagę dotyczącą Same as firewall: automatyczne włączanie SSO dla odziedziczonych metod VPN dotyczy SFOS 22.0 i nowszych, a więc także odpowiedniej aktualizacji do SFOS 23. Udokumentowana migracja serwera nie zastępuje ani sprawdzenia faktycznie używanych metod, ani rzeczywistego logowania z kontrolą przekierowania, grup, MFA i tunelu.

SFOS 22: Microsoft Entra ID SSO

Poniższy formularz serwera z polami Directory (tenant) ID, User attribute mapping i Fallback user group dotyczy SFOS 22. Dla SFOS 23 należy użyć pól z poprzedniej procedury.

Ścieżka menu to:

Authentication > Servers

Procedura na firewallu:

1. Otwórz Add.
2. Wybierz opcję Microsoft Entra ID SSO jako Server type.
3. Nadaj zrozumiałą nazwę serwera.
4. Wprowadź Application (client) ID z aplikacji Entra.
5. Wprowadź Directory (tenant) ID.
6. Wprowadź Client secret.
7. Sprawdź lub ręcznie ustaw FQDN Redirect URI.
8. Ustal grupę awaryjną.
9. Jeśli potrzebne jest WebAdmin-SSO, zaplanuj mapowanie ról lub grup na profile administratora.
10. Wykonaj Test connection.
11. Zapisz.

Dla czystych scenariuszy VPN-SSO nie potrzebujesz mapowania ról administratora. Wtedy serwer powinien być zaplanowany jako usługa użytkownika, a nie jako ogólny dostęp administratora.

⚠️ Client Secrets to produktywne dane dostępowe. Data wygaśnięcia, rotacja, odpowiedzialność i dokumentacja powinny być ustalone przed wdrożeniem.

Ustawianie metod uwierzytelniania

Po dodaniu serwera Microsoft Entra ID musi on być przypisany do odpowiednich usług w Authentication > Services.

Dla Remote Access istotne są te obszary:

• VPN portal authentication methods
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods
• SSL VPN authentication methods

Jeśli używany jest plik provisioningowy, dla VPN Portal, IPsec i SSL VPN powinien być używany ten sam serwer Microsoft Entra ID. W przypadku plików provisioningowych ważny jest ten sam wybór serwera dla metod uwierzytelniania, aby profil klienta, portal i metoda Remote Access były zgodne.

Bez pliku provisioningowego SSL VPN i VPN Portal nadal muszą korzystać z tego samego serwera Microsoft Entra ID; Remote Access IPsec może wtedy używać innego obiektu serwera Entra. Z plikiem provisioningowym VPN Portal, SSL VPN i IPsec muszą natomiast wskazywać ten sam obiekt. Tę różnicę należy świadomie udokumentować, a nie dopiero wywnioskować z błędu tenant w oknie SSO.

Po każdej zmianie:

1. Wybierz serwer w odpowiedniej metodzie.
2. Przeciągnij serwer na właściwą pozycję, jeśli jest więcej serwerów.
3. Wykonaj Apply dla każdej zmienionej usługi.
4. Użyj użytkownika testowego przed szerokim wdrożeniem zmiany.

Wprowadzanie Redirect URIs w Microsoft Entra ID

Aby SSO działało, URL-e firewalla muszą być zapisane w aplikacji Entra jako Redirect URIs.

Procedura:

1. Otwórz Authentication > Servers na firewallu.
2. Otwórz serwer Microsoft Entra ID.
3. Skopiuj potrzebne URL-e:
   • URL konsoli administracyjnej, jeśli używane jest WebAdmin-SSO
   • URL Captive Portal, jeśli używane jest Captive Portal
   • URL VPN Portal i Remote Access dla VPN Portal, Remote Access IPsec i SSL VPN
4. W Azure Portal przejdź do Microsoft Entra ID > App registrations.
5. Otwórz aplikację dla Sophos Firewall.
6. Pod Manage > Authentication dodaj platformę webową lub edytuj istniejącą.
7. Wklej skopiowane Redirect URIs.
8. Zapisz.

Częstym błędem jest inna nazwa hosta w profilu klienta, Redirect URI, certyfikacie i publicznym DNS. Te wartości powinny być świadomie porównane przed wdrożeniem.

Jeśli chronione jest nie Remote Access, ale Captive Portal, należy dodatkowo sprawdzić specyficzny przebieg dla Captive Portal: Device Access dla strefy klienta, metoda uwierzytelniania Captive Portal, grupa użytkowników i późniejsze dopasowanie reguł firewall.

Udostępnianie VPN Portal przez Device Access

Microsoft Entra ID SSO dla Remote Access używa portu VPN Portal do komunikacji z firewallem. Dla dostępu z Internetu zezwól więc na VPN Portal w wierszu WAN w Administration > Device access. Inne strefy włączaj tylko wtedy, gdy klienci rzeczywiście muszą z nich docierać do portalu.

To nie oznacza, że VPN Portal powinien być bezmyślnie otwarty na cały świat. Remote Access to publicznie dostępna powierzchnia ataku. Dla środowisk produkcyjnych należy dodatkowo sprawdzić:

• ważny publiczny certyfikat
• MFA i Conditional Access w Entra ID
• możliwie wąskie ograniczenie krajowe lub źródłowe, jeśli realistyczne
• logowanie i przegląd prób logowania
• jasne wyłączenie niepotrzebnych użytkowników

Wzmocnienie lokalnych usług firewall jest opisane w Device Access i Local Service ACL na Sophos Firewall.

Jeśli występuje już wiele nieudanych logowań, rozproszonych źródeł lub blokad kont Entra, artykuł Wykrywanie i ograniczanie ataków brute force na VPN Portal łączy logi firewalla ze sprawdzaniem Entra, bezpiecznym ograniczeniem ACL i kontrolą końcową.

Zezwalanie na URL-e logowania Microsoft

Klienci i dotknięte ścieżki firewall muszą mieć dostęp do punktów końcowych Microsoft Entra ID. Obejmuje to kilka URL-i logowania Microsoft i CDN, na przykład login.microsoftonline.com, login.microsoft.com, *.login.live.com, *.msauth.net i inne domeny Azure/Microsoft Online.

W restrykcyjnych środowiskach nie należy odkrywać dopiero przy wdrożeniu, że strony logowania, JavaScript lub punkty końcowe tokenów są blokowane. Sensowne jest:

• Użycie pełnej listy dozwolonych adresów logowania Microsoft Entra dla hostów FQDN i wyjątków proxy.
• Nazwanie FQDN Hosts lub FQDN Host Groups poprawnie.
• Świadome ustawienie reguły firewall dla DNS i HTTPS.
• Przy bezpośrednim Web Proxy dodatkowo sprawdzenie wyjątków webowych.
• Aktywowanie logowania, aż logowanie SSO będzie stabilne.

W przypadku Direct Web Proxy sama reguła Allow do FQDN Host Group nie wystarcza. W podlinkowanym artykule dotyczącym listy dozwolonych adresów znajdują się dokładne wzorce URL oraz instrukcja konfiguracji Web > Exceptions. Ogranicz wyjątek do wymaganych wzorców logowania i CDN.

Sprawdzanie grup i uprawnień VPN

SSO samo w sobie nie daje jeszcze dostępu do VPN. Użytkownik musi być również dozwolony w odpowiedniej konfiguracji Remote Access.

Selektywny import grup Entra

Do importu grup aplikacja firewalla potrzebuje uprawnienia Microsoft Graph Group.Read.All jako Application permission oraz udzielonej zgody Admin Consent. Następnie w Authentication > Servers otwiera się Assistant for importing groups dla serwera Entra. Zamiast importować wszystkie grupy bez kontroli, asystent może filtrować na przykład według Display name lub Description.

Podczas importu można przypisać Surfing quota, Access time, Network traffic i Traffic shaping wszystkim lub wybranym grupom. Polityki te przypisuje się tylko wtedy, gdy grupa rzeczywiście ich potrzebuje. Czas na firewallu i w Microsoft Entra ID musi być zsynchronizowany, w przeciwnym razie sam import może się nie powieść.

Jeśli grupa Entra istnieje na firewallu, SFOS przypisuje do niej użytkownika. Jeśli jej nie ma, obowiązuje skonfigurowana na serwerze Entra Fallback user group. Dotyczy to również sytuacji, gdy serwer Entra jest używany w Firewall authentication methods; znajdująca się tam Default group nie zastępuje grupy rezerwowej. Po imporcie nową grupę należy dodatkowo dopuścić w odpowiedniej polityce IPsec lub SSL VPN.

Do sprawdzenia:

• Grupa Entra została zaimportowana do firewalla lub jest poprawnie mapowana.
• Grupa jest wybrana w Remote Access IPsec pod Allowed users and groups.
• Grupa jest wybrana w SSL VPN pod Policy members.
• Reguły firewall pozwalają na ruch z VPN-zone tylko do potrzebnych celów.
• Użytkownik nie tylko jest uwierzytelniony, ale również otrzymuje oczekiwaną politykę.

Jeśli tunel jest połączony, ale nie ma ruchu, często przyczyną nie jest SSO, ale reguły, routing, DNS lub NAT. Do analizy pasuje Testowanie reguł firewall za pomocą Log Viewer, Policy Test i Packet Capture.

Sprawdzanie UPN, e-mail i dopasowania grup

Przy Microsoft Entra ID SSO należy szczególnie dokładnie sprawdzić tożsamość użytkownika i dopasowanie grup. Logowanie może być pomyślne w Identity Provider, ale na firewallu może być źle przypisane, jeśli UPN, adres e-mail, zaimportowana grupa lub lokalna identyfikacja użytkownika nie pasują.

Jest to szczególnie istotne w środowiskach, w których użytkownicy mają historycznie różne wartości:

• User Principal Name: max.muster@example.com jest często oczekiwany jako właściwa nazwa logowania.
• Adres e-mail: m.muster@example.com może się różnić i wprowadzać zamieszanie przy przypisaniu lub logowaniu do portalu.
• Nazwa wyświetlana: Max Muster jest czytelna dla ludzi, ale nie nadaje się jako techniczna identyfikacja.
• Grupa: VPN-Users musi być zaimportowana na firewall i używana w odpowiedniej konfiguracji Remote Access.

Format logowania ma również znaczenie podczas migracji z lokalnego Active Directory do Entra ID. AD często używa sAMAccountName@domain, natomiast Entra ID używa UserPrincipalName@domain. SFOS traktuje różne ciągi jako odrębne obiekty użytkowników, nawet gdy należą do tej samej osoby. Jeśli to możliwe, format należy ujednolicić przed migracją. Gdy świadomie stosuje się różne nazwy, powstają duplikaty; starych użytkowników AD nie usuwa się przed sprawdzeniem reguł, grup, raportowania i nowego logowania Entra.

Wcześniejszy znany problem NC-157635 powodował nieudane logowanie do portalu SSL VPN lub IPsec, gdy adres e-mail i UPN były różne. Sophos usunął go w SFOS 21.0 MR2 Build 349, 21.5 MR1 Build 261 i 22.0 EAP0 Build 274. Sprawdzanie atrybutów użytkownika nadal ma sens przy problemach dotyczących pojedynczych kont, ponieważ pozwala wykryć rozbieżne lokalne obiekty użytkowników lub uprawnienia grup.

Praktyczny przebieg sprawdzania:

1. Otwórz użytkownika testowego w Microsoft Entra ID.
2. Porównaj UPN i adres e-mail.
3. Sprawdź, czy użytkownik jest członkiem planowanej grupy VPN.
4. Na firewallu otwórz zaimportowaną grupę i sprawdź, czy użytkownik pojawia się tam zgodnie z oczekiwaniami.
5. Pod Authentication > Services sprawdź, czy wybrany jest właściwy serwer Microsoft Entra ID dla VPN Portal, SSL VPN i IPsec.
6. Wykonaj testowe logowanie i sprawdź Log Viewer oraz oauth_sso_vpn.log.

Jeśli dotyczy to tylko pojedynczych użytkowników, bardziej prawdopodobne jest, że problem dotyczy atrybutów lub grup, niż ogólny błąd serwera Entra ID. Jeśli dotyczy to wszystkich użytkowników, najpierw sprawdź Tenant ID, Client ID, Client Secret, Redirect URIs, czas i punkty końcowe Microsoft.

Przy regułach użytkownika po pomyślnym logowaniu VPN dodatkowo obowiązuje: reguła firewall musi widzieć użytkownika lub grupę w rzeczywistym ruchu. Jeśli tunel jest aktywny, ale planowana reguła użytkownika nie pasuje, pasuje analiza z Reguła Sophos Firewall nie działa: sprawdzanie przyczyn.

Kontrolowane wdrażanie MFA i Conditional Access

Ogranicz zasadę do Enterprise Application firewalla i zacznij od pilotów lub trybu Report-only. Sprawdź MFA i każdy warunek przypadkiem dozwolonym i odrzuconym w logach Entra. Microsoft zaleca planowanie i ocenę zasad przed wymuszeniem.

Utrzymuj co najmniej dwa oddzielne, monitorowane konta awaryjne Entra typu cloud-only, wyłączone z Conditional Access. Nie zastępują lokalnego administratora niezależnego od Internetu, Entra i aplikacji ani nie powinny być przypisywane do VPN tylko do testu obejścia. Zobacz Manage emergency access accounts.

Testowanie Sophos Connect i provisioning

Dla Sophos Connect obowiązuje: po konfiguracji Entra ID lub po zmianach w konfiguracji SSO należy ponownie zaimportować konfigurację klienta.

Testuj macOS osobno: Dla Microsoft Entra ID SSO z Sophos Connect 2.1 lub nowszym na macOS (nie 2.0) zastosuj procedurę logowania w przeglądarce na macOS. auto zaczyna w przeglądarce wbudowanej i przełącza się na przeglądarkę systemową, gdy wymagają tego odpowiednie warunki Conditional Access; embedded nie zapewnia automatycznego przełączenia. Wybór system poprzez zatwierdzony plik .pro opisuje schemat provisioningu, a nie ręczne zmiany w .ovpn lub .scx. Dokończ logowanie wraz z MFA w przeglądarce otwartej przez klienta, wróć do klienta i sprawdź tunel, DNS oraz dostęp. Zmiana przeglądarki nie omija wymagań zgodności urządzenia: spełnij je lub skontaktuj się z IT, nie osłabiając Conditional Access. Poniższy test Windows nadal dotyczy Sophos Connect 2.4 lub nowszego.

Przebieg testu:

1. Zainstaluj aktualny klient Sophos Connect na Windows.
2. Zaimportuj odpowiednią konfigurację provisioningową lub VPN.
3. Sprawdź, czy opcja SSO jest widoczna i możliwa do kliknięcia w kliencie.
4. Zaloguj się za pomocą Entra ID.
5. Wywołaj MFA lub Conditional Access zgodnie z planem i sprawdź wynik w logach logowania Entra.
6. Sprawdź status tunelu.
7. Sprawdź VPN-IP, DNS, wewnętrzne cele i dopasowanie reguł firewall.
8. Na współdzielonym urządzeniu przetestuj wymuszone ponowne logowanie SSO.

W ostatnim teście otwórz menu w prawym górnym rogu klienta Sophos Connect, wybierz Force SSO re-login i potwierdź przyciskiem OK. Dopiero wtedy następny użytkownik musi zalogować się własnymi danymi Entra. Zwykłe rozłączenie tunelu nie jest tym samym. Na współdzielonych urządzeniach Windows ten krok jest częścią prawidłowej zmiany użytkownika także przy aktualnym firmware.

Dla każdego testu zapisz czas, użytkownika, typ VPN i oczekiwany wynik. Aplikacja, użytkownik, wynik MFA/Conditional Access i kod błędu w Entra muszą odpowiadać oauth_sso_vpn.log lub modułowi Authentication w Log Viewer. Przed wdrożeniem sprawdź we własnym środowisku: przypisanego pilota i nieprzypisanego użytkownika w portalu; każdy używany profil SSL/IPsec z adresem VPN, DNS i tylko dozwolonymi celami; użytkownika bez grupy VPN; Force SSO re-login na współdzielonym urządzeniu; oraz lokalne logowanie break-glass ograniczoną ścieżką. To plan testów, nie deklaracja wykonania.

Dla instalacji klienta na Windows pasuje Instalowanie klienta Sophos Connect na Windows. Dla SSL VPN z Sophos Connect pasuje dodatkowo Konfigurowanie Sophos SSL VPN z Sophos Connect na Windows.

Rollback z zachowaniem stanu

Nie usuwaj poprzedniego uwierzytelniania przed udanym pilotem i rollbackiem; zachowaj stare profile pod kontrolą. W razie problemu zaloguj się lokalnym administratorem i przywróć w Authentication > Services zapisane serwery oraz kolejność dla VPN Portal, SSL VPN i IPsec, wybierając Apply dla każdej usługi. Na urządzeniu pilotażowym zaimportuj stary profil i sprawdź portal, tunel, DNS oraz dozwolony cel wewnętrzny.

Aplikację Entra, nowy serwer, importowane grupy i secret usuń dopiero po potwierdzeniu odzyskania dostępu w logach. Jeśli Device Access rozszerzono wyłącznie dla SSO, przywróć go później, aby jednocześnie nie zablokować odzyskanej ścieżki VPN.

Eksploatacja i bezpieczeństwo

Entra ID SSO przenosi bezpieczeństwo logowania bardziej do Identity Provider. To dobrze, jeśli Entra ID jest poprawnie zarządzane. Jest to problematyczne, jeśli grupy, Conditional Access lub App Secrets są zarządzane pobieżnie.

W eksploatacji należy regularnie sprawdzać te punkty:

• App Secret nie wygasa nieoczekiwanie.
• Grupy Entra zawierają tylko uprawnionych użytkowników.
• Conditional Access obowiązuje dla Remote Access.
• Dostępy typu break-glass i dostęp rezerwowy są udokumentowane.
• VPN Portal jest dostępny tylko tak szeroko, jak to konieczne.
• Wersje Sophos Connect są aktualne.
• Stare profile klientów są usuwane po zmianach.
• Logi są wcześnie sprawdzane przy problemach z logowaniem.

Dla strony klienta powinien dodatkowo istnieć własny proces aktualizacji. Artykuł Sprawdzanie wersji klienta Sophos Connect i bezpieczne aktualizowanie podsumowuje, jakie tematy dotyczące Windows, macOS, SSO, OTP i provisioning powinny być sprawdzone przed wdrożeniem.

Rozwiązywanie problemów

SFOS 23.0: Dla przepływu logowania OIDC używa się /log/oauth_sso_svc.log; błędy Test connection z komunikatem x509: certificate signed by unknown authority sprawdza się w /log/sfos-macro-cfg.log. W Log Viewer dla VPN Portal, IPsec i SSL VPN nadal istotny jest moduł Authentication. Poniższe odwołania do oauth_sso_vpn.log i ponowne uruchomienie usługi specyficznej dla VPN dotyczą SFOS 22.

Po poprawieniu potwierdzonego niekompletnego łańcucha CA należy najpierw ponownie wykonać Test connection. Tylko jeśli ponowne uruchomienie nadal jest potrzebne i przerwa w używanych usługach logowania OIDC jest akceptowalna w oknie serwisowym, należy użyć udokumentowanego przez Sophos dla SFOS 23 polecenia Advanced Shell:

service oauth_sso_svc:restart -ds nosync

Następnie ponownie sprawdź Test connection, nowe logowanie do VPN Portal i faktycznie używany tunel. Jest to wspólna usługa, więc jej ponowne uruchomienie nie dotyczy wyłącznie VPN; inne usługi korzystające z tego obiektu OIDC również należy osobno przetestować ponownie. Żadne ponowne uruchomienie nie zastępuje sprawdzenia DNS, czasu, uprawnień ani CA.

Przycisk SSO nie jest dostępny w kliencie Sophos Connect

Jeśli klient zgłasza, że SSO nie jest skonfigurowane, najpierw przetestuj połączenie z serwerem Microsoft Entra ID na firewallu. Następnie pod Authentication > Services sprawdź, czy serwer Entra ID jest poprawnie ustawiony dla SSL VPN lub IPsec i VPN Portal.

Użytkownik nie może się zalogować do VPN Portal

Wtedy SSO może działać zasadniczo, ale brakuje uprawnień VPN. Sprawdź, czy grupa Entra jest zawarta w konfiguracji Remote Access IPsec pod Allowed users and groups lub w SSL VPN pod Policy members.

Tylko pojedynczy użytkownicy nie mogą się zalogować

Wtedy najpierw sprawdź UPN, adres e-mail, członkostwo w grupie i zaimportowaną grupę firewall. Szczególnie w przypadku użytkowników z różnym adresem e-mail, zmienionymi nazwami lub migrowanymi kontami techniczna identyfikacja może wyglądać inaczej niż oczekiwano.

Microsoft zgłasza błędny Tenant lub błędną aplikację

Wtedy często metody uwierzytelniania, aplikacja Entra, Tenant ID lub wybór serwera na firewallu nie są zgodne. Szczególnie przy wielu serwerach Entra ID należy sprawdzić, czy VPN Portal, SSL VPN i IPsec używają tego samego oczekiwanego serwera.

Przekierowanie lub logowanie kończy się na stronie błędu

Porównaj FQDN, certyfikat, publiczny DNS, Redirect URI i wartość gateway pliku provisioningowego. Nawet małe różnice w nazwie hosta, porcie lub ścieżce mogą zakłócić przepływ OAuth/OIDC.

Test connection kończy się błędem x509

Jeśli w oauth_sso_vpn.log pojawia się błąd x509: certificate signed by unknown authority, w łańcuchu certyfikatów do Microsoft Entra ID może brakować głównego lub pośredniego urzędu certyfikacji. Znany problem NC-176806 usunięto w SFOS 22.0 MR2 Build 546; inne niekompletne łańcuchy certyfikatów lub błędy TLS są nadal możliwe.

W Advanced Shell można sprawdzić łańcuch dostarczany przez Microsoft:

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

1. Sprawdź łańcuch certyfikatów i Issuer w danych wyjściowych.
2. Brakujący główny lub pośredni certyfikat CA pobierz wyłącznie z zaufanego źródła. Nie importuj certyfikatu serwera jako CA.
3. Dodaj CA w Certificates > Certificate Authority i zastosuj zmianę.
4. W Authentication > Servers otwórz serwer Entra ID i ponownie wykonaj Test connection.
5. Tylko jeśli test nadal się nie powiedzie i krótka przerwa w bieżących logowaniach VPN SSO jest akceptowalna, uruchom ponownie usługę VPN SSO w Advanced Shell:

service oauth_sso_vpn:restart -ds nosync

Następnie ponownie wykonaj Test connection. Ponowne uruchomienie usługi jest opcjonalnym ostatnim krokiem, a nie pierwszym działaniem przy błędzie x509.

Import grup nie działa

Sprawdź czas firewalla, dane Tenant, uprawnienia aplikacji, Client Secret i dostępność punktów końcowych Microsoft. Jeśli istniejące lokalne grupy nie pasują do grup Entra, należy zdecydować, czy je uporządkować, zmapować czy zarządzać ręcznie.

Połączenie jest aktywne, ale wewnętrzne systemy są niedostępne

Wtedy uwierzytelnianie prawdopodobnie nie jest już głównym błędem. Sprawdź VPN-IP, DNS, reguły firewall, NAT, routing i system docelowy. W Log Viewer powinno być widoczne, która reguła trafia w ruch z VPN-zone.

Lista kontrolna

• Aplikacja Entra z Client ID, Tenant ID i Client Secret jest udokumentowana.
• Redirect URIs dla VPN Portal i Remote Access są zapisane w Entra ID.
• Publiczny FQDN, certyfikat i gateway provisioningowy pasują do siebie.
• VPN Portal jest świadomie dozwolony w Device Access.
• URL-e logowania Microsoft są dostępne.
• Usługi uwierzytelniania używają właściwego serwera Entra ID.
• Grupy VPN są zaimportowane i dozwolone w politykach SSL/IPsec.
• UPN, adres e-mail i członkostwo w grupie zostały sprawdzone z użytkownikiem testowym.
• Sophos Connect 2.4 lub nowszy jest używany na Windows.
• Profile klientów zostały ponownie zaimportowane po zmianach.
• Entra-MFA i Conditional Access zostały sprawdzone z użytkownikiem testowym.
• oauth_sso_vpn.log, Log Viewer i logi serwera dostępu są znane do rozwiązywania problemów.

Często zadawane pytania