# LDAP (Lightweight Directory Access Protocol)

Source: https://startwithidentity.com/standards/ldap/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

## What it is

LDAP (Lightweight Directory Access Protocol) is the IETF protocol for talking to a **directory**: a tree of entries for people, groups, computers and services, each with attributes. Version 3 is specified as a set of RFCs published in June 2006, listed in the [RFC 4510 road map](https://www.rfc-editor.org/rfc/rfc4510): the protocol itself in [RFC 4511](https://www.rfc-editor.org/rfc/rfc4511), authentication and security in [RFC 4513](https://www.rfc-editor.org/rfc/rfc4513), string forms of names in RFC 4514, search filters in [RFC 4515](https://www.rfc-editor.org/rfc/rfc4515), URLs in RFC 4516, and syntaxes and schema in RFC 4517 to RFC 4519.

LDAP sits under most enterprise identity even when nobody calls it by name. Active Directory domain controllers answer LDAP, open-source directories such as OpenLDAP and 389 Directory Server are LDAP servers, and identity platforms import users from LDAP: [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/) documents user federation from LDAP and Active Directory, [FreeIPA](https://startwithidentity.com/vendors/open-source/freeipa/) is built on 389 Directory Server with MIT Kerberos, and [JumpCloud](https://startwithidentity.com/vendors/iam/jumpcloud/) sells a cloud LDAP service (each checked on the vendor's site on 5 November 2026).

## Status (November 2026)

| Item | Status |
| --- | --- |
| RFC 4511, LDAP: The Protocol | Proposed Standard, June 2006; obsoletes RFC 2251, RFC 2830 and RFC 3771; no later RFC updates it |
| RFC 4513, Authentication Methods and Security Mechanisms | Proposed Standard, June 2006 |
| Ports | 389/tcp `ldap` and 636/tcp `ldaps` in the [IANA registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml); RFC 4511 §5.2 names 389 |

LDAPv3 is stable: there is no LDAPv4 effort, and changes arrive as controls, extended operations and schema. The editor of RFC 4511 was J. Sermersheim (Novell); RFC 4513 was edited by R. Harrison (Novell).

## How it works

Every entry has a **distinguished name** (DN) such as `uid=ada,ou=people,dc=example,dc=com`, read right to left from the root. A client opens a TCP connection, optionally upgrades it to TLS, **binds** (authenticates), then sends operations: Search, Compare, Add, Modify, Delete, Modify DN, and Extended operations. Each request and response is an `LDAPMessage` with a `messageID`, encoded in ASN.1 BER ([RFC 4511 §4.1.1, §5.1](https://www.rfc-editor.org/rfc/rfc4511#section-4.1.1)). Requests can be pipelined; the `messageID` ties responses back to them.

The two operations that matter for identity:

- **Bind** ([§4.2](https://www.rfc-editor.org/rfc/rfc4511#section-4.2)): a DN plus password ("simple"), or a SASL mechanism such as `GSSAPI` (Kerberos) or `EXTERNAL` (the TLS client certificate). The result code says whether it worked: `0` success, `49` invalidCredentials.
- **Search** ([§4.5](https://www.rfc-editor.org/rfc/rfc4511#section-4.5)): a base DN, a scope (base, one level, whole subtree), a filter such as `(&(objectClass=person)(mail=ada@example.com))`, and the attributes to return. Applications use it to find a user's DN and group memberships.

The classic application pattern is "search then bind": a service account binds, searches for the user's DN by username, then binds again as that DN with the password the user typed. The full message sequence, with each field annotated, is in [how LDAP works, message by message](https://startwithidentity.com/guides/protocols/ldap-message-flow/).

## Security model

LDAP leaves almost all security to configuration. The three settings that decide whether a deployment is safe:

1. **Confidentiality before credentials.** A simple bind carries the password as an OCTET STRING, and RFC 4513 §5.1.3 says plainly that it "is not suitable for authentication in environments without confidentiality protection." Use StartTLS ([RFC 4511 §4.14](https://www.rfc-editor.org/rfc/rfc4511#section-4.14), [RFC 4513 §3](https://www.rfc-editor.org/rfc/rfc4513#section-3)) or LDAPS, and verify the server certificate per RFC 4513 §3.1.3. Servers can refuse with `confidentialityRequired` (13) or `strongerAuthRequired` (8).
2. **No unauthenticated binds.** A bind with a DN and an empty password produces an anonymous session, and the DN must not be treated as authenticated ([RFC 4513 §5.1.2](https://www.rfc-editor.org/rfc/rfc4513#section-5.1.2)). Servers SHOULD reject these by default with `unwillingToPerform` (53); clients SHOULD refuse empty passwords. Applications that treat "bind succeeded" as "password correct" are exactly the misuse RFC 4513 §6.3.1 describes.
3. **Escape filter input.** Filters built by string concatenation are injectable. RFC 4515 §3 requires `*`, `(`, `)`, `\` and NUL to be escaped as a backslash and two hex digits.

Access control inside the directory (who may read `userPassword`, who may write group membership) is not standardized by the LDAPv3 RFCs; every server has its own ACL model, and misconfigured ACLs are a recurring source of privilege escalation.

## Where LDAP breaks in practice

From the SWI [identity CVE catalog](https://startwithidentity.com/cves/):

- **Client and server parsing bugs on domain controllers.** [CVE-2024-49113](https://startwithidentity.com/cves/cve-2024-49113/) (LDAPNightmare) crashes the Windows LDAP client with a crafted response, and its critical sibling [CVE-2024-49112](https://startwithidentity.com/cves/cve-2024-49112/) is remote code execution class.
- **Directory ACLs that let the wrong client write.** [CVE-2026-76578](https://startwithidentity.com/cves/cve-2026-76578/): a FreeIPA ACI let an anonymous LDAP client create an entry that ended up as an attacker-owned Kerberos principal in the admins group.
- **LDAP-backed login in other products.** HashiCorp Vault's LDAP auth method leaked user existence through error differences ([CVE-2023-3462](https://startwithidentity.com/cves/cve-2023-3462/)) and let case permutations reset lockout ([CVE-2025-6004](https://startwithidentity.com/cves/cve-2025-6004/)), which turns LDAP into a [password spraying](https://startwithidentity.com/techniques/password-spraying/) target.

Directories are also the reconnaissance source for most Active Directory attacks: [Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/) starts with an LDAP search for accounts that have a `servicePrincipalName`.

## When to use it

Use LDAP to **read and manage directory data**: provisioning and sync, group lookups, Linux and network device integration, and applications that genuinely cannot speak anything newer. Do not make it the login protocol for new web applications. Binding with the user's password means your application sees and handles that password, cannot participate in MFA or phishing-resistant authentication, and has to manage directory credentials. Use [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) or [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) for web sign-on and [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/) for pushing users into SaaS applications. For Windows and Unix single sign-on on a network, LDAP works alongside [Kerberos](https://startwithidentity.com/standards/kerberos/), which carries the actual authentication.

## Pitfalls

- Binding in cleartext on 389 "just inside the network", or skipping certificate verification on 636.
- Accepting an empty password as a successful login (unauthenticated bind).
- Service accounts with domain-wide read and a password that never rotates.
- Unescaped filter input, and searches with no size or time limits.
- Treating `mail` or `uid` as a permanent identifier; use the server's stable entry identifier (for example `entryUUID` in RFC 4530, or `objectGUID` in Active Directory).

## How it works, message by message

The [LDAP message-flow walkthrough](https://startwithidentity.com/guides/protocols/ldap-message-flow/) decodes the search-then-bind login used by most applications: StartTLS, the service-account bind, the user search, the user bind and its result codes, with every `LDAPMessage` field tied to RFC 4511 or RFC 4513 and eight checks an LDAP-authenticating application must run.

## Related

Walkthrough: [how LDAP works, message by message](https://startwithidentity.com/guides/protocols/ldap-message-flow/). Standards: [Kerberos](https://startwithidentity.com/standards/kerberos/), [RADIUS](https://startwithidentity.com/standards/radius/), [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/). Glossary: [LDAP](https://startwithidentity.com/glossary/ldap/), [directory service](https://startwithidentity.com/glossary/directory-service/), [Active Directory](https://startwithidentity.com/glossary/active-directory/). Guides: [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), for detecting directory reconnaissance and abuse.