Lightweight Directory Access Protocol, or LDAP, serves as the open‑standard method for querying and modifying directory services over an IP network. At its core, the protocol defines a structured way to look up information about users, groups, devices, and other resources that live in a centralized repository. Rather than storing data itself, LDAP acts as a language that clients and directory servers use to communicate, enabling authentication, authorization, and address book functionality across diverse systems.
Core concepts and directory structure
To understand how LDAP works, it helps to think of a directory as a hierarchical tree, similar to a filesystem or an organizational chart. The tree’s root represents the enterprise or domain, and beneath it branch organizational units, sites, or departments. Each entry in the directory is a collection of attributes, such as a person’s common name, email address, or member‑of relationships. Because the structure is predictable, software can reliably locate resources by traversing this distinguished name, or DN, which is the full path to a specific entry.
Data model and object classes
Entries in an LDAP directory are not arbitrary; they follow a strict data model defined in schema. Each object class constrains what attributes an entry can have and whether they are required or optional. For example, a person object class might demand a surname and a common name, while allowing optional fields like telephone number or photo. This schema governance ensures consistency, so different applications can rely on a shared understanding of what attributes mean and how they should be formatted.
The communication flow
At a practical level, an LDAP session begins when a client opens a TCP or UDP connection to a directory server, typically on port 389 for unencrypted traffic or 636 for LDAP over TLS. After the transport connection is established, the client sends a bind request to authenticate, either with simple authentication, which transmits a password in clear text over encrypted channels, or with more advanced methods such as SASL. Once authenticated, the client can perform search, compare, add, modify, or delete operations, each of which corresponds to a specific protocol message defined in the specification.
Search operations and filtering
One of the most common uses of LDAP is searching for entries that match particular criteria. A search request includes a base object, a scope that defines how deep the query goes in the hierarchy, and a filter written in a compact string format. For instance, a filter might look for all users in a specific department whose account status is active. Servers evaluate these filters efficiently, often with the help of indexes on frequently queried attributes, so that even large directories can return results quickly without scanning every entry.
Security considerations and modern deployments
Security is a critical aspect of how LDAP works in production environments. Unencrypted LDAP is vulnerable to eavesdropping and man‑in‑the‑middle attacks, which is why LDAPS, or LDAP over SSL/TLS, is widely recommended. Alternatively, StartTLS can upgrade a plain connection to an encrypted one after the initial handshake. Beyond transport security, administrators use carefully designed access control lists to limit who can read or modify specific parts of the directory, ensuring that sensitive information is exposed only to authorized applications and users.
Replication and high availability
Enterprise deployments rarely rely on a single directory server. Replication allows changes made on one supplier server to be copied to one or more consumers, providing redundancy and improving read performance. During replication, servers exchange update messages, ensuring that identical copies remain consistent across locations. This architecture supports failover scenarios, where clients can automatically switch to a healthy replica if a primary server becomes unavailable, thereby maintaining continuous access to directory information.
