Ansluta Active Directory till Sophos Firewall

Active Directory är fortfarande den centrala källan för användare, grupper och autentisering i många Sophos Firewall-miljöer. Firewallen använder AD-anslutningen till exempel för användarregler, Remote Access VPN, Captive Portal, User Portal, Reporting eller Single Sign-On-scenarier.

Artikeln förklarar hur man lägger till en Active Directory-server på Sophos Firewall, vilka fält som verkligen är viktiga och hur anslutningen kontrolleras efteråt. För nya Remote Access-designer bör man dessutom avgöra om klassiskt AD, RADIUS eller Microsoft Entra ID SSO för Sophos Connect och VPN Portal passar bättre.

Om Active Directory ska bli målet för en befintlig eDirectory-miljö bör man först planera den kontrollerade migreringsprocessen för eDirectory med gruppkontroll, tjänstevis övergång och återställning.

Följande Sophos Techvids-video visar grundprocessen som visuellt komplement. Den skapades med SFOS v21, logiken är fortfarande användbar, men enskilda vyer kan se något annorlunda ut i SFOS 22.

Det praktiska arbetsflödet består av fyra delar. Ett lyckat anslutningstest är bara början; VPN, portaler, användarregler och SSO måste valideras separat.

1. Lägg till servern: ange domänkontrollant, NetBIOS-domän, sökbas och servicekonto korrekt.
2. Skydda anslutningen: planera LDAPS, certifikatvalidering och intern DNS-upplösning medvetet.
3. Importera grupper: importera endast nödvändiga AD-grupper och förstå Main Group.
4. Testa användningen: kontrollera inloggning, MFA, VPN, User Portal, Captive Portal, SSO och Log Viewer.

Sammanhang

Sophos Firewall kan använda flera autentiseringskällor. Active Directory är lämpligt när användare och grupper redan underhålls lokalt i en Windows-domän och firewallen ska använda dessa identiteter direkt.

Typiska användningsfall:

• användar- och gruppsynkronisering från lokalt Active Directory
• Firewall-regler med användar- eller gruppkoppling
• Remote Access VPN med AD-användare
• User Portal eller Captive Portal med domänkonton
• Reporting per användare i stället för enbart per IP-adress
• Active Directory SSO med NTLM eller Kerberos

AD-anslutning betyder däremot inte automatiskt att varje autentiseringsfråga är löst. Man måste skilja på om firewallen bara frågar användare via LDAP/LDAPS, om grupper importeras, om SSO används eller om Remote Access dessutom behöver MFA. För MFA-grunder passar Aktivera MFA för Sophos Firewall WebAdmin, VPN Portal och Remote Access.

Viktiga beslut före konfiguration

Före servern läggs till bör dessa punkter vara klara:

• Anslutning: använd om möjligt LDAPS med SSL/TLS på port 636.
• Servicekonto: använd ett dedikerat AD-konto med läsrättigheter i stället för Domain Admin.
• Sökbas: sök endast i nödvändiga organisationsenheter, inte i hela domänen utan avgränsning.
• Visningsattribut: välj medvetet sAMAccountName, userPrincipalName eller displayName.
• Grupper: importera endast grupper som verkligen behövs för brandvägg, VPN eller portal.
• MFA: skydda fjärråtkomst och portaler ytterligare med MFA.
• Serverordning: ange frågeordningen medvetet när flera AD-servrar används.
• Drift: kontrollera autentiseringsloggar, gruppimport, certifikat och lösenordets giltighetstid regelbundet.

Även routning och källväg från brandväggen till domänkontrollanten måste vara fastställda. LDAPS kräver TCP 636 och STARTTLS TCP 389; intern DNS-upplösning och en fullständig, giltig certifikatkedja måste fungera från den brandväggsväg som faktiskt används. Före ändringen skapas och hämtas en krypterad konfigurationsbackup under Backup and firmware > Backup and restore, och backupens lösenord förvaras säkert.

⚠️ Anslutningen mellan firewall och autentiseringsserver bör vara krypterad. Okrypterad LDAP på port 389 kan fungera i labb, men är ingen bra permanent lösning för produktiva miljöer.

För AD-integration stöds även äldre Windows Server-versioner, men i aktuella miljöer är framför allt Windows Server 2016, 2019, 2022 och 2025 relevanta. Sedan SFOS 21.5 MR1 är Active Directory SSO med Windows Server 2025 möjligt för NTLM och Kerberos. SFOS 22 innehåller uppdaterade Samba-komponenter för Kerberos- och NTLM-autentisering och tar bort äldre krypteringsmetoder. Särskilt efter firewall- eller Domain Controller-upgrades bör man därför testa AD SSO, gruppimport och Remote Access riktat.

Viktigt: strikt tvingande LDAP Channel Binding och LDAP Signing stöds för närvarande inte av Sophos Firewall. Om Domain Controllers kräver mycket hårda LDAP-säkerhetskrav bör AD-anslutningen därför testas i ett underhållsfönster före produktiv omställning.

Lägg till Active Directory Server

Konfigurationen görs i Sophos Firewalls WebAdmin:

Authentication > Servers

Där skapas en ny autentiseringsserver med Add och Active Directory väljs som Server Type.

Fält i Active Directory-konfigurationen

Numreringen i skärmbilden är avsiktlig: de viktigaste fälten förklaras uppifrån och ned. Beroende på SFOS-version kan ordningen se något annorlunda ut. I nyare versioner syns dessutom Validate server certificate när certifikatkontroll för LDAPS ska aktiveras.

1. Server type: för en klassisk Windows-domän används Active Directory. RADIUS, LDAP och Microsoft Entra ID är andra integrationssätt som inte ska blandas ihop.
2. Server name: internt visningsnamn på brandväggen. Det påverkar inte DNS eller AD, men bör vara entydigt, exempelvis AD-ZH-DC01 eller AD-HQ-LDAPS. Med flera domänkontrollanter underlättar ett tydligt namn i Log Viewer och vid felsökning.
3. Server IP/domain: domänkontrollantens IP-adress eller DNS-namn. DNS-namn är att föredra när certifikat, intern DNS-upplösning och redundans stämmer. IP-adress förenklar felsökning men binder brandväggen till en viss kontrollant.
4. Port: port för LDAP-anslutningen. I produktion föredras 636 med SSL/TLS. Port 389 används för okrypterad LDAP eller STARTTLS men bör inte vara en permanent lösning.
5. NetBIOS domain: AD-domänens korta NetBIOS-namn, till exempel AVANET. Det är inte DNS-domännamnet. Ett felaktigt värde gör ofta att användare inte hittas eller tilldelas korrekt.
6. ADS user name: namnet på kontot som används för AD-frågor. Sophos använder kortnamnet administrator i sitt exempel. I produktion rekommenderar Avanet i stället ett dedikerat servicekonto med rätt att söka, läsa och hämta gruppmedlemskap, inte ett Domain Admin-konto. Sophos bekräftar inte att kortnamn, DOMAIN\user och UPN är likvärdiga i alla konfigurationer; använd och dokumentera därför det format som testats i den egna AD-miljön.
7. Password: servicekontots lösenord. Om det löper ut eller ändras kan frågor, gruppimport samt VPN- och portalinloggningar plötsligt sluta fungera. Dokumentera och övervaka därför kontot.
8. Connection security: för LDAPS används SSL/TLS med port 636. STARTTLS använder normalt 389 och kräver korrekt stöd på domänkontrollanten. Plaintext är okrypterat och bör bara användas för tester.
9. Display name attribute: AD-attributet som används som visningsnamn. Det måste passa katalogschemat och verifieras med en testanvändare; Sophos allmänna anvisning anger inga generellt utbytbara standardvärden. För Microsoft Entra Domain Services anger Sophos uttryckligen DisplayName.
10. Email address attribute: attribut för e-postadress, oftast mail. Det är bara användbart om adresserna faktiskt underhålls i AD.
11. Domain name: AD-domänens DNS-namn, till exempel ad.example.com. Det är inte NetBIOS-namnet och måste stämma med domän, sökbas och domänkontrollant.
12. Search queries: sökbas för användar- och gruppfrågor. Ange ett Distinguished Name som DC=ad,DC=example,DC=com eller begränsa det till OU=Users,OU=Company,DC=ad,DC=example,DC=com. En riktad OU begränsar synliga användare och håller importen överskådlig.

Endast användare som omfattas av minst en Search query kan visas för den här AD-servern under Current activities > Live users. Om en förväntad användare saknas trots ett lyckat Test connection, kontrolleras först att Base DN och OU-omfånget inkluderar användarens faktiska katalogobjekt. Sökbasen breddas inte i förebyggande syfte till hela domänen.

Om flera Domain Controllers finns bör man medvetet avgöra om firewallen ska tala med en specifik DC eller om ett stabilt internt DNS-namn pekar mot en lämplig AD-infrastruktur. Viktigt är att DNS-upplösning, certifikat, routing och firewall-regler passar ihop.

AD-automatisering vid övergång från SFOS 22 till SFOS 23: API-dokumentationen för att lägga till och redigera en AD-server använder mer avgränsade benämningar i tabellerna i SFOS 23 än i SFOS 22: ServerIpDomain/ServerAddress blir ServerAddress, ServerName/NetBIOSDomain blir NetBIOSDomain och ADSUsername/Administrator/Username blir ADSUsername/Administrator. XML-exemplet använder däremot samma element i båda versionerna: ServerAddress, NetBIOSDomain och ADSUsername. Detta visar att benämningarna i dokumentationen har ändrats, inte att firewallen avvisar äldre aliasnamn eller att de WebAdmin-fält som förklaras ovan har bytt namn. Exemplet är inte konsekvent i sig och är ingen verifierad API-mall som kan köras direkt.

Även benämningarna för anslutningssäkerhet hålls åtskilda: Plaintext är benämningen i WebAdmin; API-dokumentationen anger värdena Simple, SSL och StartTLS för ConnectionSecurity. GUI-benämningar används inte som API-värden utan föregående kontroll.

Mellan SFOS 22 och SFOS 23 skiljer sig dessutom de dokumenterade status-/meddelandetabellerna för Add och Edit. Dessa tabeller garanterar i sig varken faktiska svarskoder eller returnerade meddelandetexter, HTTP-transportstatus eller säkra återförsök. Vid migrering av AD-automatisering kontrolleras därför tolkningen av svaren mot API-dokumentationen för den version som används och faktiskt registrerade svar, i stället för att gamla felmappningar återanvänds oförändrade. Därefter kontrolleras den sparade AD-konfigurationen och att en vanlig testanvändare kan logga in på den avsedda tjänsten.

Validate server certificate

I aktuella SFOS-versioner kan Validate server certificate dessutom aktiveras. Det är lämpligt för LDAPS, eftersom firewallen då inte bara ansluter krypterat utan också kontrollerar om den litar på Domain Controller-certifikatet.

För detta måste dessa punkter stämma:

1. Domänkontrollantens servercertifikat laddas upp under Certificates > Certificates > Add > Upload certificate. Ett fristående CA-certifikat hör däremot hemma under Certificates > Certificate authorities; blanda inte ihop listorna.
2. Enligt Sophos anvisning anges CNAME i Server IP/domain; detta DNS-namn måste finnas i servercertifikatets Subject Alternative Name.
3. Firewallen kan lösa upp detta CNAME internt.
4. Datum och tid på firewall och Domain Controller stämmer.

Om den interna DNS-upplösningen inte löser upp en CNAME eller Domain Controller-namnet korrekt kan en DNS Host Entry under Network > DNS > DNS host entry hjälpa.

NetBIOS-domän och domännamn

Sophos Firewall behöver både uppgifter om NetBIOS-domänen och domännamnet. Dessa värden ska passa exakt till AD-domänen.

NetBIOS-domänen hittar man till exempel i Active Directory Users and Computers via domänens egenskaper.

Domännamnet är domänens DNS-namn, till exempel ad.example.com.

Typiska fel här:

• NetBIOS-namn och DNS-domännamn förväxlas.
• Den angivna Domain Controller tillhör en annan domän.
• Firewallen kan inte lösa upp Domain Controllerns DNS-namn.
• En nätverks- eller Windows-firewall blockerar anslutningen mellan firewall och Domain Controller.

Servicekonto och lösenord

För åtkomst till Active Directory bör ett dedikerat servicekonto användas. Ett Domain Admin-konto behövs inte för normal LDAP-fråga och ökar risken i onödan.

Lämpliga riktlinjer:

• eget konto för firewallen, till exempel svc-sophos-fw-ldap
• bara nödvändiga läsrättigheter
• dokumenterad ansvarig för lösenordsbyten
• långt, unikt lösenord
• ingen interaktiv inloggning om AD-policyerna kan avbilda det korrekt
• övervakning eller påminnelse före lösenordsutgång

Om servicekontots lösenord löper ut eller ändras kan firewallen inte längre fråga användare och grupper. Det visar sig senare ofta som VPN-, Portal- eller användarregelproblem, även om den egentliga orsaken ligger i AD-anslutningen.

Anslutningssäkerhet och LDAPS

För produktiva miljöer bör man föredra LDAPS. Domänkontrollanten behöver då ett passande servercertifikat. När Validate server certificate är aktivt följs Sophos-importen ovan för servercertifikatet; ett CA-certifikat som också behövs importeras separat som Certificate Authority.

Kontrollera:

• Port 636 är nåbar från firewall-interfacet till Domain Controller.
• Domain Controller-certifikatet är giltigt.
• Certifikatnamnet passar det använda DNS-namnet.
• Servercertifikatet och vid behov utfärdande CA är importerade i respektive korrekt certifikatlista.
• Tid och datum på firewall och Domain Controller stämmer.

En viktig produktgräns kvarstår: SFOS 22 stöder för närvarande inte strikt tillämpning av LDAP Channel Binding och LDAP Signing. LDAPS med certifikatvalidering skyddar anslutningen, men bevisar inte att en AD-säkerhetspolicy som kräver channel binding eller signing uppfylls. Om organisationen kräver denna tillämpning måste integrationen valideras mot den konkreta AD-policyn före rollout och får inte godkännas enbart på grundval av en lyckad Test connection.

Vid certifikatfrågor är även CA-distribution relevant. För distribution av Sophos Firewall-CA till clients passar Distribuera Sophos Firewall CA-certifikat för HTTPS Scanning. För LDAPS är däremot främst CA:n för Domain Controller respektive intern PKI avgörande.

Anslut Microsoft Entra Domain Services

En hanterad Microsoft Entra Domain Services-domän kan anslutas som Active Directory-server. Sophos anger WebAdmin, Captive Portal, User Portal, Client Authentication Agent och Remote Access SSL VPN för detta. Det är inte direkt Entra ID-SSO; dokumentationen bekräftar i synnerhet inte stöd för VPN Portal.

Aktivera Secure LDAP för produktion och tillåt port 636 från vald brandväggsväg till domänen. Servercertifikatet behöver Extended Key Usage Server Authentication. Exponera helst inte LDAPS publikt, utan använd en privat Azure- eller IPsec-väg och begränsa Network Security Group till nödvändig källadress.

Sophos officiella exempel använder den publika Secure LDAP-IP-adressen, SSL/TLS, port 636, DisplayName och mail och stänger av Validate server certificate. En privat anslutning via Azure-nät eller IPsec är Sophos ytterligare säkerhetsrekommendation. Certifikatvalidering med matchande namn och korrekt förtroendekedja är däremot en härdningsrekommendation från Avanet som måste testas i den egna miljön och inte anges som en del av det officiella exemplet. Entra-användare måste först logga in och byta lösenord så att Kerberos-/NTLM-hashar skapas och synkroniseras; bind-kontot ska tillhöra den konfigurerade administratörsgruppen för Entra Domain Services.

Visningsattribut och e-postattribut

Visningsattributet avgör hur användare visas i Sophos Firewall. Typiska värden är:

• sAMAccountName
• userPrincipalName
• displayName
• name

Värdena är inte generellt utbytbara. Katalogschemat, entydigheten och resultatet med en testanvändare är avgörande. För Entra Domain Services dokumenterar Sophos DisplayName; det innebär ingen allmän rekommendation för lokalt AD.

Attributen kan kontrolleras i Active Directory Users and Computers när Advanced Features är aktiverat.

E-postattributet är oftast mail. Det är framför allt relevant om firewallen ska koppla e-postrelaterad information till användare.

Sökbas och grupper

Sökbasen avgör vilken del av Active Directory som firewallen söker igenom. För en hel domän kan ett exempel vara:

DC=ad,DC=example,DC=com

För en enskild OU kan sökvägen till exempel se ut så här:

OU=Users,OU=Company,DC=ad,DC=example,DC=com

Distinguished Name för en OU hittar man i Active Directory Users and Computers i OU:ns attribut.

En för bred sökbas fungerar ofta, men gör konfigurationen mer svåröverskådlig. För produktiva miljöer är detta bättre:

• dedikerad OU eller tydlig sökbas för relevanta användare
• separata AD-grupper för VPN, portaler eller Firewall-regler
• ingen slumpmässig återanvändning av stora avdelningsgrupper
• testa gruppimport efter ändringar
• ta bort gamla eller tomma grupper regelbundet

För breda gruppimporter kan på sikt även belasta firewallens interna användarhantering. Om mycket många gamla användare eller grupper uppstår och VPN Portal-nedladdningar senare fallerar oväntat hjälper kontroll av Sophos Firewall User-ID-gränsen.

Viktigt vid Remote Access: Sophos ändrade i SFOS 21.5 MR1 att L2TP och PPTP inte längre aktiveras automatiskt när grupper importeras från Active Directory och Microsoft Entra ID. Det minskar oönskad angreppsyta, men bör kontrolleras efter upgrades om gamla Remote Access-processer har förlitat sig på detta. Konfigurera L2TP-fjärråtkomst på Sophos Firewall beskriver uttrycklig medlemstilldelning, Main Group-gränsen och verifieringen.

Importera grupper och förstå användare

Efter att AD-servern lagts till finns AD-grupper inte automatiskt fullständigt i firewallen. Grupper importeras via importguiden:

Authentication > Servers > Import

Förloppet är:

1. Välj AD-server och starta Import.
2. Välj Base DN för gruppsökningen.
3. Välj nödvändiga AD-grupper.
4. Kontrollera gemensamma Group Policies.
5. Kontrollera urvalet och slutför importen.
6. Kontrollera under Authentication > Groups om grupperna finns korrekt.

Om AD ska vara den primära autentiseringsmetoden i detta konfigurationsflöde, gå till Authentication > Services, välj den konfigurerade AD-servern under Firewall authentication methods, flytta den till första platsen i listan över valda servrar och klicka på Apply. Kontrollera sedan de importerade grupperna under Authentication > Groups och låt en testanvändare logga in igen för att uppdatera grupptilldelningen. Den första platsen gäller flödet med AD som primär metod, inte alla befintliga serverordningar.

Användare visas under Authentication > Users först när de loggar in på en tjänst, till exempel User Portal, VPN Portal, Captive Portal eller via Remote Access VPN. Vid varje login kontrollerar firewallen på nytt vilka importerade grupper som passar användaren och uppdaterar tilldelningen.

Om ingen av användarens AD-grupper finns på brandväggen tilldelas den Default group som konfigurerats under Authentication > Services. Produktens standardvärde är Open group. Kontrollera ändå det faktiska värdet före driftsättning, eftersom det kan ha ändrats och direkt avgör vilka inställningar som ärvs.

I HA-miljöer importerar man AD-grupper på Primary-enheten. Det gäller även rensning av gamla AD-användare med Purge AD users.

Den fullständiga proceduren för att hantera och testa gruppolicyer, Default Group, huvudgrupp, användaråsidosättningar och funktionsberoende stöd för flera grupper finns i Hantera användargrupper och huvudgruppen korrekt i Sophos Firewall.

Main Group, gruppordning och nästlade grupper

En AD-användare kan vara medlem i flera grupper. Sophos Firewall skiljer mellan:

• Group: den första passande gruppen i brandväggens grupplista. Det är användarens Main Group.
• Other group memberships: ytterligare importerade grupper som användaren också tillhör.
• Group order: ordningen under Authentication > Groups. Den avgör vilken grupp som blir Main Group vid flera träffar.

Detta är viktigt eftersom inte alla funktioner utvärderar flera grupper. Vissa funktioner använder bara Main Group. Om en användare finns i flera AD-grupper kan därför en annan policy träffa än väntat.

Gruppordningen ändras här:

Authentication > Groups > Reorder

Nästlade AD-grupper stöds inte. Om en firewall-policy ska gälla för en undergrupp måste denna undergrupp importeras själv. Det räcker inte att bara importera den överordnade AD-gruppen.

Den primära AD-gruppen för en användare tas inte heller över som ett normalt gruppmedlemskap. Det gäller särskilt AD-standardgruppen Domain Users. För firewall-policies bör man därför använda explicita säkerhetsgrupper och lägga användare direkt i dessa grupper.

Vilka funktioner stöder flera grupper

För driften är denna skillnad särskilt viktig.

Flera AD-grupper kan beaktas för:

• Firewall rules: ordningen på brandväggsreglerna är fortsatt avgörande.
• SSL/TLS inspection rules: den första passande inspektionsregeln används.
• Web policies: först matchas brandväggsregeln och därefter rätt Web Policy-regel.
• IPS policies: policyn från den passande regeln tillämpas.
• Application control policies: utvärderingen sker via den passande brandväggsregeln.
• SD-WAN routes: användar- eller gruppkriterier kan beakta flera grupper.
• Policy test: hjälper till att kontrollera grupp- och policymatchning.
• Remote access SSL VPN: behörigheter från passande Full- och Split Tunnel-policyer beaktas; Full Tunnel har företräde.
• Clientless SSL VPN: behörigheter från passande grupper kombineras.

Endast Main Group eller uttryckligen angivna användare beaktas för:

• WAF rules
• Remote access IPsec VPN
• L2TP och PPTP
• Hotspots
• MFA, när MFA riktas till grupper
• Surfing quota, Access time, Network traffic och Traffic shaping
• Quarantine digest, MAC binding och Sign-in restriction

Sophos Firewall Access Time för användare och grupper visar hur huvudgruppen för tidsberoende användaråtkomst kontrolleras och användarundantag avgränsas.

Samma Main Group-gräns gäller för förbrukningsbaserade tids- och datakvoter. Surfing Quota och Network Traffic Quota på Sophos Firewall beskriver hela arbetsflödet.

Praktiskt exempel: en användare är medlem i VPN-Users och Firewall-Admins. För SSL VPN kan multipelt medlemskap fungera. För IPsec Remote Access eller MFA-grupptilldelning kan däremot bara Main Group räknas. Därför bör man vid Remote Access och administrativa åtkomster medvetet testa vilken grupp som är satt som Group i användarobjektet.

Flera Active Directory-servrar

Man kan konfigurera flera AD-servrar. För Firewall authentication methods gäller en viktig regel: brandväggen går bara vidare till nästa server när den föregående inte kan nås; nekade inloggningsuppgifter utlöser inte normal redundans. Ordningen innebär alltså varken lastbalansering eller en ersättning för en välplanerad AD-arkitektur.

Rekommendationer:

• Sätt serverordning under Authentication > Services medvetet.
• Dokumentera sökbas och domän korrekt per server.
• Använd inga motsägande grupper med samma namn i olika källor.
• Planera separata DNS- och AD-konfigurationer korrekt vid flera UPNs eller flera domäner.
• Testa redundansen inte bara med Test connection, utan med en verklig användarinloggning.
• Vid bortfall av en AD-server kan felmeddelandet för användaren se ut som ett felaktigt lösenord.

Om flera UPNs hör till samma domäninfrastruktur måste DNS-poster och AD-serverkonfiguration passa respektive domän. Viktigt är att sökbas, Domain Name och serverupplösning hör ihop.

För flera UPN-domäner på samma domänserver beskriver Sophos denna specifika konfiguration: skapa en DNS-post för varje domän som pekar på den serverns IP-adress och en separat AD-serverkonfiguration på brandväggen för varje domän. Använd respektive AD-domän som Search query i LDAP-DN-format, till exempel DC=ad,DC=example,DC=com för ad.example.com. Ersätt värdena med de egna domänerna och testa inloggning och grupptilldelning för varje UPN-domän. Detta är inte ett förfarande för lastbalansering eller failover mellan flera domänkontrollanter; med LDAPS måste det använda servernamnet fortfarande passa certifikatvalideringen.

Testa anslutningen

Efter att ha sparat bör anslutningen testas direkt. Testet kontrollerar om firewallen når servern och om de angivna uppgifterna i grunden passar.

Ett lyckat test betyder inte automatiskt att användarregler, SSO eller VPN redan fungerar. Därefter bör minst dessa punkter kontrolleras:

1. AD-användare eller grupper hittas korrekt.
2. Testanvändare kan logga in på avsedd plats.
3. Gruppmedlemskap passar önskad firewall- eller VPN-behörighet.
4. Log Viewer visar spårbara autentiseringsevents.
5. Remote Access VPN, User Portal eller Captive Portal fungerar med en normal testanvändare.
6. MFA efterfrågas om det är planerat för användningsfallet.
7. AD-servern är införd på önskad plats i Firewall Authentication Methods under Authentication > Services.

Om det därefter fortfarande är oklart om tjänstevalet, användaridentiteten, Main Group, kvoten eller först den senare brandväggsregeln misslyckas skiljer Felsök autentiseringsfel på Sophos Firewall systematiskt dessa lager åt med ett reproducerbart testfall.

För Remote Access med Sophos Connect är Konfigurera Sophos Connect Client på Sophos Firewall nästa passande steg.

Validering efter användningsfall

Efter AD-anslutningen bör inte bara ett enskilt anslutningstest dokumenteras. Olika funktioner använder AD-integrationen på olika sätt. Därför bör man göra ett eget test för varje planerat användningsfall.

• Gruppimport: sök efter en relevant AD-grupp och importera den till brandväggen. Vid fel hittas gruppen inte eller innehåller oväntade användare.
• User Portal: testa inloggning med en vanlig AD-användare. Ett typiskt symptom är att inloggningen misslyckas trots ett lyckat servertest.
• Remote Access VPN: kontrollera VPN-inloggning, gruppbehörighet, MFA och åtkomst till interna mål. Användaren kan autentiseras men ändå sakna rätt policy eller åtkomst.
• Användarbaserad brandväggsregel: skapa testtrafik och kontrollera användare, grupp och Rule ID i Log Viewer. Vid fel visas trafiken bara med IP-adress eller träffar en annan regel.
• Captive Portal: testa webbläsarinloggning och efterföljande trafik. Inloggningen kan fungera utan att användaren därefter kopplas korrekt.
• AD SSO eller STAS: kontrollera Live Users och Log Viewer efter Windows-inloggningen. Vid problem förblir användaren okänd eller kopplas till fel IP-adress.

Denna uppdelning sparar tid i drift. Ett lyckat LDAP-test bevisar bara att server, port, bind-konto och sökbas i grunden är nåbara. Det bevisar inte att VPN-grupper tilldelas korrekt, att MFA tillämpas eller att användartrafik utvärderas med identitet i brandväggsregler.

För användarbaserade regler bör man alltid utlösa ett verkligt trafiktest och kontrollera i Log Viewer om användarnamn, grupp, Firewall Rule ID och åtgärd stämmer med förväntan. Om bara IP-adressen syns ligger orsaken ofta i SSO, STAS, Captive Portal eller i brandväggsreglernas ordning. För STAS-miljöer passar Konfigurera STAS på Sophos Firewall som nästa artikel.

Om Sophos Endpoint redan skickar Security Heartbeat kan Synchronized User ID Authentication överföra en Windows 10-domänanvändare till brandväggen utan extra autentiseringsagent. Förloppet kräver fortfarande rätt AD-validering och ett verkligt regeltest.

Beakta Active Directory SSO

Active Directory SSO är ett eget driftområde. Själva AD-serveranslutningen är en grund, men SSO kräver dessutom rätt förutsättningar för klient, webbläsare, DNS, Kerberos eller NTLM.

För Web Authentication stöder Sophos Firewall klassisk AD SSO med Kerberos och NTLM. Kerberos är renare och snabbare, men ställer högre krav på FQDN, DNS, SPN och webbläsarens förtroende. NTLM är mer tolerant och kan vara en pragmatisk reservmetod i gamla miljöer, men bör inte tyst bli den enda metod som fungerar.

Sophos placerar webbläsarinitierad NTLM efter General Authentication Client, Clientless single sign-on och Client-based single sign-on. NTLM används som reserv först när dessa tilldelningar inte gäller; om även NTLM misslyckas visas Captive Portal. Om en användare visas med en oväntad metod under Current activities > Live users kontrolleras först den visade Client type och redan aktiva identitetskällor innan SPN eller Web Authentication ändras.

Inställningen Kerberos & NTLM erbjuder båda metoderna till webbläsaren, och klienten avgör vilken som används. Det finns inget läge med enbart Kerberos eftersom HTTP-specifikationen inte stöder det. För transparent webbtrafik omdirigerar firewallen autentiseringen till TCP-port 8091.

När flera användare delar samma RDS- eller terminalserver-IP räcker den vanliga IP-kopplingen inte. För HTTP- och HTTPS-trafik som uteslutande går genom en explicit proxy beskriver Per-Connection AD SSO för fleranvändarvärdar det separata förfarandet och avgränsningen mot SATC.

⚠️ Uppgraderingsinformation för SFOS 22: Efter en upgrade från SFOS 21.5 eller tidigare till SFOS 22.0 GA kan AD SSO med Kerberos och NTLM sluta fungera. Användarbaserade regler känner då inte längre igen de berörda domänanvändarna, medan annan firewall-trafik fortsätter fungera. Sophos har korrigerat felet i SFOS 22.0 MR1 Build 490. AD SSO bör testas med verklig användaråtkomst före och direkt efter upgraden. Reparera AD SSO efter SFOS 22-upgrade beskriver kontrollen i nasm.log, riktad NASM-cleanup och efterföljande kontroll med verklig användartrafik.

AD SSO-flödet är därför mer än bara Test connection på AD-servern:

Sophos beskriver registreringen av brandväggen i Windows-domänen som att ett objekt för brandväggen skapas på den primära domänkontrollanten. Detta sammanhang hör till domänanslutningen för AD SSO; enbart LDAP/LDAPS-katalogfrågor kräver inte automatiskt den anslutningen. De rättigheter som krävs för domänanslutningen hålls separata från LDAP-bindkontots läsrättigheter.

1. Ange hostname eller FQDN under Administration > Admin and user settings. För Kerberos bör det vara en FQDN, skriven med små bokstäver och med en host-del på högst 15 tecken, så att NetBIOS name, AD-datorobjekt och SPN inte glider isär.

   Exempel: brandväggen är konfigurerad som fw01.edge.example.com, medan AD-domänen heter corp.example.com. Vid domänanslutningen använder SFOS NetBIOS-värdnamnet fw01 tillsammans med AD-domänen. Namnet som AD känner till är därför fw01.corp.example.com, inte automatiskt brandväggens konfigurerade FQDN. Omdirigeringsnamnet för transparent Kerberos måste matcha det HTTP-SPN som registrerats i AD och kunna lösas upp i DNS.

2. Under Administration > Admin and user settings anges Redirection Location så att klienterna kan slå upp namnet och lita på målet. I transparenta Kerberos-scenarier måste namnet matcha SPN. Ett konto med läsåtkomst till AD kan köra följande riktade och skrivskyddade fråga på ett Windows-system:

   setspn -Q HTTP/fw01.corp.example.com
   

   Ersätt exempelvärdet med den egna omdirigerings-FQDN:en. Resultatet måste visa exakt förväntat SPN och förväntat datorobjekt; ingen träff eller en träff på ett annat objekt ska utredas med AD-ansvarig före driftsättning.

3. Spara AD-servern under Authentication > Servers och kör Test connection. Testet kontrollerar anslutning och inloggningsuppgifter, men bevisar ännu inte att AD SSO fungerar.

4. Under Authentication > Services placeras AD-servern på önskad position i Firewall authentication methods. AD SSO använder servrarna i denna ordning och faller först tillbaka till nästa server om den föregående inte kan nås.

5. Under Administration > Device access aktiveras AD SSO för de zoner som behövs. Vanligtvis är det LAN eller ett tydligt definierat internt klientnät, inte alla zoner.

6. Under Authentication > Web authentication väljs Kerberos & NTLM eller medvetet NTLM only vid If Active Directory (AD) SSO is configured.

7. I berörda firewall-regler kontrolleras om Match known users och, för okända webbförfrågningar, Use web authentication for unknown users passar det önskade flödet. En separat och tydligt namngiven regel för HTTP och HTTPS är ofta enklare att drifta.

Under Authentication > Services bör HTTP challenge redirect on intranet zone vara aktiverat. Om en webbplats på internet utlöser en NTLM-challenge hanterar firewallen då utbytet via sitt lokala interface-IP i intranätzonen. Om alternativet stängs av kan webbläsaren skicka inloggningsuppgifter över internet. Det är inte en ofarlig kompatibilitetsinställning.

När Use web authentication for unknown users autentiserar HTTPS-trafik i transparent läge dekrypterar firewallen anslutningen för autentiseringen oberoende av inställningarna i firewall-regeln eller SSL/TLS Inspection-regeln. Det måste passa TLS Inspection- och certifikatdesignen; annars ser AD SSO snabbt ut som ett browser-, certifikat- eller webfilterproblem.

För validering är Log Viewer avgörande. Under Log viewer > Authentication bör starten av AD SSO-anslutningen visa meddelanden som Kerberos authentication initialized successfully och NTLM authentication channel established successfully. Meddelanden som Cannot initialize Kerberos authentication eller Cannot establish NTLM authentication channel är problematiska. Kolumnen Log Comp visar dessutom om en klient använder Kerberos eller NTLM.

Sophos Firewall erbjuder inte någon av metoderna till webbläsaren förrän både Kerberos och NTLM har initierats korrekt på brandväggen. En synlig övergång till NTLM är därför inget skäl att hoppa över Kerberos-kontrollen. DNS, SPN och systemtid måste stämma överens; som standard får de klockor som ingår i Kerberos inte skilja sig med mer än fem minuter.

Kontorollerna måste hållas isär. LDAP-bindkontot behöver bara de läsrättigheter som krävs för katalogfrågor. Själva domänanslutningen för AD SSO kräver däremot ett Domain Admin-konto eller ett konto med delegerad rätt att skapa datorobjektet eller SPN. I HA-miljöer, med flera AD-servrar eller efter en uppgradering kan en ny domänanslutning krävas; lämpliga anslutningsuppgifter måste därför finnas tillgängliga utan att LDAP-bindkontot ges dessa utökade rättigheter.

Sedan SFOS 21.5 MR1 stöds Windows Server 2025 vid Active Directory SSO med NTLM och Kerberos. SFOS 22 ger dessutom uppdaterade Samba-komponenter och tar bort äldre krypteringsmetoder. För administratörer betyder det:

• Testa AD SSO riktat efter Domain Controller-upgrades.
• Kontrollera autentisering och användartilldelning efter SFOS-upgrades.
• Dokumentera Kerberos-/NTLM-beroenden i gamla miljöer.
• Planera inte föråldrad kryptering som permanent lösning.
• Kontrollera DNS request routes för AD-domäner om firewallen inte hittar AD service records via normal resolver.
• Förväxla inte SSO med Entra ID SSO för Sophos Connect.

Om Entra ID SSO planeras för VPN eller VPN Portal bör man använda den separata artikeln Konfigurera Microsoft Entra ID SSO för Sophos Connect och VPN Portal. Det är en annan autentiseringsmodell än klassisk lokal AD-anslutning.

Troubleshooting

Anslutningstest misslyckas

Kontrollera först nåbarhet, port, routing och DNS. Kontrollera därefter anslutningssäkerhet, certifikat, servicekonto och lösenord.

Praktiska kontroller:

• Kan firewallen nå Domain Controller via IP?
• Löses DNS-namnet upp korrekt?
• Är port 389 eller 636 nåbar?
• Passar SSL/TLS verkligen till port och certifikat?
• Är servicekontot aktivt och inte spärrat?
• Finns Windows-side firewall-regler eller LDAP Signing-krav?

Användare hittas inte

Då är sökbasen ofta fel eller för snäv. Kontrollera OU:ns distinguishedName och säkerställ att användaren verkligen ligger inom sökbasen. Även stavning, svenska tecken, specialtecken och valt visningsattribut kan försvåra sökningen.

Grupp importeras men åtkomst fungerar inte

Då bör man kontrollera behörighetskedjan: AD-grupp, importerad firewall-grupp, tilldelad VPN-/Portal-/Firewall-regel, MFA och regelposition. Vid Remote Access måste dessutom passande VPN-konfiguration vara kopplad till gruppen.

Om användaren finns i flera AD-grupper, kontrollera dessutom Main Group under Authentication > Users. Särskilt MFA, Remote access IPsec VPN, WAF, Hotspots och flera användarrelaterade inställningar beaktar bara Main Group.

Nya AD-användare kan inte logga in på VPN Portal

Om en befintlig AD-användare kan använda VPN Portal men en nyskapad användare med jämförbar behörighet inte kan det, bör man först jämföra grupptilldelning, Remote Access-metod och firmwareversion. Under Authentication > Users visar Group Main Group; andra importerade grupper visas under Other group memberships. SSL VPN kan beakta flera gruppmedlemskap, medan IPsec Remote Access endast beaktar Main Group eller en uttryckligen vald användare.

För diagnos:

1. Jämför den berörda nya användaren med en fungerande befintlig användare.
2. Kontrollera Main Group och Other group memberships.
3. Kontrollera VPN portal authentication methods under Authentication > Services, tillåten källzon under Administration > Device access och användaren eller gruppen i Remote Access-policyn.
4. Anteckna SFOS-version och build.

Med NC-180824 har Sophos åtgärdat ett fel som gjorde att nya AD-användare från en Secondary AD Group inte kunde logga in på VPN Portal. Korrigeringen ingår i SFOS 22.0 MR2 Build 546 från 14 juli 2026. Sophos anger varken någon introduktionsversion eller någon officiell workaround. Om konfigurationen och grupplogiken stämmer bör man därför uppdatera en berörd äldre installation till SFOS 22.0 MR2 eller senare och därefter testa med en AD-användare som loggar in på firewallen för första gången och vars VPN-behörighet endast ges via den berörda Secondary Group i en SSL-VPN-policy.

⚠️ Ändra inte gruppordningen på måfå, rensa inte användare i förtid med Purge AD users och skapa inte om grupper. Sophos dokumenterar inte dessa åtgärder som lösning för NC-180824, och de kan ändra andra behörigheter.

Ny AD-grupp visas inte automatiskt

Nyskapade AD-grupper synkroniseras inte automatiskt till firewallen. Gruppen måste importeras igen via importguiden eller skapas manuellt som passande grupp. Därefter bör en testanvändare logga in på nytt så att firewallen utvärderar gruppmedlemskapen igen.

Användare togs bort i AD men syns fortfarande på firewallen

AD-användare som redan har loggat in kan fortsätta synas på firewallen. Om användare har tagits bort i AD bör man först ta bort dem i AD och därefter använda Purge AD users på firewallen. I HA-miljöer görs detta på Primary-enheten.

Login fungerar men användarregel träffar inte

Då är LDAP oftast inte själva problemet, utan användartilldelning, SSO, regelposition eller logging. I Log Viewer bör det synas om traffic värderas med användaridentitet eller bara med IP-adress. För regelanalys passar Testa firewall-regel med Log Viewer, Policy Test och Packet Capture.

AD SSO faller tillbaka till Captive Portal eller NTLM

Om AD SSO inte fungerar transparent är oftast Redirection URL, SPN, DNS-upplösning eller webbläsarens förtroende inblandade. För Kerberos måste namnet som brandväggen omdirigerar till höra till rätt HTTP-SPN och kunna lösas av klienten. För NTLM måste webbläsaren behandla målnamnet som betrott, annars frågar den efter inloggningsuppgifter eller går vidare till Captive Portal.

I praktiken kontrollerar man först Administration > Admin and user settings, DNS-upplösningen för omdirigeringsnamnet, setspn -Q HTTP/fw01.corp.example.com på en Windows-klient och Log viewer > Authentication. Om bara NTLM visas i stället för Kerberos är det ofta ett tecken på problem med SPN eller webbläsarens förtroende, inte nödvändigtvis på en trasig AD-serveranslutning.

Certifikatet som valts under Admin console and end-user interaction > Certificate måste omfatta redirect-hostnamnet eller FQDN och vara betrott av klienterna. Brandväggens förinstallerade självsignerade certifikat uppfyller normalt inget av kraven för ett nykonfigurerat namn. En certifikatvarning ska inte ignoreras utan lösas med ett matchande offentligt eller internt certifikat.

För NTLM kan förtroendet begränsas till det interna redirect-namnet. Microsoft Edge och Google Chrome i Windows ärver inställningen från Internet Options > Security > Local intranet > Sites > Advanced. I Firefox läggs samma FQDN till i network.automatic-ntlm-auth.trusted-uris under about:config. Tillåt bara det interna namnet som faktiskt används, inte en bred domän eller godtyckliga webbplatser.

Efter en upgrade fungerar enskilda logins inte längre

Efter SFOS- eller Domain Controller-upgrades bör man särskilt titta på SSO, Kerberos/NTLM, gamla krypteringsmetoder, certifikat och gruppimport. Om bara vissa användare berörs bör man dessutom kontrollera specialtecken, blanksteg, UPN, gruppmedlemskap och lösenordsstatus.

För autentiserings- och serviceloggar hjälper Sophos Firewall Troubleshooting: Services och Logs.

Anslutning fungerar inte med aktiverad certifikatkontroll

Om Validate server certificate är aktiverat måste certifikat, CNAME, DNS-upplösning och CA-förtroende passa ihop. Vanliga orsaker är ett certifikat med annat namn, en saknad intern CA på firewallen eller en CNAME som firewallen inte kan lösa upp.

Återställ ändringen och fortsätt driften säkert

Dokumentera serverordning, använda tjänster, grupper och certifikatinställningar före ändringen. Om acceptanstestet misslyckas återställs först den tidigare ordningen samt den ursprungliga krypterade anslutningsmetoden och porten. Plaintext på port 389 får endast användas för kortvarig diagnostik och ska aldrig lämnas kvar som produktionsåterställning.

Om hela konfigurationen måste återställas kan den tidigare hämtade säkerhetskopian återläsas under Backup and firmware > Backup and restore. Det ersätter aktuell konfiguration, tar bort senare ändringar och startar om brandväggen, så åtgärden hör hemma i ett underhållsfönster. En återställning av firmware startar den föregående partitionen med dess konfiguration och avslutar också sessioner. Automatisk firmwareåterställning används bara när konfigurationsmigreringen misslyckas, inte när ett AD SSO-fel visar sig först under drift.

Efter varje återställning kontrolleras Test connection, en normal tjänsteinloggning, gruppeffekten och, för SSO, en verklig användaråtkomst tillsammans med Log viewer > Authentication på nytt. I HA-miljöer importeras grupper och Purge AD users körs på Primary-enheten. Ett bortfallstest av avsedd sekundär domänkontrollant utförs endast i ett godkänt underhållsfönster, där man bekräftar att den första servern verkligen inte kan nås och att inloggning via den andra lyckas.

Driftchecklista

Före konfiguration:

• Domain Controller, port och DNS-namn är fastställda.
• LDAPS och certifikatkedja är kontrollerade.
• Dedikerat servicekonto är skapat.
• Sökbas och relevanta grupper är definierade.
• MFA- och Remote Access-design är klarlagd.

Efter konfiguration:

• Anslutningstest lyckades.
• AD-server är införd som primär eller passande Authentication Method.
• Testanvändare och testgrupp är kontrollerade.
• AD-grupper är importerade via importguiden.
• Main Group för en testanvändare är kontrollerad.
• Vid flera grupper: inloggning på VPN Portal har testats med en befintlig användare och en användare som loggar in på firewallen för första gången och vars VPN-behörighet endast ges via en Secondary Group i en SSL-VPN-policy.
• Remote Access, Portal eller användarregel är testad med normal användare.
• Log Viewer visar förväntade autentiseringsevents.
• Vid AD SSO har Kerberos-/NTLM-meddelandena i autentiseringsloggen kontrollerats.
• Servicekontots lösenordsutgång är dokumenterad.
• Upgrade-test för AD SSO, gruppimport och VPN-processer är planerat.

I drift:

• Ta bort grupper som inte längre behövs.
• Importera nya AD-grupper aktivt, vänta inte på automatisk synkronisering.
• Kontrollera servicekontot regelbundet.
• Förnya LDAPS-certifikat före utgång.
• Kontrollera gruppordning efter AD-ändringar.
• Använd Named Admins och MFA för administrativa åtkomster.
• Behandla inte autentiseringsfel bara som användarproblem, utan kontrollera även AD, nätverk, certifikat och firewall-regler.

FAQ