LDAP: Lightweight Directory Access Protocol
The standard protocol for accessing and managing directory services like Active Directory, OpenLDAP, and cloud identity providers.
Type
Application Protocol
Ports
389 (LDAP), 636 (LDAPS)
Standard
RFC 4511 (2006)
Model
Client-Server
What is LDAP?
LDAP (Lightweight Directory Access Protocol) is a protocol for reading and writing data in directory services. A directory service is like a specialized database optimized for lookups rather than frequent writes. It stores information about people, groups, devices, and services in a hierarchical tree structure.
LDAP was created in 1993 as a simpler alternative to the X.500 Directory Access Protocol (DAP), which was complex and required the full OSI stack. By running over TCP/IP instead, LDAP made directory services accessible to a much wider range of applications and platforms. The current version, LDAPv3, is defined in RFC 4511 and has been the standard since 2006.
LDAP runs over TCP/IP on port 389 for unencrypted connections and port 636 for LDAPS (LDAP over TLS). It is the backbone of enterprise identity management. Microsoft Active Directory, OpenLDAP, Apache Directory Server, and cloud services like Azure AD all speak LDAP.
When you log into a corporate network, VPN, or Wi-Fi, LDAP is typically how your credentials are verified. It is also used behind the scenes for email address lookups, certificate validation, and application authorization. Despite being over 30 years old, LDAP remains essential to how organizations manage identity and access.
The LDAP Directory Tree
LDAP organizes data in a tree structure called the Directory Information Tree (DIT). Every entry in the tree has a Distinguished Name (DN) that uniquely identifies it, similar to a file path. For example: uid=jsmith,ou=People,dc=example,dc=com. The DN reads from the most specific entry on the left to the root on the right. Each component of the DN is called a Relative Distinguished Name (RDN).
The tree starts at the root, which is usually based on the organization's domain name (for example, dc=example,dc=com). It branches into Organizational Units (OUs) that group related entries. Common OUs include People (for user accounts), Groups (for access control groups), and Services (for application accounts).
Each entry in the tree has attributes, which are key-value pairs defined by an object class. For example, a person entry might have attributes like cn (common name), mail, uid, and userPassword. Object classes define which attributes are required and which are optional for a given entry type.
How LDAP Communication Works
LDAP uses a client-server model over TCP. A typical session has three phases: Bind (authenticate), perform operations (search, add, modify, delete), and Unbind (disconnect). The client opens a TCP connection to port 389, sends a Bind request with credentials, and the server responds with success or failure.
After binding, the client can send any number of operation requests. Each request includes a message ID so the client can match responses to requests, even when multiple operations are in progress at once. The server processes each request and sends back one or more response messages.
The most common operation is Search, which takes a base DN (where to start looking), a scope (how deep to search), and a filter (what to match). The server returns matching entries one at a time as individual Search Result Entry messages, followed by a Search Result Done message that indicates the operation is complete.
LDAP Operations
LDAP defines a small set of operations that cover all directory interactions. Each operation is sent as a request message, and the server replies with a response that includes a result code indicating success or failure.
Bind authenticates the client to the server. Simple bind sends a DN and password, which are transmitted in plaintext and should only be used over a TLS-encrypted connection. SASL bind supports stronger authentication mechanisms like Kerberos, DIGEST-MD5, and EXTERNAL (client certificates).
Search is the most frequently used operation. It takes a base DN (the starting point), a scope (base, one level, or subtree), and a filter expression that defines which entries to return. The client can also specify which attributes to include in the results and set a size limit.
Add creates a new entry in the directory. The client sends the full DN of the new entry along with all its attributes. The parent entry must already exist in the tree.
Modify changes attributes of an existing entry. A single Modify request can add new attribute values, delete existing values, or replace all values of an attribute. Multiple changes can be batched into one request.
Delete removes an entry from the directory. The entry must be a leaf node with no children. To delete an entire subtree, you must delete the children first or use the subtree delete control extension.
Modify DN renames or moves an entry in the tree. It can change the RDN of an entry (renaming it) or move the entry to a different location in the DIT by specifying a new parent DN.
Compare tests whether an entry has a specific attribute value without retrieving the entire entry. This is useful for checking group membership or verifying a password hash without exposing the full attribute data.
Unbind closes the connection. Despite its name, Unbind is not the opposite of Bind. It simply signals to the server that the client is done and the TCP connection should be closed. The server does not send a response to an Unbind request.
LDAP Search Filters
LDAP search filters use a prefix notation enclosed in parentheses. Simple filters compare a single attribute to a value. Compound filters combine multiple conditions using AND, OR, and NOT operators. The filter syntax is defined in RFC 4515 and is consistent across all LDAP implementations.
Filters support exact matches, substring matches (using the * wildcard), presence checks, and approximate matches. You can nest compound filters to build complex queries. Here are some common examples:
Equality Filter
(uid=jsmith)Matches the entry where uid is exactly "jsmith".
Substring Filter
(cn=John*)Matches any entry where cn starts with "John".
AND Filter
(&(objectClass=person)(department=Engineering))Matches entries that are persons AND belong to the Engineering department.
OR Filter
(|(mail=*@example.com)(mail=*@corp.com))Matches entries with an email at either example.com or corp.com.
NOT Filter
(!(accountDisabled=TRUE))Matches entries where accountDisabled is not TRUE (active accounts only).
| Operator | Syntax | Description |
|---|---|---|
= | (attr=value) | Equality match. Returns entries where the attribute equals the value. |
~= | (attr~=value) | Approximate match. Returns entries where the attribute is approximately equal (sounds like). |
>= | (attr>=value) | Greater than or equal. Useful for numeric or date comparisons. |
<= | (attr<=value) | Less than or equal. Useful for numeric or date comparisons. |
=* | (attr=*) | Presence check. Returns entries where the attribute exists, regardless of value. |
& | (&(filter1)(filter2)) | AND. All sub-filters must match. |
| | (|(filter1)(filter2)) | OR. At least one sub-filter must match. |
! | (!(filter)) | NOT. The sub-filter must not match. |
LDAP vs LDAPS vs StartTLS
LDAP on port 389 is unencrypted by default. Credentials sent in a simple Bind request travel in plaintext, making them vulnerable to interception on the network. There are two options for adding encryption to LDAP connections.
LDAPS (LDAP over TLS) runs on port 636. The entire connection is encrypted from the very start, before any LDAP messages are exchanged. This is similar to how HTTPS works on port 443. LDAPS is straightforward to configure but requires a dedicated port and does not allow unencrypted fallback.
StartTLS begins as a plaintext connection on port 389, then upgrades to TLS using an extended operation within the LDAP protocol. StartTLS is the recommended approach in modern deployments because it uses the standard LDAP port and allows the server to support both encrypted and unencrypted connections on the same port. Microsoft Active Directory, OpenLDAP, and most modern directory servers support both LDAPS and StartTLS.
LDAP and Active Directory
Microsoft Active Directory (AD) is the most widely deployed LDAP directory in the world. AD uses LDAP as its primary access protocol for reading and writing directory data. When people say "LDAP authentication" in a corporate environment, they almost always mean authenticating against Active Directory.
Active Directory extends the standard LDAP schema with Microsoft-specific object classes and attributes for managing Windows domains, group policies, and Kerberos authentication. AD uses LDAP for client queries and modifications but adds its own replication protocol between domain controllers to keep directory data synchronized across the network.
AD supports LDAP on port 389, LDAPS on port 636, and Global Catalog queries on ports 3268 (unencrypted) and 3269 (over TLS). The Global Catalog is a read-only, partial replica that contains a subset of attributes for every object in the entire Active Directory forest, making it useful for cross-domain searches in large organizations.
Common LDAP Attributes
| Attribute | Full Name | Example |
|---|---|---|
cn | Common Name | John Smith |
dn | Distinguished Name | uid=jsmith,ou=People,dc=example,dc=com |
uid | User ID | jsmith |
mail | john@example.com | |
ou | Organizational Unit | Engineering |
dc | Domain Component | example |
sn | Surname | Smith |
givenName | Given Name | John |
memberOf | Group Membership | cn=admins,ou=Groups,dc=example,dc=com |
userPassword | Password | {SSHA}...hashed... |
Common Use Cases for LDAP
- Corporate authentication: single sign-on across applications, allowing employees to use one set of credentials for email, VPN, intranet, and other services.
- Email address books: email clients like Outlook and Thunderbird query LDAP directories to look up contact information and email addresses.
- VPN and Wi-Fi authentication: RADIUS servers often authenticate users against an LDAP directory before granting network access.
- Linux and Unix authentication: tools like SSSD and NSS allow Linux systems to authenticate users against a central LDAP directory instead of managing local accounts.
- Application user directories: web applications and enterprise software use LDAP to store and retrieve user profiles, roles, and permissions.
- Certificate management: LDAP directories can store X.509 certificates and certificate revocation lists (CRLs) for PKI deployments.
Frequently Asked Questions About LDAP
What is the difference between LDAP and a database?
LDAP directories are optimized for read-heavy workloads with infrequent writes, while relational databases are designed for balanced read and write operations. LDAP organizes data in a hierarchical tree, whereas databases use tables with rows and columns. LDAP also has a standardized protocol for network access, which means any LDAP client can connect to any LDAP server without vendor-specific drivers.
Is LDAP still used today?
Yes. LDAP remains widely used in enterprises for identity management and authentication. Microsoft Active Directory, which uses LDAP as its core protocol, is deployed in the vast majority of large organizations. Cloud identity providers like Azure AD and Okta also support LDAP for backward compatibility with on-premises applications.
What is the difference between LDAP and Active Directory?
LDAP is a protocol, while Active Directory is a directory service product from Microsoft. Active Directory uses LDAP as one of its access protocols, but it also includes additional features like Kerberos authentication, Group Policy, DNS integration, and multi-master replication that are not part of the LDAP standard. You can think of LDAP as the language and Active Directory as a product that speaks that language.
What port does LDAP use?
LDAP uses TCP port 389 for unencrypted connections and StartTLS. LDAPS (LDAP over TLS) uses TCP port 636. Active Directory also uses ports 3268 and 3269 for Global Catalog queries. All of these are IANA-registered port numbers.
How do I test LDAP connectivity?
The most common tool for testing LDAP is ldapsearch, which is available on Linux and macOS. You can test a connection with a command like ldapsearch -H ldap://server:389 -x -b "dc=example,dc=com". On Windows, you can use the dsquery and ldp.exe tools. For quick connectivity checks, a simple telnet server 389 or Test-NetConnection command will verify that the LDAP port is open and reachable.
Related Protocols
- TLS: provides encryption for LDAPS and StartTLS connections.
- DNS: used for SRV record discovery to locate LDAP servers automatically.
- TCP: the transport layer protocol that carries LDAP messages.
- SSH: can be used to tunnel LDAP connections securely across untrusted networks.
- HTTP: some modern directory services offer REST-based APIs alongside LDAP access.