LDAP
acronymStands for: Lightweight Directory Access Protocol
The protocol for querying and modifying directory services like Active Directory.
Lightweight Directory Access Protocol (RFC 4511) reads and writes hierarchical directory data - users, groups, attributes. It is central to enterprise authentication and identity. RFC 4511 (June 2006, edited by Sermersheim of Novell, Standards Track, obsoleting RFC 2251) defines the protocol as a set of operations carried as ASN.1 BER-encoded messages, "mapped directly onto the TCP bytestream", on the IANA-assigned port 389: Bind, Unbind, Search, Modify, Add, Delete, ModifyDN, Compare, Abandon, Extended and IntermediateResponse. A Bind is authentication, with a simple choice that sends a clear-text password or a SASL mechanism; the StartTLS extended operation, identified by the OID 1.3.6.1.4.1.1466.20037, upgrades the connection to TLS, and LDAPS wraps it in TLS from the first byte. A Search is a base entry, a scope, a filter and a list of attributes to return, and the filter grammar is the part that defeats people. The protocol is how applications ask who someone is and which groups they belong to, how RADIUS and web-authentication servers verify passwords, and how a directory's tree is read by anything that needs an organisation's shape.
LDAP is how applications ask a directory who someone is and what groups they belong to, and it long predates the identity protocols that layer on top of it. Active Directory speaks it, most enterprise directories speak it, and a surprising amount of authentication still bottoms out in an LDAP query. The current specification is RFC 4511, published in June 2006, edited by Sermersheim of Novell as a Standards Track document obsoleting RFC 2251, and it describes a protocol of eleven operations: Bind, Unbind, Search, Modify, Add, Delete, ModifyDN, Compare, Abandon and Extended, plus the IntermediateResponse that lets a long operation report progress. Each is an LDAPMessage encoded in ASN.1 Basic Encoding Rules, and the RFC specifies that the encoded PDUs are "mapped directly onto the TCP bytestream"; the IANA-assigned port is 389.
The model catches people out because it is hierarchical rather than relational. Entries live in a tree, identified by a distinguished name that reads from the specific to the general, and queries are filters in prefix notation with their own parenthesised grammar. Writing one correctly the first time is uncommon, and a filter that is merely wrong rather than malformed will return the wrong users silently. A Search carries a base object to start from, a scope that says whether to look at the base alone, one level down or the whole subtree, the filter, and the list of attributes wanted; the LDAP filter explainer tool on this site exists because the filter is where the time goes.
Two operational details cause most incidents. A bind is authentication, and an anonymous or unprivileged bind may succeed while returning far less than expected, which looks like missing data rather than missing permission. The Bind operation's AuthenticationChoice is either simple, in which the password is sent in clear text inside the message, or sasl, which names a mechanism; passwords are UTF-8 strings. And plain LDAP is unencrypted, so credentials cross the network in the clear unless LDAPS or StartTLS is in use, which is why directory traffic is a standing finding in security reviews. RFC 4511 defines StartTLS as an extended operation, with the object identifier 1.3.6.1.4.1.1466.20037, that upgrades an existing port 389 connection to TLS; LDAPS, TLS from the first byte on its own port, is the other way, and the LDAPS entry covers the difference.
In the AAA world LDAP is the back end rather than the front. A RADIUS server that receives an EAP-TTLS/PAP exchange or a web-authentication login verifies the password with a Bind as that user, or compares it against an attribute; a policy engine reads group membership with a Search to decide which VLAN or role to return; a web application maps a login to a person by a Search on an identifier attribute. The directory's schema, its naming conventions and its access controls therefore shape every authorisation built on top, and a change to any of them shows up as authentication failures in systems that never mention LDAP in their names.
The companion material carries the detail: the LDAP fundamentals article for the tree and the operations, the LDAP search filters article and the filter explainer tool for the grammar, and the Active Directory entry for the directory that most enterprises actually run behind the protocol.
Also known as: ldap, tcp 389, directory protocol, bind, distinguished name