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.

Als Active Directory het doel van een bestaande eDirectory-omgeving wordt, plant men eerst de gecontroleerde eDirectory-migratie met groepscontrole, cutover per service en terugval.

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.

1. Server toevoegen: Domain controller, NetBIOS-domein, zoekbasis en serviceaccount correct invullen.
2. Verbinding beveiligen: LDAPS, certificaatcontrole en interne DNS-resolutie bewust plannen.
3. Groepen importeren: Alleen benodigde AD-groepen importeren en Main Group begrijpen.
4. 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/TLS op poort 636.
• 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, userPrincipalName of displayName bewust.
• 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.

Ook routing en het bronpad van de firewall naar de domain controller moeten vaststaan. Voor LDAPS is TCP 636 nodig, voor STARTTLS TCP 389; interne DNS-resolutie en een volledige, geldige certificaatketen moeten werken vanaf het pad dat de firewall werkelijk gebruikt. Maak vóór de wijziging onder Backup and firmware > Backup and restore een versleutelde configuratieback-up, download die en bewaar het back-upwachtwoord veilig.

⚠️ De verbinding tussen firewall en authenticatieserver moet versleuteld zijn. Onversleuteld LDAP op poort 389 kan 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.

1. 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.
2. Server name: Interne weergavenaam op de firewall. De naam heeft geen invloed op DNS of AD, maar moet duidelijk zijn, bijvoorbeeld AD-ZH-DC01 of AD-HQ-LDAPS. Bij meerdere domain controllers helpt een nette naam later in de Log Viewer en bij troubleshooting.
3. 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.
4. Port: Poort voor de LDAP-verbinding. Voor productieomgevingen is 636 met SSL/TLS de voorkeursvariant. 389 wordt voor onversleuteld LDAP of STARTTLS gebruikt, maar moet geen permanente oplossing zijn wanneer gebruikersauthenticatie productief wordt gebruikt.
5. 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.
6. ADS user name: Gebruikersnaam van het account waarmee de firewall AD-query’s uitvoert. Sophos gebruikt in het voorbeeld de korte naam administrator. Voor productie adviseert Avanet in plaats daarvan een dedicated serviceaccount dat mag zoeken, lezen en groepslidmaatschappen opvragen, geen Domain Admin-account. Sophos bevestigt niet in het algemeen dat korte naam, DOMAIN\user en UPN in elke configuratie gelijkwaardig zijn; gebruik en documenteer daarom het formaat dat in de eigen AD-omgeving is getest.
7. 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.
8. Connection security: Bepaalt of en hoe de verbinding wordt beveiligd. Voor LDAPS gebruikt men SSL/TLS met poort 636. STARTTLS gebruikt normaal poort 389, maar vereist dat de domain controller STARTTLS correct aanbiedt. Simple is onversleuteld en mag hoogstens voor tests worden gebruikt.
9. Display name attribute: AD-attribuut voor de naam die op de firewall wordt weergegeven. De waarde moet bij het eigen directoryschema passen en met een testgebruiker worden gecontroleerd; de algemene Sophos-handleiding beschrijft hier geen universeel uitwisselbare standaardwaarden. Voor Microsoft Entra Domain Services noemt Sophos uitdrukkelijk DisplayName.
10. 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.
11. Domain name: DNS-naam van het AD-domein, bijvoorbeeld ad.example.com. Deze waarde is niet de NetBIOS-naam. Hij moet passen bij het domein, de zoekbasis en de gebruikte domain controller.
12. Search queries: Zoekbasis voor gebruikers- en groepsquery’s. Hier vult men Distinguished Names in zoals DC=ad,DC=example,DC=com of specifieker OU=Users,OU=Company,DC=ad,DC=example,DC=com. Een gerichte OU beperkt de zichtbare gebruikersgroep en houdt de import overzichtelijk.

Alleen gebruikers die door minstens één Search query worden gevonden, kunnen voor deze AD-server onder Current activities > Live users verschijnen. Ontbreekt een verwachte gebruiker ondanks een geslaagde Test connection, controleer dan eerst of de Base DN en OU-scope het werkelijke directoryobject van die gebruiker omvatten. De zoekbasis wordt niet uit voorzorg naar het hele domein verbreed.

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:

1. Het servercertificaat van de domain controller wordt geüpload via Certificates > Certificates > Add > Upload certificate. Een los CA-certificaat wordt daarentegen onder Certificates > Certificate authorities geïmporteerd; deze twee lijsten mogen niet worden verwisseld.
2. Vul volgens de Sophos-instructie de CNAME in bij Server IP/domain; deze DNS-naam moet in de Subject Alternative Name van het servercertificaat staan.
3. De firewall kan de CNAME intern resolven.
4. 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 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 servercertificaat nodig. Wanneer Validate server certificate actief is, volgt men de hierboven beschreven Sophos-procedure om het servercertificaat te importeren; een aanvullend vereist CA-certificaat wordt apart als Certificate Authority geïmporteerd.

Te controleren punten:

• Poort 636 is vanaf het firewallinterface naar de domain controller bereikbaar.
• Het certificaat van de domain controller is geldig.
• De certificaatnaam past bij de gebruikte DNS-naam.
• Het servercertificaat en, indien nodig, de uitgevende CA zijn elk in de juiste certificaatlijst geïmporteerd.
• Tijd en datum op firewall en domain controller kloppen.

Er blijft een belangrijke productgrens: SFOS 22 ondersteunt momenteel geen strikte afdwinging van LDAP Channel Binding en LDAP Signing. LDAPS met certificaatvalidatie beveiligt de verbinding, maar bewijst niet dat aan een AD-beveiligingsbeleid met verplichte channel binding of signing wordt voldaan. Als de organisatie deze afdwinging vereist, moet de integratie vóór de uitrol tegen het concrete AD-beleid worden gevalideerd en niet alleen op basis van een geslaagde Test connection worden goedgekeurd.

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.

Microsoft Entra Domain Services verbinden

Een beheerd Microsoft Entra Domain Services-domein kan als Active Directory-server worden verbonden. Sophos noemt hiervoor WebAdmin, Captive Portal, User Portal, Client Authentication Agent en Remote Access SSL VPN. Dit is geen directe Entra ID-SSO-koppeling; uit deze documentatie volgt met name geen ondersteuning voor VPN Portal.

Activeer voor productie Secure LDAP en sta poort 636 toe vanaf het gekozen firewallpad naar het beheerde domein. Het servercertificaat heeft Extended Key Usage Server Authentication nodig. Maak LDAPS indien mogelijk niet openbaar bereikbaar, maar gebruik een privéverbinding via Azure-netwerken of IPsec en beperk de toegang in de Network Security Group tot het vereiste bronadres.

De officiële Sophos-voorbeeldconfiguratie gebruikt het openbare Secure LDAP-IP, SSL/TLS, poort 636, DisplayName en mail, en schakelt Validate server certificate uit. Een privéverbinding via Azure-netwerken of IPsec is Sophos’ aanvullende beveiligingsadvies. Certificaatvalidatie met een passende naam en een correcte vertrouwensketen is daarentegen een Avanet-hardeningvoorstel dat vóór productie in de eigen omgeving moet worden getest; het wordt niet als onderdeel van het officiële voorbeeld gepresenteerd. Entra-gebruikers moeten zich eerst aanmelden en hun wachtwoord wijzigen, zodat Kerberos-/NTLM-hashes worden aangemaakt en gesynchroniseerd; het bindaccount moet lid zijn van de geconfigureerde Entra Domain Services-beheerdersgroep.

Weergave-attribuut en e-mailattribuut

Het weergave-attribuut bepaalt hoe gebruikers in de Sophos Firewall worden getoond. Directory-attributen die men in de eigen omgeving kan aantreffen en vóór gebruik moet controleren, zijn onder meer:

• sAMAccountName
• userPrincipalName
• displayName
• name

Deze waarden zijn niet algemeen uitwisselbaar. Het directoryschema, de eenduidigheid en het resultaat met een testgebruiker zijn bepalend. Voor Entra Domain Services documenteert Sophos DisplayName; daaruit volgt geen algemene regel voor lokaal AD.

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

Voor één OU kan het pad er bijvoorbeeld zo uitzien:

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

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. L2TP Remote Access op Sophos Firewall instellen beschrijft de expliciete ledentoewijzing, de Main Group-grens en de validatie.

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:

1. AD-server selecteren en Import starten.
2. Base DN voor de groepszoekopdracht selecteren.
3. Benodigde AD-groepen selecteren.
4. Gemeenschappelijke group policies controleren.
5. Selectie controleren en import afronden.
6. 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 geen AD-groep van een gebruiker op de firewall bestaat, krijgt die gebruiker de onder Authentication > Services ingestelde Default group. De productstandaard is Open group. Controleer vóór de uitrol toch de effectieve waarde, omdat die gewijzigd kan zijn en rechtstreeks de overgenomen instellingen bepaalt.

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.

De volledige beheer- en testprocedure voor groepsbeleid, Default Group, hoofdgroep, gebruikersoverrides en functieafhankelijk gedrag van meerdere groepen staat in Sophos Firewall-gebruikersgroepen en de hoofdgroep correct beheren.

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

Sophos Firewall Access Time voor gebruikers en groepen laat zien hoe men de hoofdgroep voor tijdafhankelijke gebruikerstoegang controleert en gebruikersuitzonderingen afbakent.

Dezelfde Main Group-grens geldt voor verbruiksafhankelijke tijd- en datategoeden. Surfing Quota en Network Traffic Quota op Sophos Firewall beschrijft het volledige proces.

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. Voor Firewall authentication methods geldt een belangrijke semantiek: de firewall gaat alleen naar de volgende server als de vorige niet bereikbaar is; geweigerde aanmeldgegevens veroorzaken geen normale fallback. Deze volgorde is dus geen load balancing en 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:

1. AD-gebruikers of groepen worden correct gevonden.
2. Testgebruiker kan zich op de bedoelde plaats aanmelden.
3. Groepslidmaatschap past bij de gewenste firewall- of VPN-rechten.
4. Log Viewer toont begrijpelijke authenticatie-events.
5. Remote Access VPN, User Portal of Captive Portal werken met een normale testgebruiker.
6. MFA wordt gevraagd wanneer dit voor het scenario gepland is.
7. De AD-server staat onder Authentication > Services op de gewenste positie binnen de Firewall Authentication Methods.

Als daarna nog onduidelijk is of serviceselectie, gebruikersidentiteit, hoofdgroep, quota of pas de latere firewallregel mislukt, scheidt Authenticatiefouten op Sophos Firewall systematisch oplossen deze lagen met een reproduceerbare testcase.

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.

Als Sophos Endpoint al Security Heartbeat verstuurt, kan Synchronized User ID Authentication een Windows 10-domeingebruiker zonder extra authenticatieagent aan de firewall doorgeven. De werkwijze vereist nog steeds de passende AD-validatie en een echte regeltest.

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.

Sophos plaatst het door de browser geïnitieerde NTLM achter General Authentication Client, Clientless single sign-on en Client-based single sign-on. NTLM wordt pas als fallback gebruikt wanneer deze toewijzingen niet van toepassing zijn; als ook NTLM mislukt, verschijnt Captive Portal. Als een gebruiker onder Current activities > Live users met een onverwachte methode verschijnt, worden eerst het weergegeven Client type en reeds actieve identiteitsbronnen gecontroleerd voordat de SPN of Web Authentication wordt gewijzigd.

De instelling Kerberos & NTLM biedt beide methoden aan de browser aan; de client bepaalt welke wordt gebruikt. Een modus met alleen Kerberos bestaat niet, omdat de HTTP-specificatie dit niet ondersteunt. Voor transparant webverkeer leidt de firewall de authenticatie om naar TCP-poort 8091.

Wanneer meerdere gebruikers hetzelfde RDS- of terminalserver-IP delen, volstaat de normale IP-toewijzing niet. Voor HTTP- en HTTPS-verkeer dat uitsluitend via een expliciete proxy loopt, beschrijft Per-Connection AD SSO voor multi-userhosts de aparte procedure en de afbakening ten opzichte van SATC.

⚠️ Upgrade-opmerking voor SFOS 22: Na een upgrade van SFOS 21.5 of eerder naar SFOS 22.0 GA kan AD SSO met Kerberos en NTLM uitvallen. Gebruikersgebaseerde regels herkennen de betrokken domeingebruikers dan niet meer, terwijl ander firewallverkeer blijft werken. Sophos heeft de fout opgelost in SFOS 22.0 MR1 Build 490. AD SSO moet vóór en direct na de upgrade met een echte domeingebruiker en werkelijk gebruikersverkeer worden getest. AD SSO herstellen na de SFOS 22-upgrade beschrijft de controle in nasm.log, de gerichte NASM-cleanup en de aansluitende controle met echt gebruikersverkeer.

De AD SSO-flow is daarom meer dan alleen Test connection op de AD-server:

1. Onder Administration > Admin and user settings een hostname of FQDN instellen. Gebruik voor Kerberos een FQDN in kleine letters met een hostdeel van maximaal 15 tekens, zodat NetBIOS name, AD-computerobject en SPN niet uit elkaar lopen.

   Voorbeeld: de firewall is geconfigureerd als fw01.edge.example.com en het AD-domein heet corp.example.com. Tijdens de Domain Join gebruikt SFOS de NetBIOS-hostname fw01 met het AD-domein. De naam die in AD bekend is, luidt daarom fw01.corp.example.com, niet automatisch de op de firewall geconfigureerde FQDN. De redirectnaam voor transparante Kerberos moet bij de in AD geregistreerde HTTP-SPN passen en via DNS oplosbaar zijn.

2. 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. Een account met leestoegang tot AD kan op een Windows-systeem deze gerichte, alleen-lezen query uitvoeren:

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

   Vervang de voorbeeldwaarde door de eigen redirect-FQDN. De uitvoer moet exact de verwachte SPN en het verwachte computerobject tonen; geen resultaat of een resultaat op een ander object moet vóór de uitrol met de AD-verantwoordelijke worden opgehelderd.

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

4. Onder Authentication > Services de AD-server op de gewenste positie in Firewall authentication methods zetten. AD SSO gaat alleen naar de volgende server als de vorige niet bereikbaar is, niet bij geweigerde aanmeldgegevens.

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

6. Onder Authentication > Web authentication bij If Active Directory (AD) SSO is configured de methode Kerberos & NTLM of bewust NTLM only kiezen.

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

Onder Authentication > Services moet HTTP challenge redirect on intranet zone ingeschakeld blijven. Als een op internet gehoste website een NTLM-challenge start, verwerkt de firewall de uitwisseling dan via het lokale interface-IP in de intranetzone. Als de optie is uitgeschakeld, kan de browser aanmeldgegevens via internet versturen. Dit is geen onschuldige compatibiliteitsinstelling.

Wanneer Use web authentication for unknown users HTTPS-verkeer in transparante modus authenticeert, ontsleutelt de firewall de verbinding voor de authenticatie, ongeacht de instellingen van de firewallregel of de SSL/TLS Inspection Rule. 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.

Sophos Firewall biedt pas een van beide methoden aan de browser aan nadat Kerberos en NTLM op de firewall met succes zijn geïnitialiseerd. Een zichtbare NTLM-fallback is daarom geen reden om de Kerberos-controle over te slaan. DNS, SPN en systeemtijd moeten overeenkomen; standaard mogen de klokken die bij Kerberos betrokken zijn niet meer dan vijf minuten verschillen.

Houd de accountrollen gescheiden. Het LDAP-bindaccount heeft alleen de leesrechten nodig die voor directoryquery’s vereist zijn. Voor de domain-join-operatie van AD SSO is daarentegen een Domain Admin-account nodig of een account met gedelegeerde rechten om het computerobject of de SPN aan te maken. In HA-omgevingen, bij meerdere AD-servers of na een upgrade kan een nieuwe domain join nodig zijn; zorg daarom dat geschikte join-inloggegevens beschikbaar zijn zonder die verhoogde rechten aan het LDAP-bindaccount toe te kennen.

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 389 of 636 bereikbaar?
• Past SSL/TLS echt 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-gebruikers kunnen zich niet aanmelden bij het VPN Portal

Als een bestaande AD-gebruiker het VPN Portal kan gebruiken, maar een nieuw aangemaakte gebruiker met vergelijkbare rechten niet, moet men eerst de groepstoewijzing, Remote Access-methode en firmwareversie vergelijken. Onder Authentication > Users toont Group de Main Group; andere geïmporteerde groepen staan onder Other group memberships. SSL VPN kan meerdere groepslidmaatschappen meenemen, terwijl IPsec Remote Access alleen de Main Group of een expliciet geselecteerde gebruiker gebruikt.

Voor de diagnose:

1. Vergelijk de betrokken nieuwe gebruiker met een werkende bestaande gebruiker.
2. Controleer de Main Group en Other group memberships.
3. Controleer onder Authentication > Services de VPN portal authentication methods, onder Administration > Device access de toegestane bronzone en in de Remote Access-policy de gebruiker of groep.
4. Noteer de SFOS-versie en build.

Sophos heeft met NC-180824 een fout opgelost waarbij nieuwe AD-gebruikers uit een Secondary AD Group zich niet konden aanmelden bij het VPN Portal. De oplossing is opgenomen in SFOS 22.0 MR2 Build 546 van 14 juli 2026. Sophos vermeldt noch de versie waarin de fout is geïntroduceerd, noch een officiële workaround. Als de configuratie en groepslogica kloppen, moet men een getroffen oudere installatie daarom bijwerken naar SFOS 22.0 MR2 of nieuwer en vervolgens testen met een AD-gebruiker die zich voor het eerst bij de firewall aanmeldt en van wie de VPN-toegang uitsluitend via de getroffen Secondary Group in een SSL-VPN-policy wordt verleend.

⚠️ Wijzig de groepsvolgorde niet op goed geluk, verwijder gebruikers niet voortijdig met Purge AD users en maak groepen niet opnieuw aan. Sophos documenteert deze maatregelen niet als oplossing voor NC-180824 en ze kunnen andere rechten wijzigen.

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/fw01.corp.example.com 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.

Het certificaat dat onder Admin console and end-user interaction > Certificate is geselecteerd, moet de redirect-hostname of FQDN dekken en door de endpoints worden vertrouwd. Het vooraf geïnstalleerde zelfondertekende firewallcertificaat voldoet voor een nieuw ingestelde naam normaal aan geen van beide voorwaarden. Negeer een certificaatwaarschuwing niet, maar los deze op met een passend openbaar of intern certificaat.

Voor NTLM kan het vertrouwen tot de interne redirectnaam worden beperkt. Microsoft Edge en Google Chrome nemen onder Windows de instelling over uit Internet Options > Security > Local intranet > Sites > Advanced. Voeg in Firefox dezelfde FQDN onder about:config toe aan network.automatic-ntlm-auth.trusted-uris. Sta alleen de werkelijk gebruikte interne naam toe, geen breed domein of willekeurige websites.

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.

Wijziging terugdraaien en veilig verder werken

Documenteer vóór wijzigingen de servervolgorde, gebruikte diensten, groepen en certificaatinstellingen. Als de acceptatietest mislukt, herstel dan eerst de vorige volgorde, de oorspronkelijke versleutelde verbindingsmethode en de bijbehorende poort. Een test met Plaintext op poort 389 blijft uitsluitend een korte diagnose en wordt nooit als productierollback gehandhaafd.

Als de volledige configuratie moet worden teruggezet, gebruikt men de eerder gedownloade back-up onder Backup and firmware > Backup and restore. Dit vervangt de huidige configuratie, maakt latere wijzigingen ongedaan en herstart de firewall; voer dit daarom in een onderhoudsvenster uit. Een firmware-rollback start de vorige partitie met de bijbehorende configuratie en beëindigt eveneens sessies. De automatische firmware-rollback werkt alleen bij een mislukte configuratiemigratie, niet bij een AD SSO-storing die pas tijdens het gebruik zichtbaar wordt.

Herhaal na elke terugkeer Test connection, een normale serviceaanmelding, de controle van de groepswerking en bij SSO een echte gebruikerstoegang met Log viewer > Authentication. In HA horen groepsimport en Purge AD users op het Primary-apparaat; voer een uitvaltest van de bedoelde secundaire DC alleen in een goedgekeurd onderhoudsvenster uit en bevestig daarbij dat de eerste server werkelijk onbereikbaar is en de login via de tweede server slaagt.

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.
• Bij meerdere groepen: aanmelding bij het VPN Portal getest met een bestaande gebruiker en een gebruiker die zich voor het eerst bij de firewall aanmeldt en van wie de rechten uitsluitend via een Secondary Group in een SSL-VPN-policy worden verleend.
• Remote Access, portal of gebruikersregel met normale gebruiker getest.
• Log Viewer toont verwachte authenticatie-events.
• Bij AD SSO zijn de Kerberos-/NTLM-meldingen in het Authentication log gecontroleerd.
• 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