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.

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.

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.

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.
• Dla każdej metody uwierzytelniania można wybrać tylko jeden serwer Microsoft Entra ID.
• 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.

Planowanie architektury

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

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ę.

Dodawanie serwera Microsoft Entra ID na firewallu

Ś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.

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. Dlatego VPN Portal musi być dozwolony w Administration > Device access dla wymaganej strefy.

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.

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:

• Sprawdzenie listy URL-i Microsoft z aktualnej dokumentacji Sophos i Microsoft.
• 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.

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.

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:

Na liście znanych problemów jest udokumentowany przypadek, w którym użytkownicy Azure AD nie mogą się zalogować do portalu SSL VPN lub IPsec, jeśli adres e-mail i UPN są różne. W praktyce oznacza to: przy problemach z Entra ID SSO należy sprawdzić nie tylko Redirect URI i Client Secret, ale także atrybuty użytkownika.

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.

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.

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.
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.

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.

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 awaryjne i awaryjne 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.

Wraz z SFOS 22 MR1 Sophos poprawił ponowną ocenę polityk Conditional Access przy ponownie używanych sesjach SSO. Dla środowisk, które używają Entra-MFA jako granicy bezpieczeństwa, jest to ważny powód, aby utrzymywać aktualną wersję firewalla.

Rozwiązywanie problemów

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.

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