Konfigurera Microsoft Entra ID SSO för Sophos Connect och VPN Portal

Med Microsoft Entra ID SSO kan Sophos Firewall autentisera användare för VPN Portal samt för Remote Access via Sophos Connect mot Microsoft Entra ID. För många Microsoft 365-miljöer är detta mer fördelaktigt än separata lokala brandväggslösenord, eftersom identitet, Conditional Access och MFA hanteras centralt i Identity Provider.

Fördelen är dock endast verklig om hela kedjan är noggrant planerad: Entra-app, Redirect URIs, VPN Portal, Sophos Connect, autentiseringsmetoder, grupper, Device Access och klientprofiler måste passa ihop. Denna artikel beskriver det praktiska förloppet för VPN Portal, SSL VPN och IPsec Remote Access med Sophos Connect.

För den allmänna Sophos-Connect-konfigurationen, börja med Konfigurera Sophos Connect på Sophos Firewall. Denna artikel kompletterar de identitets- och SSO-specifika stegen.

Versionsval: De befintliga menyvägarna, fältnamnen och tjänstespecifika loggfilerna i denna artikel avser SFOS 22. För SFOS 23.0 används OpenID Connect-avsnittet nedan och de loggar som anges där. App-behörigheter, VPN-policyer, Provisioning, MFA, pilot- och återställningstester ingår fortfarande i samma process; enbart ändringen av serverformuläret ger ingen VPN-åtkomst. Tillgängligheten för SFOS 23-hjälpen innebär inte att något GA-datum kan fastställas.

Vad Entra ID SSO gör på brandväggen

Sophos Firewall integrerar Microsoft Entra ID SSO via OAuth 2.0 och OpenID Connect. Brandväggen använder Entra ID som autentiseringsserver och kan logga in användare för flera tjänster.

För Remote Access är dessa tjänster särskilt relevanta:

• VPN Portal
• SSL VPN via Sophos Connect
• IPsec Remote Access via Sophos Connect

För Captive Portal gäller en annan process: Där loggar en användare redan in i det lokala nätverket via webbläsare så att användarbaserade regler kan tillämpas. Detta fall beskrivs separat i Konfigurera Microsoft Entra ID SSO för Sophos Firewall Captive Portal.

Direkt Microsoft Entra ID SSO omfattar inte alla klassiska brandväggsinloggningar. För User Portal och Client Authentication Agent hänvisar Sophos till Microsoft Entra ID Domain Services. Det är en separat AD- eller LDAP-kompatibel katalogarkitektur, inte ytterligare ett val i OAuth-/OIDC-serverobjektet. Den som behöver User Portal eller CAA får därför inte utgå från att SSO-appen som konfigureras här automatiskt autentiserar dessa tjänster.

Det är viktigt att skilja på rollerna: Brandväggen hanterar fortfarande VPN, policies, användargruppsmatchning och åtkomst via brandväggsregler. Entra ID hanterar identitetsverifiering, SSO och Entra-baserad MFA.

En Entra ID-server, flera tjänster

Microsoft Entra ID-servern skapas en gång på Sophos Firewall under Authentication > Servers. Därefter kan samma serverobjekt väljas under Authentication > Services för olika tjänster, till exempel VPN Portal, SSL VPN, IPsec Remote Access, Captive Portal eller administratörsinloggning.

Det betyder inte att varje tjänst automatiskt fungerar på samma sätt. Varje tjänst behöver rätt Redirect URI, rätt autentiseringsmetod och en egen testväg. För VPN Portal, SSL VPN och IPsec Remote Access är framför allt VPN portal and remote access URL relevant. Om Captive Portal eller WebAdmin också använder Entra ID SSO måste deras service-URL:er också läggas till i Entra-appen och testas separat.

För administratörstjänsten krävs dessutom Entra-roller eller -grupper, lokala behörighetsprofiler och testad nödåtkomst. Det separata arbetsflödet finns i Konfigurera Microsoft Entra ID SSO för Sophos Firewall WebAdmin.

Endast en Microsoft Entra ID-server kan användas per autentiseringsmetod. Vid Sophos Connect Provisioning bör VPN Portal, SSL VPN och IPsec därför medvetet använda samma Entra ID-server, så att gateway-värde, Redirect URI och klientprofil matchar.

När Entra ID SSO är lämpligt

Entra ID SSO passar bra när användare redan arbetar med Microsoft 365 och organisationen använder Conditional Access eller Entra-MFA som central säkerhetskontroll.

Typiska skäl:

• Användare ska inte behöva hantera separata brandväggslösenord.
• MFA ska hanteras via Entra ID istället för Sophos OTP.
• Remote Access ska vara mer kopplat till användarstatus, grupper och Conditional Access.
• Helpdesk och säkerhetsteam ska hantera identitetsprocesser centralt i Entra ID.
• Lokala brandväggsanvändare ska minskas.

Inte alla miljöer bör omedelbart byta. I små installationer utan en tydlig Entra-gruppmodell kan Sophos egen MFA vara enklare. För den klassiska OTP-varianten, se Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access.

Förutsättningar och begränsningar

Innan konfigurationen bör dessa punkter vara uppfyllda:

• Sophos Firewall med en stödd SFOS-version.
• Microsoft Entra Tenant med behörighet att skapa en App Registration.
• Offentlig FQDN för VPN Portal eller Remote Access-åtkomst.
• Giltigt certifikat för det offentliga namnet.
• VPN Portal är tillgänglig via den nödvändiga zonen.
• Sophos Connect 2.4 eller senare på Windows om SSO ska användas i klienten.
• Användare eller grupper finns korrekt i Entra ID.
• Brandvägg och Entra ID har korrekt tid.
• Microsoft-login-URL:er är tillgängliga från klienterna och, beroende på trafikväg, från brandväggen.

Viktiga begränsningar:

• För Sophos Connect SSO nämner Sophos Windows-endpunkter med Sophos Connect 2.4 eller senare.
• När Microsoft Entra ID SSO används, används MFA i Identity Provider. Sophos brandväggens egen MFA kan inte användas för denna autentiseringsmetod.
• Under SFOS 22 kan endast en Microsoft Entra ID-server väljas per autentiseringsmetod. Under SFOS 23 gäller gränsen en OpenID Connect-IdP-server, inte en Entra-server utöver en annan OIDC-leverantör.
• Användare från samma domän bör inte synkroniseras samtidigt via AD och Microsoft Entra ID.
• I HA-kluster bör man för närvarande inte förvänta sig att Microsoft Entra ID SSO fungerar för WebAdmin på Auxiliary Firewall.

⚠️ Conditional Access kräver en korrigerad firmwareversion: I SFOS 21.5 GA Build 171 kunde Sophos Connect återanvända en befintlig SSO-session utan att utvärdera MFA och andra Conditional Access-villkor på nytt. Att koppla från och återansluta VPN-tunneln räckte inte nödvändigtvis. Sophos listar problemet som NC-167126 och anger ingen officiell workaround. Det är korrigerat från SFOS 21.5 MR2 Build 323 respektive SFOS 22.0 MR1 Build 490. I miljöer där Conditional Access används som säkerhetsgräns bör brandväggen först uppgraderas till minst en av dessa versioner. Force SSO re-login minskar risken på äldre system, men ersätter inte korrigeringen.

⚠️ En uppgradering till SFOS 22 kan aktivera SSO automatiskt: Om VPN Portal, IPsec Remote Access eller SSL VPN använde Same as firewall under Authentication > Services före uppgraderingen aktiverar SFOS 22.0 eller senare automatiskt Microsoft Entra ID SSO för dessa tjänster. Dokumentera de effektiva metoderna före uppgraderingen. Om Entra SSO är avsett måste därefter den exakta VPN portal and remote access URL från Entra-serverobjektet registreras i Entra-appen och verifieras med en riktig inloggning. Använd inte Sophos Fusion (tidigare Sophos Central) reverse SSO-URL. Om SSO inte är avsett anges den önskade metoden uttryckligen i stället för att det ärvda läget accepteras utan kontroll.

Planera arkitektur

Innan den tekniska konfigurationen bör man bestämma vilka tjänster som ska använda SSO.

• VPN Portal: Ska inloggning på portalen ske via Entra ID?
• SSL VPN: Ska SSL VPN via Sophos Connect användas med Entra SSO?
• IPsec Remote Access: Ska IPsec Remote Access via Sophos Connect användas med Entra SSO?
• Provisioning-fil: Används en automatisk provisioning-fil?
• Grupper: Vilka Entra-grupper får använda VPN?
• MFA: Vilka Conditional Access- och MFA-regler gäller för Remote Access?
• Fallback: Vad händer om Entra ID eller internetåtkomst till Microsoft inte är tillgänglig?

Om en provisioning-fil används måste det gateway-värde som anges i den matcha FQDN eller IP som används i Microsoft Entra ID-konfigurationen av brandväggen som Redirect URI. Efter ändringar i Entra ID eller brandväggskonfigurationen måste användare importera den uppdaterade konfigurationen igen.

Dokumentera före ändringen Authentication > Services, serverordning, VPN-grupper och -policyer, Device Access och distribuerade profiler. Behåll en lokal administratör oberoende av Entra ID som skyddad, övervakad och separat testad break-glass-åtkomst. Entra-licenserna som Conditional Access kräver måste finnas. SFOS 22: Microsoft 365 Government Community Cloud High (GCC High) stöds inte för denna SSO-integration. SFOS 23-hjälpen anger inte längre denna begränsning; det innebär inte att GCC High-stöd bekräftas här. För en sådan tenant måste stödet klargöras separat före utrullning.

Förbered Entra-appen för brandväggen

Sophos rekommenderar en separat app. Skapa i App registrations > New registration en app med Accounts in this organizational directory only och plattform Web, och kopiera Application (client) ID samt Directory (tenant) ID. Ge under API permissions > Microsoft Graph med Admin Consent de delegerade behörigheterna User.Read.All och Group.Read.All; lägg endast till Group.Read.All som Application permission för SFOS-gruppimport. Skapa ett Client secret, lagra genast dess Value säkert och planera utgång och rotation.

Sätt Assignment required? till Yes under Enterprise application > Properties och tilldela endast pilot-/VPN-gruppen och nödvändiga administratörer. Tilldelningen är första kontrollen; SSL/IPsec-policyn är den andra. Microsoft beskriver tilldelning av användare och grupper och reglerna för Redirect URI. SFOS läser automatiskt attribut från token; välj en Fallback user group utan breda VPN-rättigheter så att en saknad importerad grupp inte ger för stor åtkomst.

Gruppbaserad apptilldelning kräver Microsoft Entra ID P1 eller P2 och omfattar inte användare som endast är medlemmar via en nästlad grupp. Utan den licensen eller vid nästlade grupper tilldelar du pilotanvändarna direkt; annars nekar Entra inloggningen trots att VPN-gruppmedlemskapet kan se korrekt ut.

Skapa Microsoft Entra ID-server på brandväggen

SFOS 23.0: OpenID Connect med Microsoft Entra ID

Under SFOS 23 konfigureras Entra ID som leverantör i det gemensamma OpenID Connect-serverobjektet. Den befintliga Entra-appen behövs fortfarande; skapa inte en andra app enbart för att formuläret har bytt namn. Före en ändring dokumenteras det befintliga serverobjektet, dess tjänsttilldelningar och Redirect URIs. En uppgradering godkänns först efter ett nytt portal- och tunneltest.

1. Öppna Authentication > Servers > Add och välj OpenID Connect under Server type.
2. Ange Server name och välj IdP vendor: Microsoft Entra ID.
3. Ange Entra-appens Application (client) ID under Client ID och dess secret-värde under Client secret.
4. Ange Directory (tenant) ID under OpenID Connect URLs > Issuer URL. För denna leverantör förväntar sig det dokumenterade SFOS-fältet tenant-ID:t; ersätt det inte med en egenkonstruerad Issuer-URL. De övriga URL-inställningarna gäller inte för Microsoft Entra ID.
5. Välj antingen Use firewall URL under Redirect URIs eller ange avsedd brandväggs-FQDN eller IP-adress med Enter manually. Vid hantering av en enskild brandvägg via Sophos Fusion anges värdnamnet manuellt; reverse SSO-URL:en är inte en callback till brandväggen.
6. Öppna Show URLs och registrera den exakta VPN portal and remote access URL som Web-Redirect-URI i Entra-appen. Vid Provisioning måste gateway-värdet matcha den brandväggs-FQDN eller IP som används här. Ändringar kräver att klientkonfigurationen importeras igen.
7. Behåll standardvärdena Display name: name, Username: upn och Email address: email under User attributes. Endast en token som faktiskt har en annan struktur och stöds motiverar avvikande attribut.
8. Låt IdP authentication for firewall administrators vara avstängt för rena VPN-användartjänster och välj en Fallback group med begränsade behörigheter. Administratörsmappning är ett separat steg i WebAdmin-artikeln.
9. Kör Test connection, spara först när testet lyckas och tilldela servern till VPN Portal, SSL VPN och vid behov IPsec under Authentication > Services. Kör Apply för varje tjänst. SSL VPN och VPN Portal använder alltid samma server; med Provisioning gäller detta även IPsec.

Kontrollera även den befintliga anvisningen om Same as firewall efter en uppgradering: Den automatiska aktiveringen för ärvda VPN-metoder gäller SFOS 22.0 och senare, alltså även vid motsvarande versionsbyte till SFOS 23. En dokumenterad servermigrering ersätter varken kontrollen av de effektiva metoderna eller en riktig inloggning med kontroll av Redirect URI, grupper, MFA och tunnel.

SFOS 22: Microsoft Entra ID SSO

Det följande serverformuläret med Directory (tenant) ID, User attribute mapping och Fallback user group hör till SFOS 22. För SFOS 23 används fälten i föregående avsnitt.

Menyvägen är:

Authentication > Servers

Gör så här på brandväggen:

1. Öppna Add.
2. Välj Microsoft Entra ID SSO som Server type.
3. Ge servern ett beskrivande namn.
4. Ange Application (client) ID från Entra-appen.
5. Ange Directory (tenant) ID.
6. Ange Client secret.
7. Kontrollera eller ställ in Redirect-URI-FQDN manuellt.
8. Ange fallback-grupp.
9. Om WebAdmin-SSO behövs, planera roll- eller gruppmappning till administratörsprofiler.
10. Kör Test connection.
11. Spara.

För rena VPN-SSO-scenarier behövs ingen administratörsrollmappning. Då bör servern planeras som en användartjänst, inte som en generell administratörsåtkomst.

⚠️ Client Secrets är produktiva åtkomstdata. Utgångsdatum, rotation, ansvar och dokumentation bör klargöras innan utrullning.

Ställ in autentiseringsmetoder

Efter att ha skapat Microsoft Entra ID-servern måste den tilldelas rätt tjänster under Authentication > Services.

För Remote Access är dessa områden relevanta:

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

Om en provisioning-fil används bör samma Microsoft Entra ID-server användas för VPN Portal, IPsec och SSL VPN. Vid provisioning-filer är samma serverval för autentiseringsmetoder viktigt så att klientprofil, portal och Remote Access-metod passar ihop.

Utan en provisioning-fil måste SSL VPN och VPN Portal fortfarande använda samma Microsoft Entra ID-server; för IPsec Remote Access får då ett annat Entra-serverobjekt användas. Med en provisioning-fil måste däremot VPN Portal, SSL VPN och IPsec peka på samma objekt. Denna skillnad bör dokumenteras medvetet och inte härledas först efter ett tenant-fel i SSO-dialogen.

Efter varje ändring:

1. Välj server i respektive metod.
2. Dra servern till rätt position om flera servrar finns.
3. Kör Apply för varje ändrad tjänst.
4. Använd testanvändare innan ändringen rullas ut brett.

Ange Redirect URIs i Microsoft Entra ID

För att SSO ska fungera måste brandväggs-URL:erna anges som Redirect URIs i Entra-appen.

Gör så här:

1. Öppna Authentication > Servers på brandväggen.
2. Öppna Microsoft Entra ID-servern.
3. Kopiera de nödvändiga URL:erna:
   • Web admin console URL, om WebAdmin-SSO används
   • Captive portal URL, om Captive Portal används
   • VPN portal and remote access URL för VPN Portal, Remote Access IPsec och SSL VPN
4. Gå till Microsoft Entra ID > App registrations i Azure Portal.
5. Öppna applikationen för Sophos Firewall.
6. Under Manage > Authentication lägg till en webbplattform eller redigera den befintliga webbplattformen.
7. Klistra in de kopierade Redirect URIs.
8. Spara.

Ett vanligt fel är ett annat värdnamn i klientprofil, Redirect URI, certifikat och offentlig DNS. Dessa värden bör medvetet jämföras innan utrullning.

Om inte Remote Access utan Captive Portal skyddas, bör dessutom den Captive Portal-specifika processen kontrolleras: Device Access för klientzonen, Captive Portal-autentiseringsmetod, användargrupp och senare brandväggsregelmatchning.

Tillåt VPN Portal via Device Access

Microsoft Entra ID SSO för Remote Access använder VPN Portal-porten för kommunikation med brandväggen. För åtkomst från internet måste VPN Portal därför tillåtas på raden WAN under Administration > Device access. Aktivera andra zoner endast om klienter faktiskt behöver nå portalen därifrån.

Det betyder inte att man bör öppna VPN Portal globalt utan eftertanke. Remote Access är en offentligt tillgänglig attackyta. För produktionsmiljöer bör man dessutom kontrollera:

• giltigt offentligt certifikat
• MFA och Conditional Access i Entra ID
• så snäv land- eller källbegränsning som möjligt, om realistiskt
• loggning och granskning av inloggningsförsök
• tydlig avaktivering av användare som inte längre behövs

Härdningen av lokala brandväggstjänster beskrivs i Device Access och Local Service ACL på Sophos Firewall.

Om många misslyckade inloggningar, distribuerade källor eller Entra-kontolåsningar redan förekommer kombinerar Upptäck och begränsa brute force-attacker mot VPN Portal brandväggsloggarna med Entra-kontroll, säker ACL-begränsning och efterkontroll.

Tillåt Microsoft-login-URL:er

Klienter och berörda brandväggsvägar måste kunna nå Microsoft Entra ID-endpunkter. Detta inkluderar flera Microsoft-login- och CDN-URL:er, till exempel login.microsoftonline.com, login.microsoft.com, *.login.live.com, *.msauth.net och andra Azure-/Microsoft Online-domäner.

I restriktiva miljöer bör man inte upptäcka först vid utrullning att inloggningssidor, JavaScript eller token-endpunkter blockeras. Det är lämpligt att:

• Använd den fullständiga tillåtelselistan för Microsoft Entra-inloggningar för FQDN Hosts och proxyundantag.
• Namnge FQDN Hosts eller FQDN Host Groups korrekt.
• Medvetet ställa in brandväggsregel för DNS och HTTPS.
• Vid direkt Web Proxy dessutom kontrollera Web Exceptions.
• Aktivera loggning tills SSO-inloggningen är stabil.

Med en Direct Web Proxy räcker inte enbart Allow-regeln för FQDN Host Group. Den länkade artikeln om tillåtelselistan innehåller de exakta URL-mönstren och beskriver hur du konfigurerar Web > Exceptions. Begränsa undantaget till de nödvändiga inloggnings- och CDN-mönstren.

Kontrollera grupper och VPN-behörigheter

SSO ger inte automatiskt VPN-åtkomst. Användaren måste också vara tillåten i den lämpliga Remote Access-konfigurationen.

Importera Entra-grupper selektivt

För gruppimport behöver brandväggen Microsoft Graph-behörigheten Group.Read.All som Application permission i Entra-appen samt beviljat Admin Consent. Därefter öppnas Assistant for importing groups på Entra-servern under Authentication > Servers. I stället för att okontrollerat importera alla grupper kan assistenten exempelvis filtrera på Display name eller Description.

Vid importen kan Surfing quota, Access time, Network traffic och Traffic shaping anges för alla eller enskilda grupper. Dessa policies tilldelas endast när gruppen verkligen behöver dem. Tiden på brandväggen och i Microsoft Entra ID måste vara synkroniserad, annars kan redan importen misslyckas.

Om Entra-gruppen finns på brandväggen placerar SFOS användaren i den gruppen. Saknas gruppen används den Fallback user group som konfigurerats på Entra-servern. Det gäller även när Entra-servern används under Firewall authentication methods; inställningen Default group där ersätter inte fallback-gruppen. Efter importen måste den nya gruppen dessutom tillåtas i respektive IPsec- eller SSL VPN-policy.

Att kontrollera:

• Entra-gruppen har importerats till brandväggen eller mappas korrekt.
• Gruppen är vald under Allowed users and groups för Remote Access IPsec.
• Gruppen är vald under Policy members för SSL VPN.
• Brandväggsregler tillåter trafik från VPN-zonen endast till de nödvändiga målen.
• Användaren är inte bara autentiserad utan får också den förväntade policyn.

Om tunneln är ansluten men ingen trafik flödar, är det ofta inte SSO som är orsaken, utan regelverk, routing, DNS eller NAT. För analys passar Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Kontrollera UPN, e-post och gruppmatchning

Vid Microsoft Entra ID SSO bör man noggrant kontrollera användaridentitet och gruppmatchning. En inloggning kan lyckas hos Identity Provider men ändå felaktigt tilldelas på brandväggen om UPN, e-postadress, importerad grupp eller lokal användaridentifiering inte stämmer överens.

Detta är särskilt relevant i miljöer där användare historiskt har olika värden:

• User Principal Name: max.muster@example.com förväntas ofta som det faktiska inloggningsnamnet.
• E-postadress: m.muster@example.com kan avvika och förvirra vid tilldelning eller portalinloggning.
• Visningsnamn: Max Muster är läsbart för människor, men inte lämpligt som teknisk identifiering.
• Grupp: VPN-Users måste importeras till brandväggen och användas i rätt Remote Access-konfiguration.

Vid en migrering från lokalt Active Directory till Entra ID är även inloggningsformatet avgörande. AD använder ofta sAMAccountName@domain, medan Entra ID använder UserPrincipalName@domain. SFOS behandlar olika strängar som separata användarobjekt även om de tillhör samma person. Därför bör formatet harmoniseras före migreringen. Om avsiktligt olika namn används uppstår dubbletter; gamla AD-användare tas bort först efter att regler, grupper, rapportering och den nya Entra-inloggningen har kontrollerats.

Det tidigare kända problemet NC-157635 gjorde att inloggning på SSL VPN- eller IPsec-portalen misslyckades när e-postadress och UPN skilde sig åt. Sophos åtgärdade det i SFOS 21.0 MR2 Build 349, 21.5 MR1 Build 261 och 22.0 EAP0 Build 274. Kontrollen av användarattribut är fortfarande relevant vid problem med enskilda konton, eftersom den kan visa avvikande lokala användarobjekt eller gruppbehörigheter.

Praktisk kontrollprocess:

1. Öppna testanvändare i Microsoft Entra ID.
2. Jämför UPN och e-postadress.
3. Kontrollera om användaren är medlem i den planerade VPN-gruppen.
4. Öppna den importerade gruppen på brandväggen och kontrollera om användaren visas där som förväntat.
5. Under Authentication > Services kontrollera om rätt Microsoft Entra ID-server är vald för VPN Portal, SSL VPN och IPsec.
6. Utför testinloggning och kontrollera Log Viewer samt oauth_sso_vpn.log.

Om endast enskilda användare påverkas är ett attribut- eller gruppproblem mer sannolikt än ett generellt Entra ID-serverfel. Om alla användare påverkas, kontrollera först Tenant ID, Client ID, Client Secret, Redirect URIs, tid och Microsoft-endpunkter.

Vid användarregler efter lyckad VPN-inloggning gäller dessutom: Brandväggsregeln måste se användaren eller gruppen i den faktiska trafiken. Om tunneln är uppe men den planerade användarregeln inte matchar, passar analysen från Sophos Firewall-regel matchar inte: Kontrollera orsaker.

Inför MFA och Conditional Access kontrollerat

Begränsa policyn till brandväggens Enterprise Application och börja med piloter eller Report-only. Testa MFA och varje villkor med ett tillåtet och ett nekat fall i Entra-loggarna. Microsoft rekommenderar att policyer planeras och utvärderas före aktivering.

Behåll minst två separata, övervakade cloud-only Entra-nödkonton som undantas från Conditional Access. De ersätter inte den lokala administratören som är oberoende av internet, Entra och appen, och ska inte VPN-tilldelas enbart för ett bypass-test. Se Manage emergency access accounts.

Testa Sophos Connect och Provisioning

För Sophos Connect gäller: Efter Entra ID-konfigurationen eller efter ändringar i SSO-konfigurationen måste klientkonfigurationen importeras igen.

Testa macOS separat: För Microsoft Entra ID SSO med Sophos Connect 2.1 eller senare på macOS (inte 2.0), följ webbläsarflödet för macOS. auto börjar i den inbyggda webbläsaren och växlar till systemwebbläsaren när de aktuella Conditional Access-kraven kräver det; embedded har ingen automatisk växling. Valet av system via en godkänd .pro-fil beskrivs i provisioneringsschemat, inte genom manuella ändringar i .ovpn eller .scx. Slutför inloggningen, inklusive MFA, i webbläsaren som klienten öppnar, återgå till klienten och kontrollera tunnel, DNS och åtkomst. Att byta webbläsare kringgår inte kraven på enhetsefterlevnad: uppfyll kraven eller kontakta IT, utan att försvaga Conditional Access. Följande Windows-test gäller fortfarande Sophos Connect 2.4 eller senare.

Testprocess:

1. Installera aktuell Sophos Connect Client på Windows.
2. Importera lämplig provisioning- eller VPN-konfiguration.
3. Kontrollera om SSO-alternativet är synligt och klickbart i klienten.
4. Logga in med Entra ID.
5. Utlös MFA eller Conditional Access som planerat och kontrollera resultatet i Entras inloggningsloggar.
6. Kontrollera tunnelstatus.
7. Kontrollera VPN-IP, DNS, interna mål och brandväggsregelmatchning.
8. På en delad enhet, testa en tvingad SSO-återinloggning.

För det sista testet öppnas menyn uppe till höger i Sophos Connect Client, Force SSO re-login väljs och bekräftas med OK. Först därefter måste nästa användare logga in med sina egna Entra-uppgifter. Att bara koppla från tunneln är inte samma sak. På delade Windows-enheter ingår detta steg i ett korrekt användarbyte även med aktuell firmware.

Dokumentera tid, användare, VPN-typ och förväntat resultat för varje test. Applikation, användare, MFA/Conditional-Access-resultat och felkod i Entra måste motsvara oauth_sso_vpn.log eller Authentication-modulen i Log Viewer. Testa före utrullning i den egna miljön: tilldelad pilot och ej tilldelad användare i portalen; varje använt SSL/IPsec-profil med VPN-IP, DNS och endast tillåtna mål; användare utan VPN-grupp; Force SSO re-login på delad enhet; samt lokal break-glass-inloggning via den begränsade hanteringsvägen. Detta är tester att utföra, inte påstådda resultat.

För klientinstallation på Windows, se Installera Sophos Connect Client på Windows. För SSL VPN med Sophos Connect, se dessutom Konfigurera Sophos SSL VPN med Sophos Connect på Windows.

Rollback med bevarat tillstånd

Ta inte bort tidigare autentisering förrän pilot och rollback lyckats; behåll gamla profiler kontrollerat. Vid fel loggar du in med den lokala administratören och återställer under Authentication > Services de dokumenterade servrarna och ordningen för VPN Portal, SSL VPN och IPsec, med Apply för varje tjänst. Importera den gamla profilen på en pilotenhet och kontrollera portal, tunnel, DNS och ett tillåtet internt mål.

Ta först bort Entra-appen, nya servern, importerade grupper och secret när åtkomst och loggar bekräftar återställningen. Om Device Access endast utökades för SSO återställs det därefter, så att den återställda VPN-vägen inte blockeras samtidigt.

Drift och säkerhet

Entra ID SSO flyttar inloggningssäkerheten mer till Identity Provider. Detta är bra om Entra ID hanteras korrekt. Det är problematiskt om grupper, Conditional Access eller App Secrets hanteras slarvigt.

I drift bör dessa punkter regelbundet kontrolleras:

• App Secret löper inte ut oväntat.
• Entra-grupper innehåller endast behöriga användare.
• Conditional Access gäller för Remote Access.
• Break-Glass- och fallback-åtkomster är dokumenterade.
• VPN Portal är endast så brett tillgänglig som nödvändigt.
• Sophos Connect-versioner är aktuella.
• Gamla klientprofiler tas ur bruk efter ändringar.
• Loggar kontrolleras tidigt vid inloggningsproblem.

För klientsidan bör dessutom en egen uppdateringsprocess finnas. Artikeln Kontrollera och säkert uppdatera Sophos Connect Client-version sammanfattar vilka Windows-, macOS-, SSO-, OTP- och provisioning-ämnen som bör kontrolleras innan en utrullning.

Felsökning

SFOS 23.0: För OIDC-inloggningsflödet används /log/oauth_sso_svc.log; fel vid Test connection med x509: certificate signed by unknown authority kontrolleras i /log/sfos-macro-cfg.log. I Log Viewer är modulen Authentication fortfarande relevant för VPN Portal, IPsec och SSL VPN. De följande hänvisningarna till oauth_sso_vpn.log och den tjänstespecifika omstarten hör till SFOS 22.

Efter att en bevisligen ofullständig CA-kedja har korrigerats körs först Test connection igen. Endast om en omstart fortfarande behövs därefter och ett avbrott i de använda OIDC-inloggningstjänsterna är acceptabelt under underhållsfönstret används följande Advanced Shell-kommando, som Sophos dokumenterar för SFOS 23:

service oauth_sso_svc:restart -ds nosync

Kontrollera därefter Test connection, en ny VPN Portal-inloggning och den tunnel som faktiskt används igen. Den gemensamma tjänsten innebär att omstarten inte enbart berör VPN; även andra tjänster som använder detta OIDC-objekt testas separat igen. Ingen omstart ersätter kontroll av DNS, tid, behörigheter eller CA.

SSO-knappen är inte användbar i Sophos Connect Client

Om klienten meddelar att SSO inte är konfigurerat, testa först anslutningen till Microsoft Entra ID-servern på brandväggen. Kontrollera sedan under Authentication > Services om Entra ID-servern är korrekt inställd för SSL VPN respektive IPsec och VPN Portal.

Användaren får inte logga in på VPN Portal

Då kan SSO fungera i grunden, men VPN-behörigheten saknas. Kontrollera om Entra-gruppen är inkluderad i Remote Access IPsec-konfigurationen under Allowed users and groups eller vid SSL VPN under Policy members.

Endast enskilda användare kan inte logga in

Kontrollera då först UPN, e-postadress, gruppmedlemskap och importerad brandväggsgrupp. Särskilt för användare med avvikande e-postadress, ändrade namn eller migrerade konton kan den tekniska identifieringen se annorlunda ut än förväntat.

Microsoft rapporterar felaktig Tenant eller felaktig applikation

Då stämmer ofta inte autentiseringsmetoder, Entra-app, Tenant ID eller servervalet på brandväggen överens. Särskilt vid flera Entra ID-servrar måste man kontrollera om VPN Portal, SSL VPN och IPsec använder samma förväntade server.

Redirect eller inloggning slutar på fel sida

Jämför FQDN, certifikat, offentlig DNS, Redirect URI och Gateway-värde i provisioning-filen. Även små avvikelser i värdnamn, port eller sökväg kan störa OAuth/OIDC-flödet.

Test connection misslyckas med ett x509-fel

Om oauth_sso_vpn.log visar felet x509: certificate signed by unknown authority kan en rot- eller mellanliggande CA saknas i certifikatkedjan till Microsoft Entra ID. Det kända problemet NC-176806 åtgärdades i SFOS 22.0 MR2 Build 546; andra ofullständiga certifikatkedjor eller TLS-fel är fortfarande möjliga.

I Advanced Shell kan kedjan som Microsoft levererar kontrolleras:

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

1. Kontrollera certifikatkedjan och Issuer i utdata.
2. Hämta endast den rot- eller mellanliggande CA som saknas från en betrodd källa. Importera inte ett servercertifikat som CA.
3. Lägg till CA under Certificates > Certificate Authority och tillämpa ändringen.
4. Öppna Entra ID-servern under Authentication > Servers och kör Test connection igen.
5. Starta bara om VPN SSO-tjänsten i Advanced Shell om testet fortfarande misslyckas och ett kort avbrott i pågående VPN SSO-inloggningar är acceptabelt:

service oauth_sso_vpn:restart -ds nosync

Kör sedan Test connection igen. Omstarten av tjänsten är ett valfritt sista steg, inte den första åtgärden vid ett x509-fel.

Gruppimport fungerar inte

Kontrollera brandväggens tid, Tenant-data, app-behörigheter, Client Secret och tillgänglighet för Microsoft-endpunkter. Om befintliga lokala grupper inte matchar Entra-grupper måste man besluta om de ska rensas, mappas eller hanteras manuellt.

Anslutning är uppe, men interna system är inte tillgängliga

Då är autentiseringen troligen inte huvudfelet längre. Kontrollera VPN-IP, DNS, brandväggsregler, NAT, routing och målssystem. I Log Viewer bör det synas vilken regel som träffar trafiken från VPN-zonen.

Checklista

• Entra-app med Client ID, Tenant ID och Client Secret är dokumenterad.
• Redirect URIs för VPN Portal och Remote Access är registrerade i Entra ID.
• Offentlig FQDN, certifikat och provisioning-gateway matchar.
• VPN Portal är medvetet tillåten under Device Access.
• Microsoft-login-URL:er är tillgängliga.
• Authentication Services använder rätt Entra ID-server.
• VPN-grupper är importerade och tillåtna i SSL/IPsec-policies.
• UPN, e-postadress och gruppmedlemskap har kontrollerats med en testanvändare.
• Sophos Connect 2.4 eller senare används på Windows.
• Klientprofiler har importerats på nytt efter ändringar.
• Entra-MFA och Conditional Access har testats med testanvändare.
• oauth_sso_vpn.log, Log Viewer och Access Server-loggar är kända för felsökning.

Vanliga frågor