LDAP Protocol

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

LDAP’s Continued Relevance

Despite predating cloud-native identity systems by decades, LDAP (Lightweight Directory Access Protocol) remains widely used, particularly as the underlying protocol many enterprise applications use to query Active Directory or other directory services for user authentication and group membership information. Many legacy and on-premises enterprise applications were built with native LDAP integration and have no equivalent support for newer protocols like SAML or OIDC, making LDAP integration a persistent requirement for identity systems serving mixed modern and legacy application portfolios — cloud identity providers often support LDAP as a compatibility bridge specifically to serve these older applications without requiring a full rebuild of their authentication logic.