LDAP Protocol
The directory protocol under Active Directory and enterprise auth — hierarchical, fast for reads, and the backend a surprising amount of infrastructure still binds against.
What is LDAP?
LDAP (Lightweight Directory Access Protocol) queries and modifies directory services — hierarchical databases of users, groups, and devices optimized for high-read, low-write lookups. It’s the protocol beneath Active Directory, OpenLDAP, and the directory tier that a large amount of enterprise software still authenticates against. Entries live in a tree (the DIT) addressed by distinguished names (cn=jsmith,ou=engineering,dc=corp,dc=com); the schema defines object classes and attributes.
Bind, search, and the auth pattern
Authentication in LDAP is the bind operation — present a DN and password, the server verifies. Classic app auth does a two-step dance: bind as a service account, search for the user’s DN by username, then attempt a second bind as that user with their password. Get it right and you have battle-tested directory auth; get it wrong and you have the protocol’s signature vulnerability.
Security: injection and cleartext
LDAP injection is the directory cousin of SQL injection — unsanitized username input concatenated into a search filter lets an attacker alter query logic (*)(uid=*))(|(uid=* and relatives), potentially bypassing auth or dumping entries. Parameterize/escape filter inputs, always. The second issue is transport: plain LDAP is cleartext, binds and all — LDAPS (LDAP over TLS) or StartTLS is mandatory, and “we bind over plain LDAP internally” is a finding, not a footnote (encryption in transit applies to directory traffic like everything else).
The cloud-era position
LDAP didn’t vanish; it moved behind federation. Cloud SSO and SAML/OIDC front the modern experience, but underneath, workforce identity frequently still resolves to an AD/LDAP directory, and plenty of appliances, VPNs, and legacy apps bind against LDAP directly. Managed AD offerings exist precisely because lifted-and-shifted workloads still expect it.
What people get wrong
- Unescaped filter inputs — LDAP injection is real and under-tested relative to SQLi.
- Cleartext binds on “internal” networks that zero trust says aren’t trusted.
- Treating LDAP as an auth protocol for apps when OIDC/SAML federation is the better modern seam — bind directly only where you must.
Primary source: RFC 4511 — LDAP: The Protocol
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.