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.

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.

Inordning

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:

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

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.

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. Den utfärdande CA:n för Domain Controller-certifikatet är känd på firewallen under Certificates > Certificates.
2. Värdet i Server IP/domain passar certifikatnamnet eller ett Subject Alternative Name i certifikatet.
3. Om en CNAME används kan firewallen lösa upp detta namn 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 example.local eller 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 owner för lösenordsbyten
• långt, unikt lösenord
• ingen interaktiv inloggning om AD-policyerna kan avbilda det korrekt
• monitoring 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. Då behöver Domain Controller ett passande certifikat och firewallen måste lita på den utfärdande CA:n.

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.
• Utfärdande CA är känd på firewallen om kontroll krävs.
• Tid och datum på firewall och Domain Controller stämmer.

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.

Visningsattribut och e-postattribut

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

• sAMAccountName
• userPrincipalName
• displayName
• name

sAMAccountName är ofta robust och kort i klassiska AD-miljöer. userPrincipalName ligger närmare moderna login-namn och cloud identities. displayName är lättläst för människor, men inte alltid tillräckligt entydigt för drift och troubleshooting.

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=example,DC=local

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

OU=Users,OU=Company,DC=example,DC=local

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

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.

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 en användare inte hittas i någon importerad AD-grupp hamnar användaren i Default Group. Denna Default Group syns under Authentication > Services vid Firewall Authentication Methods. Standard är ofta Open group.

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.

Main Group, gruppordning och nästlade grupper

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

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 en normal 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 drift är denna tabell särskilt viktig:

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. Firewallen validerar då användare i den ordning som är konfigurerad i WebAdmin. Det ersätter inte en rent planerad AD-design.

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 failover inte bara med Test connection, utan med en verklig user login.
• 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.

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.

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.

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 träffar eller att user traffic värderas med identitet i firewall-regler.

För användarbaserade regler bör man alltid utlösa ett verkligt traffic-test 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 firewall-reglernas ordning. För STAS-miljöer passar Konfigurera STAS på Sophos Firewall som nästa artikel.

Beakta Active Directory SSO

Active Directory SSO är ett eget driftområde. Den rena AD-serveranslutningen är en grund, men SSO behöver dessutom passande client-, browser-, DNS-, Kerberos- eller NTLM-förutsättningar.

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 browser trust. NTLM är mer tolerant och kan vara en pragmatisk fallback i gamla miljöer, men bör inte tyst bli den enda metod som fungerar.

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

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.
2. Under Administration > Admin and user settings sätts Redirection Location så att klienter kan slå upp namnet och lita på målet. I transparenta Kerberos-scenarier måste detta namn matcha SPN. På en Windows-klient hjälper setspn -Q HTTP/* för att kontrollera befintliga HTTP-SPN.
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.

Om Use web authentication for unknown users ska autentisera HTTPS-trafik i transparent läge kan firewallen dekryptera anslutningen för autentiseringsprocessen. 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.

Kontofrågan är viktig. För vanliga LDAP-frågor räcker ofta en Domain User med läsrättigheter. För AD SSO måste firewallen däremot ansluta till domänen och kunna skapa ett datorobjekt eller SPN. Det kräver antingen ett Domain Admin-konto eller ett konto med korrekt delegerade domain-join-rättigheter. I HA-miljöer, med flera AD-servrar eller efter upgrades kan firewallen behöva ansluta till domänen igen. Därför bör man inte göra join en gång med Domain Admin och sedan byta till ett svagare konto om detta konto inte får göra rejoin senare.

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.

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 browser trust inblandade. För Kerberos måste namnet som firewallen omdirigerar till höra till rätt HTTP-SPN och kunna lösas av klienten. För NTLM måste browsern behandla målnamnet som betrott, annars frågar den efter inloggningsuppgifter eller faller tillbaka till Captive Portal.

I praktiken kontrollerar man först Administration > Admin and user settings, DNS-upplösning för redirect-namnet, setspn -Q HTTP/* på en Windows-klient och Log viewer > Authentication. Om bara NTLM visas i stället för Kerberos är det ofta ett tecken på SPN- eller browser trust-problem, inte nödvändigtvis på en trasig AD-serveranslutning.

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.

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.
• Remote Access, Portal eller användarregel är testad med normal användare.
• Log Viewer visar förväntade autentiseringsevents.
• 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