Konfigurera Microsoft Entra ID SSO för Sophos Firewall Captive Portal

Med Microsoft Entra ID SSO för Captive Portal kan Sophos Firewall autentisera användare mot Microsoft Entra ID via webbläsaren innan användarbaserade brandväggsregler träder i kraft. Detta är särskilt intressant för BYOD-nätverk, gäst- eller partnerzoner, enheter utan transparent AD-detektion eller miljöer där STAS inte passar alla klienter.

Det är viktigt att skilja på funktionerna: Captive Portal är varken VPN Portal eller Remote Access. Användaren finns redan i det lokala nätverket eller Wi-Fi-nätet och loggar in i webbläsaren så att brandväggen kan koppla efterföljande trafik till en användaridentitet. För fjärråtkomst med Sophos Connect passar den separata artikeln Konfigurera Microsoft Entra ID SSO för Sophos Connect och VPN Portal.

Om Microsoft Entra ID SSO redan är konfigurerat för VPN Portal eller Sophos Connect krävs inte automatiskt en helt ny Entra-design. I många fall kan samma Microsoft Entra ID-serverobjekt på brandväggen återanvändas. Captive Portal behöver ändå korrekt Captive portal URL som Redirect URI, tilldelning under Authentication > Services och ett separat test av den senare användarregeln.

När Captive Portal med Entra ID SSO är vettigt

Captive portal med Entra ID SSO är vettigt om användare loggar in med Microsoft 365 ändå och brandväggen behöver en användaridentitet för vissa nätverk.

Typiska tillämpningar:

• BYOD eller WiFi-nätverk utan domänanslutning.
• Gäster eller externa användare med kontrollerad tillgång till ett fåtal destinationer.
• Användarbaserade internetregler utan STAS eller SATC.
• Nätverk där transparent autentisering är opålitlig.
• Övergångsscenarier där lokal AD-autentisering bör minskas.

För fullt hanterade Windows-klienter i en klassisk domän är Captive Portal inte automatiskt den bästa lösningen. Där kan STAS, AD SSO eller andra transparenta procedurer vara mer ergonomiska eftersom användare inte aktivt behöver utlösa en webbläsarinloggning. Captive portal är mer en reserv- eller speciallösning för ohanterade enheter.

Separat captive-portal, VPN-portal och användarportal

Med Entra ID SSO blandas portaltermer snabbt ihop. Separation är avgörande för konfigurationen.

• Captive Portal: Användare i det lokala nätverket loggar in via en webbläsare så att regler med användaridentitet tillämpas. Entra ID SSO används här för webbläsarinloggning och användarmappning.
• VPN-portal: Användare med fjärråtkomst hämtar Sophos Connect eller VPN-konfigurationer. Entra ID SSO är här relevant för fjärråtkomst och portalinloggning.
• Användarportal: Den här portalen innehåller användarfunktioner som OTP eller äldre personliga alternativ. Beroende på miljön är den fortfarande relevant för tokens eller användaralternativ.

En allmän portalöversikt finns i Sophos-portaler: SophosID, Central, Support och brandväggsåtkomst. För Captive Portal måste man framför allt kontrollera från vilken källzon den lokala brandväggstjänsten kan nås och vilken brandväggsregel som sedan behandlar den faktiska användartrafiken. Den klassiska konfigurationen utan den Microsoft-specifika processen förklaras i Konfigurera och testa Sophos Firewall Captive Portal, från Device Access och DNS till användarregeln och Live users. För Entra ID SSO tillkommer därefter appregistrering, Redirect URI och OAuth/OIDC-kontrollerna i den här artikeln.

Krav

Innan du installerar bör dessa punkter förtydligas:

• Sophos Firewall med en SFOS-version som stöder Microsoft Entra ID SSO.
• En kommersiell Microsoft Entra-klientorganisation. Sophos Firewall stöder inte denna SSO-integration för Microsoft 365 GCC High-klientorganisationer.
• Microsoft Entra Tenant med tillstånd för appregistrering, omdirigering av URI:er, API-behörigheter, administratörssamtycke och klienthemlighet.
• FQDN och certifikat för captive-portalen så att användare inte ser onödiga webbläsarvarningar.
• Tillgänglighet för Microsofts inloggningsslutpunkter från det berörda klientnätverket.
• Captive Portal är tillåten under Administration > Device access för rätt zon.
• Användare eller grupper underhålls rent i Microsoft Entra ID.
• Brandväggsregler använder de förväntade användarna eller grupperna.
• En testanvändare och reservåtkomst är tillgängliga.
• Tid och NTP på brandvägg och klienter är korrekta eftersom OAuth/OIDC är tidsberoende.
• Om Uppdrag krävs är aktivt i Microsoft Entra ID, tilldelas de nödvändiga användarna eller grupperna till Enterprise Application.

⚠️ Captive portal är ett inloggningsområde på brandväggen. Den ska bara vara tillgänglig i de zoner där den verkligen behövs. Device Access och Local Service ACL är säkerhetskontroller här, inte bara anslutningsinställningar.

För härdning av lokala brandväggstjänster passar Säkra åtkomst till Sophos Firewall: Konfigurera enhetsåtkomst korrekt. I denna design implementeras MFA i Microsoft Entra ID, till exempel via Conditional Access. Sophos Firewalls lokala MFA ersätter inte Microsofts inloggningsfaktor med Entra ID SSO. Detta är vanligtvis bättre ur användarens perspektiv eftersom samma MFA används som Microsoft 365, men det måste noggrant planeras och testas hos hyresgästen.

Planera arkitektur före konfigurering

Före den tekniska konfigurationen bör du bestämma vilken captive-portal för uppgift som specifikt ska lösa. Annars får du snabbt en inloggning som fungerar men som inte utlöser en lämplig brandväggsregel.

Viktiga designfrågor:

• Vilken zon använder Captive Portal?: Enhetsåtkomst och regelkälla beror på zonen.
• Vilken användargrupp får logga in?: Entra-gruppen måste matcha den senare brandväggsregeln.
• Vilka mål kan uppnås efter inloggning?: Captive portal ersätter inte ren segmentering.
• Hur länge ska sessionerna vara giltiga?: Sessioner som är för långa späder på användartilldelning och sessioner som är för korta stör driften.
• Vad händer vid en Entra- eller Internetstörning?: Det måste finnas en tydlig reserv för kritiska jobb.
• Hur utlöses inloggningen?: Användare behöver en tillgänglig webbadress för captiveportal eller en ren omdirigering.

Captive Portal ska inte användas som en ersättning för VLAN, zoner eller minimala brandväggsregler. Brandväggen känner användaren bättre efter inloggning, men nätverksarkitekturen måste fortfarande vara ren. Konfigurera Sophos Firewall-zoner och gränssnitt är lämplig för den grundläggande logiken i zoner.

Skapa Microsoft Entra ID-server

Installationen består av två delar: Först förbereds en appregistrering i Microsoft Entra ID. Denna app registreras sedan som en autentiseringsserver på Sophos brandvägg.

Förbered appregistrering i Microsoft Entra ID

En separat appregistrering för brandväggen ska skapas i Microsoft Entra ID. Detta innebär att omdirigerings-URI:er, behörigheter och klienthemligheter förblir rent separerade från andra applikationer.

Typisk process:

1. Öppna Microsoft Entra admin center.
2. Öppna Appregistreringar > Ny registrering.
3. Ge ett tydligt namn, till exempel Sophos-Firewall-SSO.
4. Välj som regel din egen hyresgäst som den kontotyp som stöds.
5. Använd plattformen webb.
6. Notera Applikations- (klient) ID och Katalog (hyresgäst) ID.
7. Skapa en klienthemlighet under Certifikat & hemligheter och spara omedelbart det hemliga värdet säkert.
8. Lägg till User.Read.All och Group.Read.All under API permissions > Microsoft Graph > Delegated permissions.
9. Lägg endast till Group.Read.All under Application permissions om grupper ska importeras med brandväggens assistent.
10. Kör Grant admin consent för dessa behörigheter.
11. Sätt helst Assignment required? till Yes under Enterprise applications > [brandväggsappen] > Properties och tilldela därefter endast tillåtna användare eller grupper.

Utan rätt API-behörigheter och administratörssamtycke kan brandväggen inte behandla användare eller grupper korrekt efter Microsoft-inloggningen. Om Assignment required? lämnas på No kan alla användare i klientorganisationen försöka logga in till brandväggens användartjänster; faktisk åtkomst styrs fortfarande av grupper, policies och brandväggsregler. Obligatorisk apptilldelning minskar alltså inloggningsytan men ersätter inte restriktiv auktorisering i brandväggen.

Enligt Microsoft kräver gruppbaserad tilldelning Entra ID P1 eller P2 och omfattar inte nästlade grupper. Testa därför med en direkt gruppmedlem och inte bara med en användare i en undergrupp.

Skapa eller återanvänd Entra ID-server på Sophos Firewall

Microsoft dokumenterar App Registration, Redirect URIs, apptilldelningar och Conditional Access separat. Använd dessa primärkällor om etiketter eller krav för klientorganisationen ändras i Entra-portalen.

Rikta Conditional Access mot Enterprise Application och utvärdera först policyn i Report-only-läge med en pilotanvändare. Kontrollera resultatet med What If och Entras inloggningsloggar före aktivering och undanta dokumenterade konton för nödåtkomst. Håll en befintlig administratörssession i brandväggen öppen och den tidigare autentiseringsvägen tillgänglig tills en tillåten användare, en nekad användare och MFA har testats med lyckat resultat; då orsakar en felaktig policy ingen utlåsning.

Menysökvägen på Sophos Firewall är:

Authentication > Servers

Grundläggande process:

1. Öppna Add.
2. Välj Microsoft Entra ID SSO som Server type.
3. Tilldela ett beskrivande namn, till exempel Entra-SSO-Firewall.
4. Ange Application (client) ID från Entra-appen.
5. Ange Directory (tenant) ID.
6. Ange Client secret.
7. Ställ in Fallback user group medvetet och håll den så restriktiv som möjligt.
8. Kör Test connection.
9. Spara.

Fallback-gruppen används när en användares Entra-grupp inte finns i brandväggen. Den ska inte få bred åtkomst och är varken nödåtkomst eller alternativ autentisering under ett Entra-avbrott.

Ange produktionsmiljöns FQDN eller IP-adress under Redirect URI. Brandväggen skapar då tjänst-URL:erna som ska kopieras oförändrade till Entra ID. Test connection kontrollerar nätverksanslutning, Application permissions och validering av TLS-certifikat.

⚠️ Client secrets är produktiva åtkomstuppgifter. Utgångsdatum, rotation och ansvar bör dokumenteras. En utgången secret ser ofta ut som ett vanligt inloggningsproblem ur användarens perspektiv, men är egentligen ett konfigurations- eller driftproblem.

För en rotation med så lite avbrott som möjligt skapar du en ny secret före utgångsdatumet, anger dess Value i brandväggen och kör Test connection följt av en Captive Portal-inloggning. Behåll föregående secret giltig som återställningsväg tills båda testerna lyckas och ta först därefter bort den i Entra ID. Lägg aldrig secretvärden i skärmbilder, ärenden eller konfigurationsexporter.

Ange omdirigerings-URI:er korrekt

Kopiera den omdirigerings-URI som brandväggen skapar oförändrad till App Registration i Microsoft Entra ID. Protokoll, värdnamn, port, sökväg och även ett avvikande avslutande snedstreck måste stämma exakt. Portalcertifikatet ingår inte i URI:n, men måste vara giltigt för samma värdnamn och betrott av klienterna.

Sophos-brandväggen visar de nödvändiga webbadresserna för tjänsten på Entra ID-servern. Captive-portalens URL är särskilt relevant för den här artikeln. Om WebAdmin eller Remote Access med Entra ID SSO också används, har dessa tjänster sina egna URL:er:

• Webbadministratörskonsolens URL: Entra ID SSO för WebAdmin Console.
• Captive portal URL: Entra ID SSO för Captive Portal i det lokala nätverket.
• VPN-portal och fjärråtkomst-URL: Entra ID SSO för VPN Portal och Sophos Connect.

Om samma Entra ID-server redan används för Remote Access lägger man till Captive portal URL bland befintliga Redirect URIs i Entra-appen. Captive Portal bör ändå testas separat, eftersom inloggningsväg, Device Access, gruppmatchning och den senare firewallregeln ger andra felbilder än Sophos Connect eller VPN Portal.

Ställ in autentiseringsmetod för captive portal

Efter att ha skapat Entra-servern måste autentiseringsmetoden för Captive Portal peka på rätt server.

Det aktuella området är under:

Authentication > Services

För att kontrollera:

1. Öppna Firewall authentication methods.
2. Lägg till eller dra Microsoft Entra ID-server till rätt position.
3. Behåll endast andra autentiseringsservrar om de fungerar som en avsiktlig reserv.
4. Tillämpa ändringen med Apply.
5. Utför en testinloggning med en enda användare.

Sophos Firewall tillåter endast en Microsoft Entra ID-server per autentiseringsmetod. Flera klientorganisationer eller Entra-appar kan därför inte staplas i samma lista Firewall authentication methods.

Om flera autentiseringsmetoder är aktiva parallellt måste det framgå vilken server som ansvarar för vilken användargrupp. För samma användare bör om möjligt bara en autentiseringskälla användas. På en firmwareversion som berörs av NC-167128 kan brandväggen neka sessionen med no permission om en användare växlar från Entra ID SSO till lokal AD-autentisering och därefter återanvänder en tidigare Entra-token. En sådan blandad drift är svårare att testa och bör endast användas medvetet och dokumenteras.

Kontrollera dessutom under Authentication > Web authentication hur Captive Portal öppnas i webbläsaren. HTTPS är viktigt för Entra ID SSO. Alternativet Use insecure HTTP instead of HTTPS ska inte aktiveras eftersom Entra-OAuth-flödet över HTTP inte stöds korrekt och skulle vara onödigt osäkert.

Följande är till hjälp för driften:

1. Öppna Captive Portal i ett nytt webbläsarfönster.
2. Håll det infångade portalfönstret öppet under sessionen.
3. Låt användare logga ut medvetet via captive-portalen om föreningen ska avslutas.
4. Kontrollera efter inloggningen under Current activities > Live users om användaren är synlig.

Alternativen för automatisk utloggning vid inaktivitet eller när webbläsarfliken stängs gäller för närvarande inte Microsoft Entra ID SSO. På delade enheter hålls därför portalfönstret öppet tills användaren uttryckligen har loggat ut där; en stängd flik räknas inte som ett tillförlitligt sessionsavslut.

Beroende på gränssnitt och certifikat kan standard-URL https://<Firewall-IP>:8090 också hjälpa till vid testning. Ett rent FQDN med ett lämpligt certifikat är mycket trevligare för produktiv drift.

Kontrollera enhetsåtkomst och portaltillgänglighet

Captive Portal är en lokal brandväggstjänst. En vanlig brandväggsregel tillåter inte denna åtkomst. Tillgängligheten styrs under Administration > Device access för respektive zon.

Du bör kontrollera:

• Captive portal är endast tillåten i de nödvändiga zonerna.
• Det betyder att WebAdmin och SSH inte av misstag också är allmänt tillgängliga.
• Certifikat och FQDN matchar användarens URL.
• DNS i klientnätverket löser portalnamnet korrekt.
• Undantagsregler för lokala tjänster ACL ställs bara in när de verkligen är nödvändiga.

Om Captive Portal inte är tillgänglig från ett nätverk bör du inte skapa en normal Allow-regel först. Orsaken är ofta enhetsåtkomst, lokal tjänst ACL, DNS, certifikat eller felaktig zonmappning.

Ta hänsyn till Microsoft-inloggning och webbfiltrering

Klienten måste nå Microsofts inloggningssidor och relaterade resurser under inloggningen. Annars, i restriktiva nätverk, kan SSO-flödet stanna vid en punkt som för användarna ser ut som ett brandväggs- eller webbläsarfel.

För att kontrollera:

• DNS-upplösning för Microsofts inloggningsdomäner fungerar.
• HTTPS till Microsofts inloggningsslutpunkter är tillåtet.
• Webbfilter, TLS-inspektion eller proxy blockerar inte inloggningssidan.
• Tid på brandvägg och klient är rimlig.
• Webbläsarcookies görs inte oanvändbara av en strikt policy.

I restriktiva miljöer konfigurerar du hela listan som Sophos dokumenterar för SFOS 22 som FQDN-värdar, i stället för att härleda den från ett fåtal observerade anrop:

• *.aadcdn.microsoftonline-p.com
• *.login.live.com
• login.microsoftonline.com
• *.login.microsoftonline.com
• *.logincdn.msftauth.net
• *.microsoftonline-p.com
• *.microsoftonline.com
• *.msauth.net
• aadcdn.msftauth.net
• login.microsoft.com
• account.activedirectory.windowsazure.com
• *.aadcdn.msauthimages.net
• *.aadcdn.msftauthimages.net
• *.aadcdn.msftauth.net

Skapa uttryckligen objekten och regeln i SFOS:

1. Gå till Hosts and services > FQDN host och välj Add. Ange ett unikt Name för varje post ovan, skriv det listade värdet i FQDN och spara objektet.
2. Gå till Hosts and services > FQDN host group och välj Add. Ange ett Name, använd Add new item, lägg till alla FQDN-värdar som skapades i steg 1 som medlemmar och spara gruppen.
3. Gå till Rules and policies > Firewall rules > IPv4, välj Add firewall rule > New firewall rule och ställ in Action på Accept. Begränsa Source zones och Source networks and devices till det berörda klientsegmentet, ange WAN under Destination zones, välj FQDN-värdgruppen under Destination networks och endast DNS och HTTPS under Services. Placera regeln i rätt ordning, aktivera Log firewall traffic och begränsa användare, schema, källa och destination så snävt som inloggningsflödet tillåter.

Efter att du har sparat kontrollerar du att varje FQDN-värd matchar aktuella adresser och att gruppen innehåller alla 14 objekt. Starta en testinloggning från det avgränsade klientnätverket och verifiera att regelns träffräknare ökar och att dess Rule ID och åtgärden Accept visas i Log Viewer. Om räknaren ligger kvar på 0 kontrollerar du objektupplösning och medlemskap, källzon/-nätverk, destinationszon, tjänster och regelordning innan regeln breddas. Direct Web Proxy kräver dessutom URL-regexundantag; FQDN-listan ensam ersätter inte dessa proxyundantag.

Om webbfiltret, en proxy- eller TLS-inspektion träder i kraft före inloggning bör dessa mål inte dekrypteras eller blockeras i onödan.

Skapa undantaget för Direct Web Proxy

För Direct Web Proxy skapar du motsvarande undantag enligt beskrivningen i Webbundantag:

1. Öppna Web > Exceptions och välj Add.
2. Ange ett beskrivande namn och välj URL pattern matches.
3. Använd Search och Add för vart och ett av dessa 14 exakta regexmönster:

• login\.microsoftonline\.com\.?/
• ^([A-Za-z0-9.-]*\.)?login.live.com\.?/
• aadcdn\.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn\.microsoftonline-p\.com\.?/
• ^([A-Za-z0-9.-]*\.)?login.microsoftonline.com\.?/
• ^([A-Za-z0-9.-]*\.)?logincdn.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msauthimages.net\.?/
• ^([A-Za-z0-9.-]*\.)?msauth\.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msftauthimages.net\.?/
• ^([A-Za-z0-9.-]*\.)?microsoftonline\.com\.?/
• ^([A-Za-z0-9.-]*\.)?microsoftonline-p.com\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?account.activedirectory.windowsazure.com\.?/
• login\.microsoft\.com\.?/

4. Välj alla checks och actions för dessa mönster.
5. Spara undantaget.

Kontrollera att den sparade Web Exception är aktiverad. Under en testinloggning kontrollerar du i webb-/proxyloggarna att den begärda Microsoft-URL:en matchar avsett mönster och att undantaget tillämpas. Om den inte gör det jämför du loggat värdnamn och sökväg tecken för tecken med regexet med ett enkelt omvänt snedstreck och kontrollerar undantagets omfattning och ordning.

Begränsa undantaget så snävt som klientnäten och Entra-inloggningsflödet tillåter; det får inte bli ett generellt undantag för Microsoft-tjänster. Validera båda riktningarna: en tillåten Entra-inloggning ska slutföras, medan en orelaterad Microsoft-URL som inte matchar ska fortsätta genom normal webb- och TLS-policy. Om även det negativa testet undantas ska omfattningen minskas före utrullningen.

Om webbskydd eller TLS Inspection är aktivt, bör inloggningen med en testanvändare observeras i loggvisaren. Ibland är problemet inte Captive Portal i sig, utan en webbpolicy, ett TLS-undantag eller ett klientnätverk som inte helt når Microsofts slutpunkter.

Testa användargrupper och brandväggsregler

Efter en lyckad inloggning på captive-portalen måste den faktiska brandväggsregeln se användaren eller gruppen i trafiken. Detta är det viktigaste praktiska provet.

Typisk process:

1. Kontrollera användare i Microsoft Entra ID.
2. Jämför UPN, e-postadress och gruppmedlemskap.
3. Markera Entra group på Sophos Firewall.
4. Aktivera Match known users och Use web authentication for unknown users i användarregeln.
5. Utför captive portal-inloggning med testanvändare.
6. Utlös sedan riktig användartrafik, till exempel HTTPS till en tillåten destination.
7. I Log Viewer kontrollerar man om användaren, gruppen, källzonen, källnätverket och Rule ID matchar den förväntade regeln.

En lyckad webbläsarinloggning bevisar bara autentisering. Det bevisar inte att den senare användarregeln gäller. Om regelräknaren står kvar på 0 eller om ingen användare är synlig i loggvisaren, bör du använda flödet från Sophos Firewall-regel fungerar inte: kontrollera orsakerna.

Gruppmatchning och den tidigare Primary Group-begränsningen

För användarregler måste den avsedda Entra-gruppen finnas på brandväggen. Efter inloggningen kontrollerar man under Current activities > Live users och i Log Viewer vilken grupp användaren tilldelades och vilket Rule ID som behandlar trafiken.

Det fanns en känd begränsning i SFOS 20.0 GA Build 222: med NC-167130 fungerade internetåtkomst via en sekundär Entra-grupp inte; regeln behövde innehålla Primary Group eller den enskilda användaren. Sophos anger att problemet är löst i SFOS 21.5 MR2 Build 323 och SFOS 22.0 MR1 Build 490. På aktuella builds är Primary Group därför inte längre ett generellt designkrav.

Inför en utrullning bör följande dokumenteras för varje testanvändare:

• Entra-grupp: Målgruppen och medlemskapet är kända.
• Grupp på Sophos-brandväggen: Samma grupp är korrekt importerad eller mappad.
• Brandväggsregel: Den avsedda gruppen ingår i användar- eller gruppvillkoret.
• Testtrafik efter inloggning: Log Viewer visar användare, grupp, Rule ID och förväntad åtgärd.
• Äldre berörd build: Använd Primary Group eller en användarspecifik testregel och planera uppdateringen.

Detta påverkar inte Sophos Connect VPN med Microsoft Entra ID SSO. För fjärråtkomst bör därför den separata processen för Microsoft Entra ID SSO för Sophos Connect och VPN Portal kontrolleras.

Validering efter lansering

Vid godkännandet bör man inte bara kontrollera om Microsofts inloggningssida visas.

• Öppna Captive Portal-URL:en från klientnätverket: Webbläsaren visar förväntad Entra-inloggning eller Sophos-omdirigering.
• Logga in med tillåten användare: Inloggningen lyckades, användaren visas på brandväggen.
• Logga in med otillåten användare: Tillgång nekas förståeligt.
• Gruppregeltest: Testanvändaren matchar den förväntade användarregeln.
• Användartrafik efter inloggning: Rätt brandväggsregel matchar med användaridentitet.
• Sessionsflöde: Efter en timeout måste du logga in igen.
• Microsoft-inloggning blockerad: Loggvisare eller webbloggar visar förståeliga skäl.
• Reservscenario: Testa den dokumenterade tidigare autentiseringsvägen; enbart fallback user group kan inte autentisera användare under ett Entra-avbrott.

Speciellt med BYOD-nätverk bör du testa med flera webbläsare och enheter. Privata surflägen, blockerade cookies från tredje part, gamla sparade inloggningar eller flera Microsoft-konton på samma enhet kan ge olika resultat.

Säker återställning

Dokumentera före ändringen ordningen under Authentication > Services > Firewall authentication methods, inställningarna under Authentication > Web authentication och berörda brandväggsregler. En skärmbild eller konfigurationsexport gör att det tidigare fungerande läget inte behöver återskapas ur minnet.

Om Entra-inloggningen stör driften återställs först den tidigare autentiseringsmetoden till sin ursprungliga position. Återställ endast Match known users och Use web authentication for unknown users till de värden som dokumenterades före utrullningen. Testa därefter en inloggning med den gamla metoden, Current activities > Live users och riktig trafik som ska matcha regeln.

Ta inte genast bort Entra-appen, serverobjektet, importerade grupper eller klienthemligheten: även WebAdmin, VPN Portal eller Remote Access kan använda dem. Ta bort Captive portal URL från App Registration först när det är bekräftat att ingen tjänst eller annan brandväggsnod använder den.

Felsökning

Captive-portalen är inte tillgänglig

Kontrollera först Administration > Device access för den berörda zonen. Kontrollera sedan DNS, certifikat, portal FQDN, lokal tjänst ACL och zonmappning. Om åtkomsten går till själva brandväggen är en normal brandväggsregel inte den första kontrollpunkten.

Microsoft-inloggning startar men kommer inte tillbaka

Jämför omdirigerings-URI, FQDN, certifikat och port. Den exakta URL som Sophos Firewall använder för Captive Portal måste lagras i Microsoft Entra ID. Proxy- eller TLS-inspektionsregler kan också störa returen.

När Microsoft visar felet AADSTS50011 matchar omdirigerings-URI:en i appregistreringen vanligtvis inte URL:en som brandväggen använder. Sedan måste protokollet, FQDN, port och sökväg jämföras exakt.

Ett internt fel visas efter Microsoft-inloggning

Ett 500 Internal Server Error eller ett liknande generiskt fel efter en lyckad Microsoft-inloggning indikerar ofta en brist på Microsoft Graph-behörigheter, en brist på administratörsmedgivande eller ett problem med klienthemligheten. Sedan bör du kontrollera API-behörigheterna, administratörens samtycke, hemliga giltighet och företagsapptilldelning i Microsoft Entra ID.

Om oauth_sso_captive.log i stället visar x509: certificate signed by unknown authority läses först den Microsoft-certifikatkedja som brandväggen faktiskt når, och en verifierat saknad Root CA eller Intermediate CA importeras från en betrodd källa:

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

Därefter körs Test connection igen. Endast om CA-kedjan redan har korrigerats och felet kvarstår är den av Sophos dokumenterade, nodlokala omstarten av Captive SSO-tjänsten ett valfritt sista steg i ett underhållsfönster:

service oauth_sso_captive:restart -ds nosync

Sedan upprepas Test connection och en ny inloggning i Captive Portal. En tjänsteomstart ersätter varken certifikatkontrollen eller ett saknat Admin Consent.

Användarnamn och lösenord fungerar inte direkt

Entra ID SSO är en webbläsare och OAuth/OIDC-flöde. Användare loggar inte in direkt på brandväggen med klassiska referenser, utan omdirigeras till Microsoft. Om en klient eller ett flöde endast stöder användarnamn och lösenord utan webbläsaromdirigering, passar den här metoden inte.

MFA visas inte eller ser annorlunda ut än förväntat

Med Entra ID SSO kontrolleras MFA i Microsoft Entra ID. Lokal brandvägg MFA är inte rätt kontrollpunkt för detta SSO-flöde. Om MFA krävs bör du kontrollera villkorad åtkomst, användargrupper, undantag och testanvändare i Microsoft Entra ID.

Användaren ser no permission eller avvisas efter långvarig drift

Detta felmönster stämmer med NC-167128 i SFOS 21.0 GA Build 169: om samma användare först använder Entra ID SSO, därefter On-Prem AD i det lokala nätverket och sedan återanvänder den tidigare Entra-tokenen kan no permission visas. Problemet är åtgärdat från och med SFOS 21.5 MR2 Build 323 respektive SFOS 22.0 MR1 Build 490.

På den berörda versionen ska webbläsarcookies först rensas. Om problemet uppstår i Sophos Connect körs Force SSO re-login där; sökvägen till kommandot finns i Konfigurera Microsoft Entra ID SSO för Sophos Connect och VPN Portal. På längre sikt är det bättre att konsekvent använda antingen Entra ID eller On-Prem AD för samma användare och uppgradera till en korrigerad firmwareversion.

Inloggning fungerar, men användarregeln matchar inte

Då är captive portal förmodligen inte längre det enda problemet. Kontrollera källzon, källnätverk, användargrupp, regelposition och loggvisare. Ofta ligger en mer generell regel över användarregeln eller så kommer trafiken från ett annat nätverk än förväntat.

Kontrollera också att den avsedda Entra-gruppen är importerad och att användaren är tilldelad den på brandväggen. Endast på SFOS 20.0 GA Build 222, som påverkas av NC-167130, måste Primary Group eller den enskilda användaren finnas i regeln för detta fel.

Endast enskilda användare påverkas

Jämför UPN, e-postadress, visningsnamn, gruppmedlemskap och importerad grupp. Med Entra ID SSO ska du inte anta att det synliga namnet och den tekniska identifieraren är identiska. Om e-postadress och UPN historiskt sett skiljer sig åt, uppstår lätt mappningsfel.

Vilka loggar hjälper?

oauth_sso_captive.log är särskilt relevant för Captive Portal med Entra ID SSO. Dessutom hjälper Log Viewer med modulen Authentication, access_server.log och, beroende på efterföljande problem, webb-, brandväggs- eller autentiseringsloggar. Tilldelningen av de viktigaste filerna finns i Sophos Firewall Felsökning: Tjänster och loggar.

Checklista

• Användningsfallet för infångad portal är tydligt: BYOD, gäster, ohanterade enheter eller reserv.
• FQDN och certifikat för captive-portalen är rena.
• Microsoft Entra ID-app med Redirect URI, Client ID, Tenant ID och Client Secret är dokumenterad.
• Microsoft Graph API-behörigheter och administratörssamtycke är inställda.
• Tilldelningar av företagsappar kontrolleras om Uppdrag krävs är aktivt.
• Client Secret har utgångsdatum, ägare och rotationsprocess.
• Captive Portal Redirect URI togs över av brandväggen och matades in exakt i Entra ID.
• Authentication > Services använder rätt Entra-server för Captive Portal.
• Authentication > Web authentication använder HTTPS och lämpliga webbläsarfönsterinställningar.
• Administration > Device access tillåter endast Captive Portal i nödvändiga zoner.
• Microsofts inloggningsslutpunkter kan nås från klientnätverket.
• Webbfiltrering och TLS-inspektion blockerar inte SSO-flödet.
• MFA och Conditional Access planeras och testas i Microsoft Entra ID.
• Entra-grupp och brandväggsgrupp matchar.
• Den avsedda Entra-gruppen är importerad och utvärderas faktiskt för testanvändaren.
• Testanvändare kan logga in och sedan träffa den förväntade brandväggsregeln.
• Loggvisaren visar användare, regel-ID och åtgärd.
• oauth_sso_captive.log och access_server.log är kända för supportärenden.
• Reserv för Entra- eller Portal-fel dokumenteras.

Vanliga frågor