Generieke LDAP-server verbinden met Sophos Firewall

Active Directory is op Sophos Firewall de meest gebruikte authenticatieserver, maar niet de enige. Wie OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP of een ander zuiver LDAP-verzeichnis draait, kan Sophos Firewall net zo goed als LDAP-client koppelen. Het servertype heet daarvoor bewust LDAP Server, niet Active Directory, ook al is Active Directory technisch zelf een LDAP-verzeichnis.

Dit artikel behandelt gericht het generieke geval: een directory service zonder de AD-specifieke velden zoals domeinnamen of Kerberos. Voor Active Directory-omgevingen met LDAPS, groepsimport en AD SSO past juist Active Directory met Sophos Firewall verbinden. Voor RADIUS-gebaseerde authenticatie, bijvoorbeeld via Microsoft NPS of een MFA-gateway, is Sophos Firewall RADIUS-server configureren het passende artikel.

Wanneer een generieke LDAP-server past

Een LDAP-server op Sophos Firewall is zinvol wanneer:

• gebruikers en groepen zich bevinden in een directory die geen Active Directory is, bijvoorbeeld OpenLDAP, 389 Directory Server of FreeIPA.
• een cloud-gebaseerde directory een LDAP-interface aanbiedt, bijvoorbeeld Google Secure LDAP of een LDAP-proxy voor Entra ID of Okta.
• meerdere systemen al tegen dezelfde LDAP-directory authenticeren en de firewall dezelfde bron moet gebruiken.
• er geen Kerberos of NTLM nodig is, maar een eenvoudige bind-authenticatie volstaat.

Als in plaats daarvan een Windows Server met Active Directory Domain Services wordt gebruikt, is het gespecialiseerde AD-servertype meestal de betere keuze, omdat het extra velden zoals domeinnamen netjes afbeeldt. Het generieke LDAP-servertype werkt weliswaar ook tegen Active Directory, maar biedt minder AD-specifieke automatismen.

Vereisten

• Toegang tot de WebAdmin van de Sophos Firewall.
• Bereikbaarheid van de LDAP-server vanaf de firewall, meestal poort 389 (Plaintext/StartTLS) of 636 (LDAPS).
• Een bind-account met leesrechten op de relevante subboom, gespecificeerd als Distinguished Name (DN).
• De Base DN waaronder gebruikers worden gezocht, bijvoorbeeld ou=people,dc=firma,dc=local.
• Kennis van het attribuut dat als aanmeldnaam dient, vaak uid, sAMAccountName of mail.
• Bij een versleutelde verbinding: het servercertificaat of de certificaatketen, als de firewall die moet valideren.

⚠️ Een bind-account mag alleen leesrechten hebben op de benodigde subboom. Het wordt niet gebruikt voor administratieve wijzigingen in de directory, maar alleen om gebruikersaanvragen van de firewall bij de LDAP-server te authenticeren.

LDAP-server aanmaken

1. Authentication > Servers openen.
2. Add kiezen en als Server type LDAP server selecteren.
3. Bij Server name een unieke naam invoeren, bijvoorbeeld LDAP_Firma_Intern.
4. Bij Server IP/domain het IP-adres of de DNS-naam van de LDAP-server invullen.
5. Bij Version de door de server ondersteunde LDAP-versie kiezen, meestal Version 3.
6. Bij Connection security kiezen tussen Plaintext, SSL/TLS of STARTTLS.
7. Bij Port de juiste poort instellen, indien niet de standaardpoort wordt gebruikt.
8. Anonymous login uitschakelen, tenzij de server anonieme bind-aanvragen toestaat.
9. Bij Bind DN het technische account als Distinguished Name invullen, bijvoorbeeld cn=svc-sophos,ou=service,dc=firma,dc=local.
10. Het bijbehorende Password invullen.
11. Bij Base DN het zoekbereik voor gebruikers invullen, bijvoorbeeld ou=people,dc=firma,dc=local.
12. Bij Authentication attribute het veld invullen dat als aanmeldnaam dient, vaak uid.
13. Optioneel Display name attribute en Email address attribute instellen, bijvoorbeeld cn en mail.
14. Optioneel Group name attribute instellen, als groepslidmaatschappen moeten worden geëvalueerd.
15. Test connection uitvoeren en resultaat controleren.
16. Save kiezen.

De velden in overzicht:

Een geslaagde Test connection bewijst alleen dat server, poort, bind-account en zoekbasis in principe bereikbaar zijn. Of de juiste gebruikers worden gevonden en groepen correct worden toegewezen, moet daarna met een echte testgebruiker worden gecontroleerd.

Versleuteling correct kiezen

Voor productieomgevingen moet de verbinding tussen firewall en LDAP-server versleuteld zijn, ofwel via LDAPS op poort 636 ofwel via STARTTLS op de klassieke poort 389. Plaintext-LDAP verstuurt bind-wachtwoorden en soms gebruikersgegevens onversleuteld en mag alleen worden gebruikt in strikt afgeschermde, interne testscenario’s.

Bij Validate server certificate controleert de firewall of het door de LDAP-server gepresenteerde certificaat vertrouwd kan worden. Bij zelfondertekende certificaten, zoals bijvoorbeeld bij Google Secure LDAP worden gebruikt, kan het certificaat als niet-vertrouwd worden aangemerkt, ook al werkt de verbinding wel. In dat geval moet bewust worden beslist of de certificaatcontrole wordt aangepast of het certificaat in de firewall wordt geïmporteerd.

Voorbeeld: Google Secure LDAP

Google Secure LDAP laat goed zien hoe een cloud-gebaseerde directory via generieke LDAP wordt gekoppeld:

• Server IP/domain: ldap.google.com
• Port: 636
• Version: 3
• Connection security: SSL/TLS
• Bind DN en Password: inloggegevens uit de in de Google Admin Console gegenereerde LDAP-client-credentials.
• Certificaat: het door Google uitgegeven clientcertificaat met privésleutel wordt op de firewall opgeslagen.
• Attributen: uid voor de aanmelding, cn voor de weergavenaam, mail voor het e-mailadres, memberOf voor groepen.

Dit voorbeeld is over te dragen op andere LDAP-aanbieders met een vergelijkbare structuur. Bepalend is altijd welk attribuut de aanbieder daadwerkelijk vult voor aanmeldnaam, weergavenaam, e-mail en groepslidmaatschap.

Bind DN en Base DN correct invullen

De meest voorkomende foutbron bij een nieuwe LDAP-server is een verkeerd geschreven of verkeerd begrepen DN-syntax.

Belangrijke regels:

• Een DN wordt geschreven van het meest specifieke naar het meest algemene deel, bijvoorbeeld cn=svc-sophos,ou=service,dc=firma,dc=local.
• De Base DN voor de gebruikerszoekopdracht moet de subboom zijn waarin de relevante gebruikersobjecten daadwerkelijk staan, niet noodzakelijkerwijs de wortel van de directory.
• Als gebruikers zich in meerdere organisatie-eenheden bevinden, moet de Base DN hoog genoeg in de boom worden gekozen om alle relevante containers te omvatten.
• Append base DN bepaalt of de Base DN extra aan de Bind DN wordt toegevoegd. Dit is serverafhankelijk en moet bij problemen gericht worden getest.

Als de Base DN te smal is gekozen, meldt de firewall soms een geslaagde verbindingstest, maar vindt daarna geen gebruikers. Als de Base DN te breed is gekozen, kan de zoekopdracht onnodig lang duren of ongewenste objecten omvatten.

Groepen en attributen toewijzen

Voor firewallregels, web policies of VPN-rechten op basis van groepen is het Group name attribute bepalend. Het bepaalt welk LDAP-attribuut de firewall als groepslidmaatschap interpreteert.

Typische patronen:

• Directories met een klassiek groupOfNames- of posixGroup-schema gebruiken vaak een attribuut zoals memberOf of bepalen groepslidmaatschap via terugverwijzingen.
• Cloud-directories met een LDAP-proxy, bijvoorbeeld Google Secure LDAP, leveren groepen vaak direct in het attribuut memberOf op het gebruikersobject.
• Als het schema onduidelijk is, helpt een LDAP-browser of een commandoregeltool zoals ldapsearch om het gebruikersobject eenmalig volledig te bekijken voordat de firewall wordt geconfigureerd.

Na de configuratie moet minstens één gebruiker uit elke relevante groep worden getest. Eén geslaagde login bewijst niet dat de groepstoewijzing voor alle groepen correct werkt.

LDAP-server voor diensten activeren

Een aangemaakte LDAP-server authenticeert nog niemand vanzelf. Hij moet ook onder Authentication > Services aan de gewenste dienst worden toegewezen, bijvoorbeeld VPN Portal, SSL VPN, Captive Portal of admin-login.

Praktisch verloop:

1. Authentication > Services openen.
2. De betreffende dienst kiezen, bijvoorbeeld Firewall authentication methods of VPN.
3. De nieuw aangemaakte LDAP-server als authenticatiebron toevoegen.
4. Volgorde controleren, als meerdere servers parallel worden gebruikt.
5. Met een testgebruiker de betreffende dienst controleren.

Als meerdere authenticatieservers tegelijk actief zijn, bijvoorbeeld LDAP en lokale gebruikers, moet de volgorde bewust worden gekozen. De firewall bevraagt de servers in de ingevoerde volgorde.

Verbinding testen en valideren

Na het opslaan moet de configuratie in meerdere stappen worden getest:

1. Test connection in het servervenster: bevestigt bereikbaarheid, bind-account en Base DN.
2. Testgebruiker aanmelden bij de doeldienst: bevestigt dat authenticatie daadwerkelijk werkt.
3. Groepslidmaatschap controleren: bevestigt dat het Group name attribute correct wordt geëvalueerd.
4. Verkeerde gebruiker of verkeerd wachtwoord testen: bevestigt dat mislukte logins netjes worden geweigerd.
5. Log Viewer controleren: toont of authenticatieaanvragen zoals verwacht binnenkomen en worden verwerkt.

Een testgebruiker die zich succesvol aanmeldt maar niet bij de verwachte groep wordt ingedeeld, wijst meestal op een verkeerd Group name attribute of een onverwacht groepsschema.

Veelvoorkomende fouten

• Verkeerde DN-syntax: Bind DN of Base DN zijn verwisseld, verkeerd geschreven of gebruiken verkeerde scheidingstekens. Syntax tegen het directoryschema controleren.
• Base DN te smal gekozen: de verbindingstest slaagt, maar echte gebruikers worden niet gevonden. Base DN hoger in de directoryboom instellen.
• Verkeerde poort of verkeerde versleuteling: LDAPS op poort 389 of Plaintext op poort 636 werkt niet. Poort en Connection security moeten bij elkaar passen.
• Certificaat niet vertrouwd: bij zelfondertekende certificaten kan de firewall de verbinding als niet-vertrouwd beoordelen. Certificaat bewust importeren of validatie gericht aanpassen.
• Anonymous login actief terwijl de server dat weigert: bind mislukt. Anonymous login uitschakelen en Bind DN/Password invullen.
• Groepsattribuut past niet bij het schema: login werkt, maar groepsbeleid grijpt niet. Attribuut controleren tegen het werkelijke LDAP-schema, bijvoorbeeld met ldapsearch.
• LDAP-server niet toegewezen onder Authentication > Services: server is aangemaakt, maar wordt door geen enkele dienst gebruikt. Toewijzing onder Authentication > Services alsnog uitvoeren.
• Meerdere authenticatieservers in verkeerde volgorde: een andere server antwoordt eerst en levert onverwacht gedrag op. Volgorde onder Authentication > Services controleren.

FAQ