What is LDAP?

LDAP has been a foundational identity protocol since the early 1990s, when it was developed as a lighter alternative to the X.500 Directory Access Protocol. It remains embedded in most enterprise environments today and continues to underpin authentication and directory services even as organizations adopt cloud identity solutions. 

LDAP operates on a client-server model in which an LDAP client sends requests to a directory server, which stores and returns information from a centralized directory. Communication happens over TCP/IP, typically on port 389 for standard connections or port 636 for LDAPS (LDAP over SSL/TLS).

At a high level, an LDAP exchange follows four steps:

1. Connect: The client opens a TCP session with the LDAP server.
2. Bind: The client authenticates to the server, either anonymously or with credentials.
3. Request: The client issues an operation, such as a search or modify request, against the directory.
4. Response: The server returns the requested data or a status code, and the client eventually issues an unbind to close the session.

The server organizes its data in a hierarchical tree and responds to a defined set of operations, including bind, search, compare, add, modify, delete, and unbind. This shared, real-time access model is what makes LDAP well suited for environments where many applications need to query the same authoritative source for identity data.

The LDAP directory structure

An LDAP directory stores information in a hierarchical tree known as the Directory Information Tree (DIT). Each entry in the tree represents an object (such as a user, group, or device) and is identified by a unique Distinguished Name (DN) that describes its position in the hierarchy.

The DN is built from a series of components read from most specific to most general:

• cn (common name), such as a person’s full name
• ou (organizational unit), such as a department
• dc (domain component), such as parts of a domain name

For example, the DN cn=John Smith,ou=Engineering,dc=example,dc=com identifies a user named John Smith in the Engineering organizational unit within the example.com domain.

LDAP operations

LDAP defines a small set of standardized operations that cover the full lifecycle of a client’s interaction with a directory, from authentication to reads, writes, and session teardown.

• Bind: authenticates the client to the directory server and establishes an authenticated session. The bind operation is what makes LDAP usable as an authentication mechanism, since a successful bind confirms that the submitted credentials match a valid directory entry.
• Search: queries the directory for entries matching specific criteria, using a filter syntax to define which attributes and values should be returned. Search is the most frequently used LDAP operation and drives use cases such as user lookups, group membership checks, and directory browsing.
• Compare: checks whether a given attribute value matches the value stored on an entry, returning a true or false response without exposing the stored value itself. Compare is often used for lightweight verification tasks where a full search is unnecessary.
• Add: creates a new entry in the directory at a specified location in the tree. Add operations are commonly used during user provisioning, when new accounts, groups, or devices need to be registered in the directory.
• Modify: updates attributes on an existing entry, allowing changes such as password resets, group membership updates, or profile edits. Modify supports adding, replacing, and deleting individual attribute values within an entry.
• Modify DN: renames an entry or moves it to a different location in the directory tree. Modify DN is used when organizational structures change, such as when a user moves between departments or an organizational unit is restructured.
• Delete: removes an entry from the directory. Delete is typically used during deprovisioning, when accounts or resources are retired and their directory records need to be cleaned up.
• Unbind: closes the client session and terminates the connection to the server. Although the name suggests it reverses a bind, unbind actually signals that the client is finished and releases the associated server resources.
• Extended Operations: is a framework that allows vendors and standards bodies to define additional operations beyond the core set. StartTLS, which upgrades a standard LDAP connection to an encrypted one, is one of the most widely used extended operations.

LDAP is used across enterprise environments to centralize identity data and enable consistent access to that data from multiple applications and services. Common use cases include:

• Centralized authentication: validating user credentials for many applications from a single directory, reducing password sprawl and administrative overhead
• User and group management: storing and organizing records for employees, contractors, and system accounts, along with the groups and permissions associated with them
• Address book and contact lookup: allowing email clients and collaboration tools to query a corporate directory for contact information
• Device and resource management: tracking network resources such as printers, servers, and shared storage
• Single sign-on foundations: serving as the underlying identity source that SSO systems use to verify users and retrieve profile attributes

LDAP authentication is the process by which an application verifies a user’s identity by binding to an LDAP directory with the credentials the user has submitted. If the directory confirms the credentials match a valid entry, the user is authenticated and granted access to the requesting application.

The typical LDAP authentication flow proceeds as follows:

1. The user submits credentials (usually a username and password) to an application.
2. The application sends an LDAP bind request to the directory server containing those credentials.
3. The LDAP server locates the user’s entry within the directory tree using the submitted identifier.
4. The server compares the submitted password against the stored credential for that entry.
5. The server returns a success or failure response to the application.
6. On success, the application grants the user access to the requested resource.

Simple bind vs. SASL bind

LDAP supports two primary bind mechanisms, and the choice between them has significant security implications for how credentials are transmitted and verified during authentication.

A simple bind transmits the username and password directly to the server, which sends credentials in cleartext unless the connection is protected by TLS (as with LDAPS or StartTLS). 

A SASL (Simple Authentication and Security Layer) bind supports stronger authentication mechanisms, including Kerberos, client certificates, and other pluggable methods, and is preferred in environments where credential exposure is a concern.

LDAP and Active Directory are frequently confused, but they are not competing technologies. LDAP is an open protocol for accessing directory information, while Active Directory is a Microsoft directory service product that uses LDAP as one of its supported access methods.

Put simply, Active Directory speaks LDAP, but LDAP is not Active Directory. Many non-Microsoft directory services, including OpenLDAP, 389 Directory Server, and Oracle Internet Directory, also implement the LDAP protocol.

LDAP, SAML, and OAuth are related but distinct protocols that solve different problems within the broader identity and access management landscape.

• LDAP handles directory access and authentication, typically for on-premises resources and internal applications. It is a protocol for querying and modifying a directory, and it can perform authentication through the bind operation.
• SAML (Security Assertion Markup Language) enables federated authentication for web-based single sign-on, exchanging authentication and authorization assertions between an identity provider and a service provider. It is commonly used to log users into cloud and SaaS applications.
• OAuth is an authorization protocol that allows third-party applications to obtain limited access to a user’s resources without exposing credentials. It governs what an application can do on a user’s behalf, not who the user is.

Many modern environments rely on all three: LDAP as the underlying directory for user data, SAML for federated SSO into cloud applications, and OAuth for delegated API access. For a deeper look at how authentication and governance layers work together, see the RSA article on identity governance and IAM.

LDAP remains widely deployed and is not being replaced wholesale, even as organizations adopt cloud identity providers and SaaS applications. Most enterprise environments continue to rely on existing LDAP directories as the authoritative source for user data, and modern IAM platforms are generally designed to integrate with those directories rather than displace them.

The prevailing trend is toward hybrid architectures in which LDAP directories coexist with cloud identity providers, SSO platforms, and multi-factor authentication layers. Rather than performing a plain bind and granting access, organizations increasingly wrap LDAP authentication with additional controls, including multi-factor authentication, passwordless authentication, adaptive authentication, risk-based access decisions, and continuous verification. This layered approach preserves existing directory investments while addressing the credential-based risks that a bare LDAP bind cannot mitigate.

RSA’s identity and access management solutions integrate with existing LDAP directories to add modern authentication and access controls on top of legacy infrastructure. RSA extends LDAP-backed authentication with MFA, passwordless options, and risk-based access, allowing organizations to strengthen identity security without replacing the directory services they already depend on.