Question
What is LDAP, and what is it used for in identity and access management?
Answer
LDAP (Lightweight Directory Access Protocol) is a client-server network protocol for querying and modifying distributed directory services; applications use it to look up objects and to authenticate and authorise users against a central directory.
LDAP is the language spoken between an LDAP client (an application, a mail client, a login service, a command-line tool) and a directory server (Directory System Agent). The client opens a TCP connection, sends requests such as "authenticate me as this account" or "find all entries whose surname is Meier", and the server answers.
In IAM it does two jobs at once:
- Lookup: read object data such as personal details, group memberships or computer configurations.
- Authentication and authorisation: an application can let the directory check a user's password and then read the user's groups to decide what they may do.
The current version is LDAPv3. Its technical specification is a family of RFCs: RFC 4510 is the road map, RFC 4511 defines the protocol itself, and RFC 4512 to 4519 cover the data model, authentication, DN and filter strings, URLs, syntaxes and the standard user schema. Further RFCs up to RFC 4532 (the "Who am I?" operation) add extensions.
Go deeper:
RFC 4510: LDAP Technical Specification Road Map — the short index of which RFC defines which part of LDAPv3.
Lightweight Directory Access Protocol (Wikipedia) — protocol overview, operations, URI scheme and history in one place.
Note saved — thanks!
Question
What makes a directory service (Verzeichnisdienst) different from a general-purpose relational database?
Answer
A directory is a "phone book": hierarchically structured, optimised for very fast reads, and updated with simple mechanisms without transactions, whereas a relational database is built for complex queries and transactional writes.
| Dimension | Directory service | Relational database |
|---|---|---|
| Mental model | A phone book of people, groups, devices | Tables of related records |
| Structure | Hierarchical tree of entries | Flat tables joined by keys |
| Typical load | Read-heavy: thousands of lookups per write | Mixed reads and writes |
| Updates | Simple, per entry, no transactions | ACID transactions across many rows |
| Storage | Denormalised: everything about an object sits in one entry | Normalised across tables |
The design follows from the use case. A user's name, password hash, e-mail and groups are read at every login, every e-mail address lookup and every permission check, but they change rarely. So a directory gives up multi-row transactions and joins in exchange for fast, simple reads that can be replicated easily to many sites.
Well-known directory services are Microsoft Active Directory (AD) and OpenLDAP; the server software is often just called the "LDAP server" or "LDAP daemon" (slapd in OpenLDAP).
Go deeper:
Directory service (Wikipedia) — how directories differ from relational databases and which implementations exist.
OpenLDAP Admin Guide: Introduction to directory services — "what is a directory service" and when not to use one, from the OpenLDAP project.
Note saved — thanks!