Active Directory met Sophos Firewall verbinden
Active Directory is in veel Sophos Firewall-omgevingen nog steeds de centrale bron voor gebruikers, groepen en authenticatie. De firewall gebruikt de AD-koppeling bijvoorbeeld voor gebruikersregels, Remote Access VPN, Captive Portal, User Portal, reporting of Single Sign-On-scenario’s.
Dit artikel legt uit hoe men een Active Directory-server op Sophos Firewall toevoegt, welke velden echt belangrijk zijn en hoe men de verbinding daarna controleert. Voor nieuwe Remote Access-ontwerpen moet men daarnaast beslissen of klassiek AD, RADIUS of Microsoft Entra ID SSO voor Sophos Connect en VPN Portal beter past.
De volgende Sophos Techvids-video toont het basisproces als visuele aanvulling. De video is met SFOS v21 gemaakt. De logica blijft nuttig, maar afzonderlijke schermen kunnen in SFOS 22 licht anders uitzien.
De praktische aanpak bestaat uit vier delen. Een succesvolle verbindingstest is slechts het begin; VPN, portal, gebruikersregels en SSO moeten apart worden gevalideerd.
- Server toevoegen: Domain controller, NetBIOS-domein, zoekbasis en serviceaccount correct invullen.
- Verbinding beveiligen: LDAPS, certificaatcontrole en interne DNS-resolutie bewust plannen.
- Groepen importeren: Alleen benodigde AD-groepen importeren en Main Group begrijpen.
- Gebruik testen: Login, MFA, VPN, User Portal, Captive Portal, SSO en Log Viewer controleren.
Inleiding
De Sophos Firewall kan meerdere authenticatiebronnen gebruiken. Active Directory is zinvol wanneer gebruikers en groepen al lokaal in een Windows-domein worden beheerd en de firewall deze identiteiten rechtstreeks moet gebruiken.
Typische toepassingen:
- gebruikers- en groepssynchronisatie uit het lokale Active Directory
- firewallregels op basis van gebruikers of groepen
- Remote Access VPN met AD-gebruikers
- User Portal of Captive Portal met domeinaccounts
- reporting per gebruiker in plaats van alleen per IP-adres
- Active Directory SSO met NTLM of Kerberos
Een AD-koppeling betekent echter niet automatisch dat elke authenticatievraag is opgelost. Men moet onderscheiden of de firewall gebruikers alleen via LDAP/LDAPS opvraagt, of groepen worden geïmporteerd, of SSO wordt gebruikt en of Remote Access daarnaast MFA nodig heeft. Voor MFA-basisprincipes past MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren.
Belangrijke beslissingen vóór de configuratie
Vóór het toevoegen van de server moeten deze punten duidelijk zijn:
- Verbinding: Gebruik indien mogelijk LDAPS met
SSL/TLSop poort636. - Serviceaccount: Gebruik een dedicated AD-account met leesrechten in plaats van Domain Admin.
- Zoekbasis: Doorzoek alleen benodigde OUs, niet blind het volledige domein.
- Weergave-attribuut: Kies
sAMAccountName,userPrincipalNameofdisplayNamebewust. - Groepen: Importeer alleen groepen die echt nodig zijn voor firewall, VPN of portal.
- MFA: Beveilig Remote Access en portals aanvullend met MFA.
- Servervolgorde: Leg bij meerdere AD-servers de queryvolgorde bewust vast.
- Beheer: Controleer Auth-logs, groepsimport, certificaten en wachtwoordverloop regelmatig.
⚠️ De verbinding tussen firewall en authenticatieserver moet versleuteld zijn. Onversleuteld LDAP op poort
389kan in labs functioneren, maar is geen goede permanente oplossing voor productieomgevingen.
Voor AD-integratie worden ook oudere Windows Server-versies ondersteund. In actuele omgevingen zijn vooral Windows Server 2016, 2019, 2022 en 2025 relevant. Sinds SFOS 21.5 MR1 is Active Directory SSO met Windows Server 2025 voor NTLM en Kerberos mogelijk. SFOS 22 bevat bijgewerkte Samba-componenten voor Kerberos- en NTLM-authenticatie en verwijdert oudere versleutelingsmethoden. Juist na firewall- of domain-controller-upgrades moet men AD SSO, groepsimport en Remote Access daarom gericht testen.
Belangrijk: strikte afdwinging van LDAP Channel Binding en LDAP Signing wordt door Sophos Firewall momenteel niet ondersteund. Wanneer domain controllers zeer strenge LDAP-beveiligingsinstellingen afdwingen, moet men de AD-koppeling daarom vóór een productieve wijziging in een onderhoudsvenster testen.
Active Directory-server toevoegen
De configuratie gebeurt in de WebAdmin van de Sophos Firewall:
Authentication > Servers
Daar wordt met Add een nieuwe authenticatieserver aangemaakt en als Server Type Active Directory gekozen.
Velden van de Active Directory-configuratie
De nummering in de screenshot is bewust zo gekozen: de belangrijkste velden worden van boven naar beneden uitgelegd. Afhankelijk van de SFOS-versie kan de volgorde licht verschillen. In nieuwere versies ziet men bovendien Validate server certificate wanneer certificaatcontrole voor LDAPS moet worden geactiveerd.
- Server type: Voor een klassiek Windows-domein gebruikt men Active Directory. Andere servertypes zoals RADIUS, LDAP of Microsoft Entra ID zijn andere integratiemodellen en moeten niet worden vermengd.
- Server name: Interne weergavenaam op de firewall. De naam heeft geen invloed op DNS of AD, maar moet duidelijk zijn, bijvoorbeeld
AD-ZH-DC01ofAD-HQ-LDAPS. Bij meerdere domain controllers helpt een nette naam later in de Log Viewer en bij troubleshooting. - Server IP/domain: IP-adres of DNS-naam van de domain controller. Een DNS-naam is netter wanneer certificaat, interne DNS-resolutie en failover daarbij passen. Een IP-adres is eenvoudiger te debuggen, maar bindt de firewall direct aan een specifieke domain controller.
- Port: Poort voor de LDAP-verbinding. Voor productieomgevingen is
636metSSL/TLSde voorkeursvariant.389wordt voor onversleuteld LDAP of STARTTLS gebruikt, maar moet geen permanente oplossing zijn wanneer gebruikersauthenticatie productief wordt gebruikt. - NetBIOS domain: Korte NetBIOS-naam van het AD-domein, bijvoorbeeld
AVANET. Deze waarde is niet de DNS-domeinnaam. Foutieve NetBIOS-waarden zorgen er vaak voor dat gebruikers wel bestaan, maar niet correct worden gevonden of toegewezen. - ADS user name: Gebruikersnaam van het serviceaccount waarmee de firewall AD-query’s uitvoert. Gebruik hiervoor een dedicated account met leesrechten, geen Domain Admin. Afhankelijk van de omgeving werkt de korte logonnaam,
DOMAIN\userof een UPN zoalssvc-firewall-ldap@example.local. - Password: Wachtwoord van het serviceaccount. Wanneer dit wachtwoord verloopt of wordt gewijzigd, werken gebruikersopvragingen, groepsimport, VPN-logins of portal-logins plots niet meer. Daarom moet het account gedocumenteerd en gemonitord worden.
- Connection security: Bepaalt of en hoe de verbinding wordt beveiligd. Voor LDAPS gebruikt men SSL/TLS met poort
636. STARTTLS gebruikt normaal poort389, maar vereist dat de domain controller STARTTLS correct aanbiedt. Simple is onversleuteld en mag hoogstens voor tests worden gebruikt. - Display name attribute: AD-attribuut dat de firewall als weergavenaam gebruikt. Veelgebruikte waarden zijn
sAMAccountName,userPrincipalName,displayNameofname. Voor beheer en troubleshooting is een eenduidig attribuut belangrijker dan een mooi leesbare naam. - Email address attribute: Attribuut voor het e-mailadres. Meestal is dit
mail. Het veld is alleen nuttig als e-mailadressen in AD echt worden onderhouden. Anders ontstaan lege of inconsistente gebruikersinformatie. - Domain name: DNS-naam van het AD-domein, bijvoorbeeld
example.localofad.example.com. Deze waarde is niet de NetBIOS-naam. Hij moet passen bij het domein, de zoekbasis en de gebruikte domain controller. - Search queries: Zoekbasis voor gebruikers- en groepsquery’s. Hier vult men Distinguished Names in zoals
DC=example,DC=localof specifiekerOU=Users,OU=Company,DC=example,DC=local. Hoe gerichter de zoekbasis wordt gekozen, hoe overzichtelijker en performanter de import blijft.
Wanneer er meerdere domain controllers zijn, moet men bewust beslissen of de firewall een specifieke DC aanspreekt of dat een stabiele interne DNS-naam naar een geschikte AD-infrastructuur verwijst. Belangrijk is dat DNS-resolutie, certificaat, routing en firewallregels bij elkaar passen.
Validate server certificate
In actuele SFOS-versies kan aanvullend Validate server certificate worden geactiveerd. Dat is zinvol voor LDAPS, omdat de firewall dan niet alleen versleuteld verbindt, maar ook controleert of hij het certificaat van de domain controller vertrouwt.
Daarvoor moeten deze punten kloppen:
- De uitgevende CA van het domain-controller-certificaat is op de firewall onder Certificates > Certificates bekend.
- De waarde in Server IP/domain past bij de certificaatnaam of bij een Subject Alternative Name van het certificaat.
- Als een CNAME wordt gebruikt, kan de firewall deze naam intern resolven.
- Datum en tijd op firewall en domain controller kloppen.
Als de interne DNS-resolutie een CNAME of de domain-controller-naam niet correct oplost, kan een DNS Host Entry onder Network > DNS > DNS host entry helpen.
NetBIOS-domein en domeinnaam
De Sophos Firewall heeft zowel gegevens over het NetBIOS-domein als over de domeinnaam nodig. Deze waarden moeten exact bij het AD-domein passen.
Het NetBIOS-domein vindt men bijvoorbeeld in Active Directory Users and Computers via de eigenschappen van het domein.
De domeinnaam is de DNS-naam van het domein, bijvoorbeeld example.local of ad.example.com.
Typische fouten op dit punt:
- NetBIOS-naam en DNS-domeinnaam worden verwisseld.
- De ingevoerde domain controller hoort bij een ander domein.
- De firewall kan de DNS-naam van de domain controller niet resolven.
- Tussen firewall en domain controller blokkeert een netwerk- of Windows-firewall de verbinding.
Serviceaccount en wachtwoord
Voor toegang tot Active Directory moet een dedicated serviceaccount worden gebruikt. Een Domain Admin-account is voor normale LDAP-query’s niet nodig en verhoogt het risico onnodig.
Zinvolle richtlijnen:
- eigen account voor de firewall, bijvoorbeeld
svc-sophos-fw-ldap - alleen benodigde leesrechten
- gedocumenteerde owner voor wachtwoordwijzigingen
- lang, uniek wachtwoord
- geen interactieve aanmelding, als de AD-richtlijnen dat netjes kunnen afdwingen
- monitoring of herinnering vóór wachtwoordverloop
Wanneer het wachtwoord van het serviceaccount verloopt of wordt gewijzigd, kan de firewall geen gebruikers en groepen meer opvragen. Dat verschijnt later vaak als VPN-, portal- of gebruikersregelprobleem, hoewel de echte oorzaak in de AD-koppeling ligt.
Verbindingsbeveiliging en LDAPS
Voor productieomgevingen moet men LDAPS verkiezen. Daarvoor heeft de domain controller een passend certificaat nodig en moet de firewall de uitgevende CA vertrouwen.
Te controleren punten:
- Poort
636is vanaf het firewallinterface naar de domain controller bereikbaar. - Het certificaat van de domain controller is geldig.
- De certificaatnaam past bij de gebruikte DNS-naam.
- De uitgevende CA is op de firewall bekend, als controle vereist is.
- Tijd en datum op firewall en domain controller kloppen.
Bij certificaatthema’s is ook CA-distributie relevant. Voor de distributie van de Sophos Firewall-CA naar clients past Sophos Firewall CA-certificaat voor HTTPS Scanning distribueren. Voor LDAPS is daarentegen vooral de CA van de domain controller of de interne PKI belangrijk.
Weergave-attribuut en e-mailattribuut
Het weergave-attribuut bepaalt hoe gebruikers in de Sophos Firewall worden getoond. Typische waarden zijn:
sAMAccountNameuserPrincipalNamedisplayNamename
sAMAccountName is in klassieke AD-omgevingen vaak robuust en kort. userPrincipalName sluit beter aan bij moderne loginnamen en cloud-identiteiten. displayName is voor mensen goed leesbaar, maar niet altijd eenduidig genoeg voor beheer en troubleshooting.
De attributen kan men in Active Directory Users and Computers controleren wanneer Advanced Features is ingeschakeld.
Het e-mailattribuut is meestal mail. Het is vooral relevant wanneer de firewall gebruikers e-mailgerelateerde informatie moet kunnen toewijzen.
Zoekbasis en groepen
De zoekbasis bepaalt welk deel van Active Directory de firewall doorzoekt. Voor een volledig domein is dit een voorbeeld:
DC=example,DC=local
Voor één OU kan het pad er bijvoorbeeld zo uitzien:
OU=Users,OU=Company,DC=example,DC=local
De Distinguished Name van een OU vindt men in Active Directory Users and Computers in de attributen van de OU.
Een te brede zoekbasis werkt vaak wel, maar maakt de configuratie minder overzichtelijk. Voor productieomgevingen is beter:
- dedicated OU of duidelijke zoekbasis voor relevante gebruikers
- aparte AD-groepen voor VPN, portals of firewallregels
- geen willekeurig hergebruik van grote afdelingsgroepen
- groepsimport na wijzigingen testen
- oude of lege groepen regelmatig verwijderen
Te brede groepsimports kunnen op lange termijn ook het interne gebruikersbeheer van de firewall belasten. Als zeer veel oude gebruikers of groepen ontstaan en VPN Portal-downloads later onverwacht mislukken, helpt een controle van de Sophos Firewall User-ID-limiet.
Belangrijk bij Remote Access: Sophos heeft in SFOS 21.5 MR1 aangepast dat L2TP en PPTP bij het importeren van groepen uit Active Directory en Microsoft Entra ID niet meer automatisch worden geactiveerd. Dat verkleint ongewenste aanvalsvlakken, maar moet na upgrades worden gecontroleerd wanneer oude Remote Access-processen daarop vertrouwden.
Groepen importeren en gebruikers begrijpen
Na het toevoegen van de AD-server zijn AD-groepen niet automatisch volledig op de firewall aanwezig. Groepen worden via de importassistent geïmporteerd:
Authentication > Servers > Import
De procedure is:
- AD-server selecteren en Import starten.
- Base DN voor de groepszoekopdracht selecteren.
- Benodigde AD-groepen selecteren.
- Gemeenschappelijke group policies controleren.
- Selectie controleren en import afronden.
- Onder Authentication > Groups controleren of de groepen correct aanwezig zijn.
Gebruikers verschijnen onder Authentication > Users pas wanneer ze zich bij een dienst aanmelden, bijvoorbeeld bij User Portal, VPN Portal, Captive Portal of via Remote Access VPN. Bij elke aanmelding controleert de firewall opnieuw welke geïmporteerde groepen bij de gebruiker passen en werkt hij de toewijzing bij.
Als een gebruiker in geen enkele geïmporteerde AD-groep wordt gevonden, komt hij in de Default Group terecht. Deze Default Group ziet men onder Authentication > Services bij de Firewall Authentication Methods. Standaard is dat vaak de Open group.
In HA-omgevingen importeert men AD-groepen op het Primary-apparaat. Dat geldt ook voor het opruimen van oude AD-gebruikers met Purge AD users.
Main Group, groepsvolgorde en geneste groepen
Een AD-gebruiker kan in meerdere groepen zitten. De Sophos Firewall maakt daarbij onderscheid tussen:
- Group: De eerste passende groep in de firewall-groepslijst. Dit is de Main Group van de gebruiker.
- Other group memberships: Andere geïmporteerde groepen waarvan de gebruiker eveneens lid is.
- Group order: Volgorde onder Authentication > Groups. Deze waarde bepaalt welke groep bij meerdere matches de Main Group wordt.
Dit is belangrijk omdat niet alle functies meerdere groepen evalueren. Sommige functies gebruiken alleen de Main Group. Wanneer een gebruiker in meerdere AD-groepen zit, kan daardoor een andere policy gelden dan verwacht.
De groepsvolgorde wijzigt men hier:
Authentication > Groups > Reorder
Geneste AD-groepen worden niet ondersteund. Als een firewallpolicy voor een subgroep moet gelden, moet deze subgroep zelf worden geïmporteerd. Het is niet genoeg om alleen de bovenliggende AD-groep te importeren.
De primaire AD-groep van een gebruiker wordt eveneens niet als normale groepslidmaatschap overgenomen. Dit raakt vooral de AD-standaardgroep Domain Users. Voor firewallpolicies moet men daarom expliciete security groups gebruiken en gebruikers rechtstreeks aan deze groepen toevoegen.
Welke functies meerdere groepen ondersteunen
Voor het beheer is dit onderscheid bijzonder belangrijk.
Meerdere AD-groepen kunnen worden meegenomen bij:
- Firewall rules: De volgorde van de firewallregels blijft doorslaggevend.
- SSL/TLS inspection rules: De eerste passende inspection rule wordt toegepast.
- Web policies: Eerst matcht de firewallregel, daarna de passende Web Policy-regel.
- IPS policies: De policy uit de passende regel wordt toegepast.
- Application control policies: De evaluatie gebeurt via de passende firewallregel.
- SD-WAN routes: Gebruikers- of groepscriteria kunnen meerdere groepen meenemen.
- Policy test: Nuttig om groep- en policy-matching te controleren.
- Remote access SSL VPN: Rechten uit passende Full- en Split-Tunnel-policies worden meegenomen. Bij Full Tunnel heeft Full Tunnel voorrang.
- Clientless SSL VPN: Rechten uit passende groepen worden gecombineerd.
Alleen Main Group of expliciete gebruikers worden meegenomen bij:
- WAF rules
- Remote access IPsec VPN
- L2TP en PPTP
- Hotspots
- MFA, wanneer MFA gericht op groepen wordt toegepast
- Surfing quota, Access time, Network traffic en Traffic shaping
- Quarantine digest, MAC binding en Sign-in restriction
Praktijkvoorbeeld: een gebruiker is lid van VPN-Users en Firewall-Admins. Voor SSL VPN kan het meervoudige lidmaatschap werken. Voor IPsec Remote Access of MFA-groepstoewijzing kan echter alleen de Main Group tellen. Daarom moet men bij Remote Access en administratieve toegangen bewust testen welke groep in het gebruikersobject als Group is ingesteld.
Meerdere Active Directory-servers
Men kan meerdere AD-servers configureren. De firewall valideert gebruikers dan in de volgorde die in WebAdmin is geconfigureerd. Dat is geen vervanging voor een goed gepland AD-design.
Aanbevelingen:
- Servervolgorde onder Authentication > Services bewust instellen.
- Per server zoekbasis en domein netjes documenteren.
- Geen tegenstrijdige groepen met dezelfde naam in verschillende bronnen gebruiken.
- Bij meerdere UPN’s of meerdere domeinen aparte DNS- en AD-configuraties netjes plannen.
- Failover niet alleen met Test connection, maar met een echte gebruikerslogin controleren.
- Bij uitval van een AD-server kan de foutmelding voor de gebruiker lijken op een verkeerd wachtwoord.
Als meerdere UPN’s bij dezelfde domeininfrastructuur horen, moeten DNS-records en AD-serverconfiguratie bij het betreffende domein passen. Belangrijk is dat zoekbasis, Domain Name en serverresolutie bij elkaar horen.
Verbinding testen
Na het opslaan moet de verbinding direct worden getest. De test controleert of de firewall de server bereikt en of de ingevoerde gegevens in principe kloppen.
Een succesvolle test betekent niet automatisch dat gebruikersregels, SSO of VPN al werken. Daarna moeten minimaal deze punten worden gecontroleerd:
- AD-gebruikers of groepen worden correct gevonden.
- Testgebruiker kan zich op de bedoelde plaats aanmelden.
- Groepslidmaatschap past bij de gewenste firewall- of VPN-rechten.
- Log Viewer toont begrijpelijke authenticatie-events.
- Remote Access VPN, User Portal of Captive Portal werken met een normale testgebruiker.
- MFA wordt gevraagd wanneer dit voor het scenario gepland is.
- De AD-server staat onder Authentication > Services op de gewenste positie binnen de Firewall Authentication Methods.
Voor Remote Access met Sophos Connect is Sophos Connect Client op Sophos Firewall configureren de volgende passende stap.
Validatie per toepassing
Na de AD-koppeling moet niet alleen één verbindingstest worden gedocumenteerd. Verschillende functies gebruiken de AD-integratie op verschillende manieren. Daarom moet men voor elke geplande toepassing een eigen test uitvoeren.
- Groepsimport: Relevante AD-groep zoeken en op de firewall importeren. Als iets niet klopt, wordt de groep niet gevonden of bevat hij onverwachte gebruikers.
- User Portal: Aanmelding met een normale AD-gebruiker testen. Een typisch foutbeeld is een mislukte login, hoewel de servertest succesvol was.
- Remote Access VPN: VPN-login, groepsrechten, MFA en toegang tot interne doelen controleren. Bij fouten authenticeert de gebruiker zich misschien, maar krijgt hij geen passende policy of geen toegang.
- Gebruikersgebaseerde firewallregel: Testverkeer genereren en Log Viewer op gebruiker, groep en Rule ID controleren. Als de toewijzing niet werkt, verschijnt verkeer alleen met IP-adres of raakt het een andere regel.
- Captive Portal: Browser-login en daaropvolgend verkeer testen. Fouten tonen zich vaak doordat de login werkt, maar de gebruiker daarna niet correct wordt toegewezen.
- AD SSO of STAS: Live Users en Log Viewer na Windows-aanmelding controleren. Bij problemen blijft de gebruiker onbekend of wordt hij aan een verkeerd IP-adres gekoppeld.
Deze scheiding bespaart tijd in de praktijk. Een succesvolle LDAP-test bewijst alleen dat server, poort, bind-account en zoekbasis in principe bereikbaar zijn. Hij bewijst niet dat VPN-groepen correct worden toegewezen, dat MFA werkt of dat gebruikersverkeer in firewallregels met identiteit wordt beoordeeld.
Voor gebruikersgebaseerde regels moet men altijd een echte verkeerstest uitvoeren en in de Log Viewer controleren of gebruikersnaam, groep, Firewall Rule ID en actie overeenkomen met de verwachting. Als alleen het IP-adres zichtbaar is, ligt de oorzaak vaak bij SSO, STAS, Captive Portal of bij de volgorde van de firewallregels. Voor STAS-omgevingen past STAS op Sophos Firewall instellen als vervolg.
Active Directory SSO aandachtspunten
Active Directory SSO is een eigen beheergebied. De zuivere AD-serververbinding is daarvoor een basis, maar SSO vereist daarnaast passende client-, browser-, DNS-, Kerberos- of NTLM-voorwaarden.
Voor Web Authentication ondersteunt Sophos Firewall klassiek AD SSO met Kerberos en NTLM. Kerberos is netter en sneller, maar stelt hogere eisen aan FQDN, DNS, SPN en browservertrouwen. NTLM is toleranter en kan in oude omgevingen een pragmatische fallback zijn, maar mag niet stilletjes de enige werkende methode worden.
De AD SSO-flow is daarom meer dan alleen Test connection op de AD-server:
- Onder Administration > Admin and user settings een hostname of FQDN instellen. Voor Kerberos gebruikt men een FQDN, in kleine letters en met een hostdeel van maximaal 15 tekens, zodat NetBIOS name, AD-computerobject en SPN niet uit elkaar lopen.
- Onder Administration > Admin and user settings de Redirection Location zo instellen dat clients de naam kunnen oplossen en het doel vertrouwen. In transparante Kerberos-scenario’s moet deze naam bij de SPN passen. Op een Windows-client helpt
setspn -Q HTTP/*om bestaande HTTP-SPN’s te controleren. - De AD-server onder Authentication > Servers opslaan en Test connection uitvoeren. Deze test controleert verbinding en toegangsgegevens, maar bewijst nog niet dat AD SSO werkt.
- Onder Authentication > Services de AD-server op de gewenste positie in Firewall authentication methods zetten. AD SSO gebruikt de servers in deze volgorde en valt pas terug op de volgende server als de vorige niet bereikbaar is.
- Onder Administration > Device access AD SSO activeren voor de benodigde zones. Meestal is dat LAN of een duidelijk gedefinieerd intern clientnetwerk, niet zomaar elke zone.
- Onder Authentication > Web authentication bij If Active Directory (AD) SSO is configured de methode Kerberos & NTLM of bewust NTLM only kiezen.
- In de passende firewallregels controleren of Match known users en bij onbekende webrequests Use web authentication for unknown users bij de gewenste flow passen. Een aparte duidelijk genoemde regel voor HTTP en HTTPS is vaak overzichtelijker.
Als Use web authentication for unknown users HTTPS-verkeer in transparante modus moet authenticeren, kan de firewall de verbinding voor het authenticatieproces ontsleutelen. Dat moet passen bij het TLS Inspection- en certificaatontwerp; anders lijkt AD SSO al snel op een browser-, certificaat- of webfilterprobleem.
Voor validatie is Log Viewer doorslaggevend. Onder Log viewer > Authentication moeten bij de start van de AD SSO-verbinding meldingen zoals Kerberos authentication initialized successfully en NTLM authentication channel established successfully verschijnen. Meldingen zoals Cannot initialize Kerberos authentication of Cannot establish NTLM authentication channel zijn problematisch. De kolom Log Comp laat bovendien zien of een client Kerberos of NTLM gebruikt.
De accountvraag is belangrijk. Voor normale LDAP-query’s is een Domain User met leesrechten vaak genoeg. Voor AD SSO moet de firewall echter toetreden tot het domein en een computerobject of SPN kunnen aanmaken. Daarvoor is een Domain Admin-account nodig of een account met correct gedelegeerde domain-join-rechten. In HA-omgevingen, bij meerdere AD-servers of na upgrades kan de firewall opnieuw moeten joinen. Daarom moet men niet eenmalig met Domain Admin joinen en daarna naar een zwakker account wisselen als dat account later geen rejoin mag uitvoeren.
Sinds SFOS 21.5 MR1 wordt Windows Server 2025 ondersteund bij Active Directory SSO met NTLM en Kerberos. SFOS 22 brengt bovendien bijgewerkte Samba-componenten en verwijdert oudere versleutelingsmethoden. Voor admins betekent dit:
- Na domain-controller-upgrades AD SSO gericht testen.
- Na SFOS-upgrades authenticatie en gebruikerstoewijzing controleren.
- Kerberos-/NTLM-afhankelijkheden in oude omgevingen documenteren.
- Verouderde versleuteling niet als permanente oplossing plannen.
- DNS request routes voor AD-domeinen controleren als de firewall AD-service-records niet via de normale resolver vindt.
- SSO niet verwarren met Entra ID SSO voor Sophos Connect.
Als Entra ID SSO voor VPN of VPN Portal gepland is, moet men het aparte artikel Microsoft Entra ID SSO voor Sophos Connect en VPN Portal instellen gebruiken. Dat is een ander authenticatiemodel dan klassieke lokale AD-koppeling.
Troubleshooting
Verbindingstest mislukt
Controleer eerst bereikbaarheid, poort, routing en DNS. Controleer daarna verbindingsbeveiliging, certificaat, serviceaccount en wachtwoord.
Praktische checks:
- Kan de firewall de domain controller per IP bereiken?
- Wordt de DNS-naam correct opgelost?
- Is poort
389of636bereikbaar? - Past
SSL/TLSecht bij poort en certificaat? - Is het serviceaccount actief en niet geblokkeerd?
- Zijn er aan Windows-zijde firewallregels of LDAP-Signing-vereisten?
Gebruiker wordt niet gevonden
Dan is vaak de zoekbasis fout of te beperkt. Controleer de distinguishedName van de OU en zorg ervoor dat de gebruiker echt binnen de zoekbasis ligt. Ook schrijfwijze, umlauten, speciale tekens en het gekozen weergave-attribuut kunnen de zoekopdracht bemoeilijken.
Groep wordt geïmporteerd, maar toegang werkt niet
Dan moet men de rechtenketen controleren: AD-groep, geïmporteerde firewallgroep, toegewezen VPN-/portal-/firewallregel, MFA en regelpositie. Bij Remote Access moet daarnaast de passende VPN-configuratie aan de groep gekoppeld zijn.
Als de gebruiker in meerdere AD-groepen zit, moet aanvullend de Main Group onder Authentication > Users worden gecontroleerd. Vooral MFA, Remote access IPsec VPN, WAF, Hotspots en meerdere gebruikersgerelateerde instellingen gebruiken alleen de Main Group.
Nieuwe AD-groep verschijnt niet automatisch
Nieuw aangemaakte AD-groepen worden niet automatisch naar de firewall gesynchroniseerd. De groep moet opnieuw via de importassistent worden geïmporteerd of handmatig als passende groep worden aangemaakt. Daarna moet een testgebruiker zich opnieuw aanmelden, zodat de firewall de groepslidmaatschappen opnieuw beoordeelt.
Gebruiker is in AD verwijderd, maar blijft zichtbaar op de firewall
AD-gebruikers die zich al hebben aangemeld, kunnen op de firewall zichtbaar blijven. Wanneer gebruikers in AD zijn verwijderd, moet men ze eerst in AD verwijderen en daarna op de firewall Purge AD users gebruiken. In HA-omgevingen doet men dat op het Primary-apparaat.
Aanmelding werkt, maar gebruikersregel matcht niet
Dan is meestal niet LDAP zelf het probleem, maar gebruikerstoewijzing, SSO, regelpositie of logging. In de Log Viewer moet zichtbaar zijn of het verkeer met gebruikersidentiteit of alleen met IP-adres wordt beoordeeld. Voor regelanalyse past Firewallregel testen met Log Viewer, Policy Test en Packet Capture.
AD SSO valt terug op Captive Portal of NTLM
Als AD SSO niet transparant werkt, zijn meestal Redirection URL, SPN, DNS-resolutie of browservertrouwen betrokken. Voor Kerberos moet de naam waarnaar de firewall omleidt bij de passende HTTP-SPN horen en door de client oplosbaar zijn. Voor NTLM moet de browser de doelnaam als vertrouwd behandelen, anders vraagt hij om toegangsgegevens of valt terug op het Captive Portal.
Praktisch controleert men eerst Administration > Admin and user settings, de DNS-resolutie van de redirectnaam, setspn -Q HTTP/* op een Windows-client en Log viewer > Authentication. Als alleen NTLM in plaats van Kerberos verschijnt, wijst dat vaak op een SPN- of browsertrustprobleem, niet per se op een defecte AD-serververbinding.
Na een upgrade werken afzonderlijke logins niet meer
Na SFOS- of domain-controller-upgrades moet men vooral letten op SSO, Kerberos/NTLM, oude versleutelingsmethoden, certificaten en groepsimport. Als slechts bepaalde gebruikers getroffen zijn, controleer dan aanvullend speciale tekens, spaties, UPN, groepslidmaatschappen en wachtwoordstatus.
Voor authenticatie- en servicelogs helpt Sophos Firewall Troubleshooting: Services en Logs.
Verbinding werkt niet met geactiveerde certificaatcontrole
Wanneer Validate server certificate is geactiveerd, moeten certificaat, CNAME, DNS-resolutie en CA-vertrouwen bij elkaar passen. Veelvoorkomende oorzaken zijn een certificaat met een andere naam, een ontbrekende interne CA op de firewall of een CNAME die de firewall niet kan resolven.
Beheerchecklist
Vóór de configuratie:
- Domain controller, poort en DNS-naam vastgelegd.
- LDAPS en certificaatketen gecontroleerd.
- Dedicated serviceaccount aangemaakt.
- Zoekbasis en relevante groepen gedefinieerd.
- MFA- en Remote Access-ontwerp duidelijk.
Na de configuratie:
- Verbindingstest succesvol.
- AD-server als primaire of passende Authentication Method ingevoerd.
- Testgebruiker en testgroep gecontroleerd.
- AD-groepen via de importassistent geïmporteerd.
- Main Group van een testgebruiker gecontroleerd.
- Remote Access, portal of gebruikersregel met normale gebruiker getest.
- Log Viewer toont verwachte authenticatie-events.
- Wachtwoordverloop van het serviceaccount gedocumenteerd.
- Upgrade-test voor AD SSO, groepsimport en VPN-processen ingepland.
In bedrijf:
- Niet meer benodigde groepen verwijderen.
- Nieuwe AD-groepen actief importeren, niet op automatische synchronisatie wachten.
- Serviceaccount regelmatig controleren.
- LDAPS-certificaten vóór afloop vernieuwen.
- Groepsvolgorde na AD-wijzigingen controleren.
- Named Admins en MFA voor administratieve toegang gebruiken.
- Authenticatiefouten niet alleen als gebruikersprobleem behandelen, maar ook AD, netwerk, certificaten en firewallregels mee controleren.
FAQ
Moet men LDAP of LDAPS voor Sophos Firewall gebruiken?
SSL/TLS verkiezen. LDAP op poort 389 is eenvoudiger, maar biedt zonder aanvullende beschermingsmaatregelen geen goede beveiligingsbasis voor een permanente AD-koppeling.