Koppelen met LDAP (Lightweight Directory Access Protocol)
Wat LDAP in 2026 nog betekent
LDAP (Lightweight Directory Access Protocol) is sinds de jaren 90 het standaard-protocol voor het bevragen van directories: gebruikers, groepen, rechten, apparaten. Ondanks de opkomst van moderne alternatieven zoals OAuth 2.0, SAML en OIDC, blijft LDAP in veel organisaties de kern van hun identity-infrastructuur. Reden: Microsoft Active Directory, dat door miljoenen bedrijven gebruikt wordt, praat native LDAP.
Voor deze organisaties is de vraag zelden “LDAP of iets anders”, maar “hoe koppelen we onze bestaande LDAP aan nieuwe software, portalen en clouddiensten”. Dat is waar wij binnenkomen.
Voor nieuwe projecten zonder legacy kijken we vrijwel altijd eerst naar modernere alternatieven zoals Microsoft Entra ID, Auth0 of eigen OAuth-flows. LDAP is een prima keuze als het past bij de bestaande infrastructuur, geen doel op zich.
Wanneer LDAP-koppelen zinvol is
Op basis van wat wij zien bij Nederlandse organisaties, zijn er vier situaties waarin een LDAP-koppeling logisch is.
De eerste is bestaande Active Directory-infrastructuur. Grote delen van het Nederlandse zakenleven, de overheid en de zorg draaien op Active Directory. Als jullie IT-organisatie AD-first werkt, is een LDAP-koppeling naar nieuwe applicaties vaak de snelste weg naar centraal gebruikersbeheer, zonder dat er een aparte identity-provider aan tussenkomt.
De tweede is OpenLDAP in Linux-omgevingen. Voor organisaties die primair op Linux draaien, is OpenLDAP een gevestigde open-source keuze. Wij koppelen daaraan voor onder andere webapplicaties, portalen en interne tools.
De derde situatie is compliance en governance. In sectoren waar centralisatie van identity een audit-vereiste is (zorg, financieel, defensie, overheid), biedt LDAP een stabiele basis die decennia meegaat. Nieuwe protocollen zijn ook goed, maar LDAP is bewezen.
De vierde is hybride setups. Voor organisaties die deels on-premise en deels in de cloud werken, kan een LDAP-koppeling de brug slaan tussen de bestaande on-premise directory en nieuwe cloudapplicaties. Voor complexere hybride scenarios combineren we vaak met Microsoft Entra ID of andere identity-brokers.
Wat een LDAP-koppeling concreet doet
Bij een LDAP-integratie draait bijna alles om drie kernvragen. Wie is deze gebruiker (authenticatie). Wat mag deze gebruiker (autorisatie). En hoe blijven de gegevens actueel (synchronisatie).
Voor authenticatie gebruikt de applicatie LDAP om inloggegevens te verifiëren tegen de directory. De gebruiker typt gebruikersnaam en wachtwoord, de applicatie vraagt LDAP om te bevestigen dat dit klopt. Voor moderne applicaties combineren we dit vaak met tweefactor-authenticatie via een aparte laag.
Voor autorisatie halen we uit LDAP welke groepen of rollen een gebruiker heeft. Op basis daarvan bepaalt de applicatie wat de gebruiker mag zien en doen. Voor complexe scenarios met veel rollen bouwen we een mapping-laag die LDAP-groepen omzet naar applicatie-specifieke permissies.
Voor synchronisatie halen we periodiek of realtime gebruikersgegevens op uit LDAP: naam, e-mailadres, telefoonnummer, afdeling, functie. Voor nieuwe medewerkers wordt automatisch een gebruikersrecord aangemaakt in de applicatie. Voor vertrekkende medewerkers wordt de toegang direct ingetrokken zodra ze uit LDAP verdwijnen.
Voor provisioning kan de flow ook de andere kant op werken: applicaties die zelf nieuwe accounts aanmaken in LDAP, bijvoorbeeld bij het onboarden van een nieuwe klant of partner. Dit vraagt om striktere autorisatie en audit-logging.
Wat we vaak bouwen
LDAP als login-provider voor webapplicaties. Gebruikers loggen in met hun bestaande AD-account, zonder aparte inloggegevens per applicatie. Voor interne portalen, ledenomgevingen en klantomgevingen die door medewerkers gebruikt worden. Werkt met Laravel, Nuxt, Symfony en custom applicaties.
LDAP-authenticatie voor WordPress. Voor organisaties met WordPress-sites waarop medewerkers content beheren, koppelen we WP-admin aan de LDAP-directory. Nieuwe medewerkers krijgen automatisch toegang, vertrekkers verliezen die direct.
LDAP als bron voor Directus en headless CMS’en. Voor Directus-projecten waar redactie of applicatiegebruikers centraal beheerd moeten worden, is LDAP een prettige koppeling. Rollen en toegangsrechten worden bepaald op basis van AD-groepen.
Klantportalen met AD-integratie. Voor B2B-organisaties waar klanten met eigen AD-accounts toegang krijgen tot een klantportaal op maat, bouwen we LDAP-federatie. Vaak in combinatie met SAML of OIDC voor moderne single-sign-on.
Migratie van LDAP naar moderne identity-providers. Voor organisaties die stap voor stap willen migreren naar bijvoorbeeld Microsoft Entra ID of Auth0, bouwen we hybride oplossingen waar LDAP en moderne providers naast elkaar draaien tijdens de overgangsperiode.
Provisioning en de-provisioning. Voor organisaties waar de HR-afdeling met een centraal systeem werkt (zoals SAP SuccessFactors of NMBRS), bouwen we de brug tussen HR-systeem en LDAP. Nieuwe medewerkers krijgen automatisch een AD-account, uit dienst gaat automatisch de toegang eraf.
Waar het technisch spannend wordt
LDAP is oud en stabiel, maar de meest voorkomende fouten in projecten zijn technisch subtiel. Op deze plekken letten we structureel op.
Bind-users en credentials. Elke LDAP-koppeling gebruikt een service-account met eigen credentials om te authenticeren tegen de directory. Deze credentials horen versleuteld te worden opgeslagen, met beperkte rechten (alleen lezen, niet schrijven, tenzij noodzakelijk), en met periodieke rotatie.
LDAPS en beveiligde verbindingen. LDAP-verkeer over ongecoderde verbindingen is een security-risico. Wij implementeren altijd LDAPS (LDAP over TLS) voor productie, met correcte certificaat-validatie. Voor interne netwerken kan onbeveiligde LDAP soms verantwoord zijn, maar dat is bewust maatwerk.
Connection pooling en performance. Elke LDAP-bevraging kost tijd. Voor applicaties die veel gebruikers verwerken, bouwen we connection pooling en caching in zodat de directory niet overbelast raakt en response-tijden voor gebruikers snel blijven.
Group nesting en indirecte lidmaatschappen. AD ondersteunt groepen die zelf lid zijn van andere groepen. Voor autorisatie-checks moet de applicatie de volledige lidmaatschappen kunnen resolveren, niet alleen directe. Wij bouwen dat correct in, ook voor diepe hierarchieën.
Failover en beschikbaarheid. Als LDAP even niet bereikbaar is, mag de applicatie niet volledig plat gaan. Wij bouwen retry-strategieën, fallback naar cached credentials waar mogelijk, en heldere foutmeldingen voor gebruikers.
Character encoding en internationale karakters. LDAP-attributen kunnen niet-ASCII karakters bevatten (bijvoorbeeld in namen). Wij zorgen dat encoding overal correct is, zodat een Franse naam met accent niet verminkt in de applicatie belandt.
Audit-logging. Voor compliance-gevoelige toepassingen loggen we welke LDAP-bevragingen wanneer zijn gedaan, door welke applicatie en met welk resultaat. Dat is essentieel bij audits en incident-onderzoek.
Wachtwoordbeleid. Applicaties horen zich te houden aan het wachtwoordbeleid van de directory (complexiteit, verlooptermijnen, geschiedenis). Wij implementeren dat consistent zodat gebruikers geen conflicterende regels ervaren tussen AD en de applicatie.
LDAP versus moderne alternatieven
Voor nieuwe projecten zonder legacy is LDAP zelden de eerste keuze. Kort waarom.
LDAP versus OAuth 2.0 en OIDC: OAuth 2.0 en OpenID Connect zijn moderner, cloud-native en beter geschikt voor mobiele apps en API-integraties. LDAP is stateful, netwerk-intensief en oorspronkelijk ontworpen voor lokale netwerken. Voor nieuwe cloud-toepassingen kiezen we vrijwel altijd OAuth/OIDC, met eventueel een broker die achter de schermen naar LDAP kijkt.
LDAP versus SAML: SAML is ook ouder maar specifiek ontworpen voor Single Sign-On tussen organisaties. Voor B2B-federaties en enterprise-SSO is SAML sterker. LDAP is beter voor interne authenticatie waar de gebruiker direct in de directory zit.
LDAP versus Microsoft Entra ID (Azure AD): Entra ID is de cloud-versie van Active Directory, met moderne protocollen (OAuth, OIDC, SAML) en uitgebreide functionaliteit voor moderne applicaties. Voor Microsoft 365-organisaties is Entra ID vrijwel altijd de logische keuze voor nieuwe applicaties. Bestaande on-premise AD blijft parallel bestaan voor legacy-systemen.
LDAP versus Auth0: Auth0 is een moderne identity-broker die kan federen met LDAP en veel andere providers. Voor projecten waar identity-flexibiliteit belangrijk is (meerdere providers, social login, custom flows), is Auth0 vaak beter geschikt dan een directe LDAP-integratie.
De praktische conclusie: LDAP kiezen we bewust als het past bij de bestaande infrastructuur en er geen doorslaggevende redenen zijn om moderner te bouwen. Voor greenfield-projecten zoeken we bijna altijd een modernere basis.
Platformen waar we LDAP aan koppelen
De koppeling werkt met vrijwel elk platform dat authenticatie ondersteunt. Wij bouwen ‘m met:
- Laravel met LdapRecord of eigen implementatie via php-ldap
- Nuxt en Node.js met ldapjs of vergelijkbare libraries
- Symfony met LDAP-security bundle
- WordPress met LDAP-plugins en custom uitbreidingen waar nodig
- Directus via de LDAP-auth-provider
- Custom applicaties via directe LDAP-integratie of via een tussenlaag
Voor complexere scenarios adviseren we vaak een aparte identity-service die tussen LDAP en de applicaties zit. Deze service handelt de LDAP-communicatie af, cachet resultaten en biedt een moderne API aan applicaties. Bijkomend voordeel: overstappen naar een andere identity-provider (bijvoorbeeld Entra ID of Auth0) betekent alleen de service aanpassen, niet elke applicatie.
Meer over de bredere aanpak op onze pagina over integraties en koppelingen.
Deze content is met AI-ondersteuning geschreven en nagelopen door het Smit-team.Hoe ideeën werkelijkheid worden
Geen theorie, maar echte trajecten. Bekijk hoe richting, techniek en ontwerp samen zorgen voor resultaat dat blijft staan.
Inzichten uit ons digitaal vakmanschap
Van praktijkverhalen en slimme oplossingen tot updates uit ons eigen team. Een inkijk in wat ons bezighoudt, wat we ontdekken en hoe ideeën langzaam vorm krijgen.
Veelgestelde vragen
Kunnen we onze Active Directory koppelen aan een nieuwe webapplicatie?
Ja. Voor Active Directory bouwen we LDAP-koppelingen die zorgen dat medewerkers met hun bestaande AD-account inloggen op de nieuwe applicatie. Groepslidmaatschappen bepalen wat de gebruiker mag zien en doen. Voor moderne cloud-applicaties adviseren we vaak om via Microsoft Entra ID te federeren (met moderne protocollen als SAML of OIDC), zeker als jullie ook Microsoft 365 gebruiken. Voor puur on-premise applicaties is directe LDAP-koppeling de logische keuze.
Is LDAP nog wel de goede keuze in 2026?
Voor organisaties met bestaande AD-infrastructuur is LDAP nog steeds de meest praktische keuze voor interne authenticatie. Voor nieuwe cloud-native projecten kijken we bijna altijd eerst naar OAuth 2.0, OpenID Connect of Entra ID. Legacy applicaties die LDAP gebruiken kunnen we prima blijven ondersteunen, en indien wenselijk gefaseerd migreren naar modernere protocollen.
Kunnen we LDAP combineren met tweefactor-authenticatie?
Ja. LDAP levert de eerste factor (gebruikersnaam en wachtwoord), een aparte laag levert de tweede factor (SMS, authenticator-app, hardware key). Wij bouwen die combinatie regelmatig in, vaak met externe providers zoals Auth0 of eigen implementaties. Voor organisaties met Microsoft 365-abonnementen is Entra ID Conditional Access vaak de logische keuze omdat het native integreert met AD.
Hoe zit het met performance bij veel gebruikers?
LDAP-bevragingen kunnen bij hoog volume een bottleneck worden als de koppeling niet goed is opgezet. Wij bouwen connection pooling, resultaat-caching en indien nodig een aparte identity-service tussen de applicatie en LDAP. Voor grote enterprise-toepassingen adviseren we soms om LDAP alleen te gebruiken bij eerste login en daarna de sessie te beheren via een moderne token-flow.
Kunnen we van LDAP migreren naar Entra ID of een moderne identity-provider?
Ja. Wij bouwen migratie-trajecten waarin LDAP en de nieuwe identity-provider tijdelijk naast elkaar draaien. Nieuwe gebruikers krijgen direct een account in de nieuwe provider, bestaande gebruikers worden gefaseerd overgezet. Voor de meeste organisaties duurt zo’n migratie zes tot achttien maanden, afhankelijk van het aantal applicaties dat gekoppeld is. Uitgangspunt: geen dip in gebruikerservaring, geen security-lekken tijdens de overgang.