LDAP is not a database, it’s a network protocol for accessing and maintaining distributed directory information services.
Let’s see it in action. Imagine you have a list of all your employees, their departments, phone numbers, and email addresses. This isn’t just a flat list; it’s structured. Alice is in the "Engineering" department, Bob is in "Sales," and so on. LDAP organizes this information like a tree, starting from a root (e.g., your company domain) and branching out to organizational units (like departments) and then to individual entries (like employees).
dc=example,dc=com
ou=Engineering
uid=alice,ou=Engineering,dc=example,dc=com
cn: Alice Smith
mail: alice.smith@example.com
uid: alice
department: Engineering
ou=Sales
uid=bob,ou=Sales,dc=example,dc=com
cn: Bob Johnson
mail: bob.johnson@example.com
uid: bob
department: Sales
Here, dc=example,dc=com is the root. ou=Engineering and ou=Sales are organizational units. uid=alice,ou=Engineering,dc=example,dc=com is the Distinguished Name (DN) for Alice’s entry. The DN is like a unique, absolute path to an object in the directory. Each part of the DN (uid=alice, ou=Engineering, dc=example,dc=com) is a Relative Distinguished Name (RDN).
The core problem LDAP solves is centralized management of identity and access information. Instead of every application having its own user database, you have one authoritative source. When a user tries to log into an application, that application can ask the LDAP server: "Does user 'alice' exist, and is her password 'supersecret'?" The LDAP server checks its directory and responds. This dramatically simplifies user management, especially in large organizations.
Internally, LDAP works by defining a schema. The schema dictates what types of objects can exist in the directory (like person, group, organizationalUnit) and what attributes each object type can have (like cn for common name, mail for email, uid for user ID). When you add an entry, it must conform to the schema. The protocol itself defines operations like:
- Bind: Authenticating to the directory server.
- Search: Finding entries based on criteria.
- Add/Modify/Delete: Managing entries.
- Compare: Checking if an attribute of an entry matches a provided value.
Let’s say you want to find all employees in the "Engineering" department. Your LDAP client would send a search request to the LDAP server. The request would specify:
- Base DN:
dc=example,dc=com(where to start searching) - Scope:
subtree(search this DN and everything below it) - Filter:
(&(objectClass=person)(department=Engineering))(find entries that are persons and have the department attribute set to "Engineering")
The LDAP server processes this, traverses its directory tree, and returns all matching entries. Each entry comes back with its DN and all its attributes.
Many people think of LDAP as just for authentication, but its power lies in its flexibility as a directory service. You can store virtually any structured information that benefits from hierarchical organization and centralized access: network configurations, printer locations, application settings, device information, and yes, user credentials. The key is that it’s designed for reading data far more often than writing it, making it incredibly efficient for lookups.
What most people miss is that LDAP is fundamentally a protocol, not a specific server implementation. OpenLDAP, Microsoft Active Directory, and 389 Directory Server are all LDAP servers, meaning they speak the LDAP protocol. You can connect to any of them using any LDAP client, regardless of the server software. This interoperability is a core strength.
The next logical step is understanding how to secure LDAP communications, particularly with LDAPS and StartTLS.