Lightweight Directory Access Protocol (LDAP) is a protocol for accessing directory entries, including identity attributes and group membership information.

Applications use LDAP to communicate with a directory server. The protocol supports operations such as searching for an entry or modifying an attribute when the caller has permission. LDAP defines the exchange; it does not specify one vendor’s directory product or a complete customer identity platform.

How LDAP works

A client connects to a directory server and establishes its authentication context, commonly through a bind operation. A bind can use different authentication mechanisms. Anonymous access may also be available, depending on the directory’s policy.

The client can then search within a defined part of the directory, using a filter to identify matching entries. An entry has a distinguished name and attributes allowed by its schema. The server applies access rules to decide which operations and values the client may use.

An application might look up an account and read a group membership to help decide which functions to display. Displaying an option is not an authorization control by itself: the application still needs to check permission when the user requests the protected operation.

Protecting credentials and directory data

LDAP does not automatically mean the connection is encrypted. A simple bind using a password needs appropriate transport protection to avoid exposing that password on the network. TLS can protect LDAP traffic, either through an established secure connection or an upgrade mechanism such as StartTLS.

Clients need to validate the server’s certificate and require the expected protection rather than silently continuing without it. Applications should also use directory credentials with only the permissions they need.

Search filters require safe handling of untrusted input. An application that inserts customer-supplied text directly into a filter can create an LDAP injection vulnerability. Established escaping and query-construction practices help maintain the intended search conditions.

LDAP in a modern identity architecture

A legacy application may authenticate directly against a directory using LDAP. A newer customer application might instead use OpenID Connect through an identity provider, which integrates with the directory behind the scenes.

The latter arrangement can move application-facing sign-in away from direct password handling, but the directory integration still needs protection and lifecycle controls. A modern federation interface does not automatically fix excessive permissions in the underlying directory.

For a portal migration, inventory which applications perform LDAP searches and which rely on specific attributes. Replacing the sign-in screen without accounting for those dependencies can leave authorization behavior inconsistent.

Frequently asked questions

Is LDAP the same as Active Directory?

No. LDAP is a protocol. Active Directory Domain Services supports LDAP and provides additional capabilities, including domain authentication and administration.

Does LDAP always send passwords without encryption?

No. LDAP can use protected connections and different authentication mechanisms. A password-based simple bind must not be treated as safe without the required connection protection.

Does LDAP provide single sign-on by itself?

No. LDAP provides directory operations and authentication mechanisms. Cross-application sign-on normally requires additional protocols and session behavior.

Related: Directory Consolidation · Identity Provider (IdP) · Legacy IdP Migration · OpenID Connect (OIDC) · Injection Attacks · User Management