LDAP (Lightweight Directory Access Protocol) is the IETF standard protocol, version 3 defined in RFC 4510 to RFC 4519 (June 2006), for reading, searching, modifying and authenticating against a hierarchical directory of users, groups and devices. Active Directory, OpenLDAP, 389 Directory Server and many cloud directories speak it.

Is LDAP an authentication protocol?

Partly. LDAP's Bind operation authenticates a client to the directory, either with a DN and password (simple bind) or with a SASL mechanism such as Kerberos via GSSAPI. Many applications use an LDAP bind to check a user's password, which works but means the application handles the password. Web single sign-on protocols such as SAML and OpenID Connect avoid that.

What is the difference between LDAPS and StartTLS?

Both protect LDAP with TLS. StartTLS, defined in RFC 4511 section 4.14 and RFC 4513 section 3, upgrades a connection on port 389 by sending an extended operation before any credentials. LDAPS opens TLS immediately on port 636, which IANA registers as ldap over TLS/SSL; it is widely deployed but not part of the LDAPv3 RFCs. Either is fine if the client verifies the server certificate and refuses to bind in cleartext.

What is an anonymous or unauthenticated LDAP bind?

An anonymous bind sends an empty DN and empty password. An unauthenticated bind sends a DN with an empty password, and RFC 4513 section 5.1.2 says the server must not treat that DN as authenticated. Applications that check a password by binding, and treat any success as proof, can be logged into with an empty password. Servers should reject unauthenticated binds by default, and clients should refuse empty passwords.

LDAP Explained: How It Works, Security and When to Use It

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: the protocol itself in RFC 4511, authentication and security in RFC 4513, string forms of names in RFC 4514, search filters in RFC 4515, 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 documents user federation from LDAP and Active Directory, FreeIPA is built on 389 Directory Server with MIT Kerberos, and 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; 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). Requests can be pipelined; the messageID ties responses back to them.

The two operations that matter for identity:

Bind (§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): 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.

Security model

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

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, RFC 4513 §3) or LDAPS, and verify the server certificate per RFC 4513 §3.1.3. Servers can refuse with confidentialityRequired (13) or strongerAuthRequired (8).
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). 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.
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:

Client and server parsing bugs on domain controllers. CVE-2024-49113 (LDAPNightmare) crashes the Windows LDAP client with a crafted response, and its critical sibling CVE-2024-49112 is remote code execution class.
Directory ACLs that let the wrong client write. 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) and let case permutations reset lockout (CVE-2025-6004), which turns LDAP into a password spraying target.

Directories are also the reconnaissance source for most Active Directory attacks: 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 or OpenID Connect for web sign-on and SCIM 2.0 for pushing users into SaaS applications. For Windows and Unix single sign-on on a network, LDAP works alongside 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 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.

Walkthrough: how LDAP works, message by message. Standards: Kerberos, RADIUS, SCIM 2.0. Glossary: LDAP, directory service, Active Directory. Guides: what is ITDR, for detecting directory reconnaissance and abuse.

LDAP (Lightweight Directory Access Protocol)