Lightweight Directory Access Protocol (LDAP ) is an Internet protocol for accessing directory information services that act in accordance with X.500 data and service models." A full description of the protocol can be found in the "Lightweight Directory Access Protocol (LDAP) Technical Specification Road Map" and its references.
Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.
A common use of LDAP is to provide a central place to store usernames and passwords. This allows many different applications and services to connect to the LDAP server to validate users.
LDAP is a simpler (lightweight) subset of the standards in the X.500 series, particularly the X.511 Directory Access Protocol. Because of this relationship, LDAP is sometimes called X.500 Lite.
The main components of LDAP are: Protocol (): An application protocol that runs over an Internet Protocol (IP) network used to communicate with a directory service Directory Information Models (): A specification for systems that implement directory services, i.e., "a collection of open systems cooperating to provide directory services" Schema for User Applications (): A standard and extensible data schema for information to be help in a directory service - a "specification of attribute types and object classes intended for use by LDAP"
History Telecommunication companies' understanding of directory requirements was well developed after some 70 years of producing and managing telephone directories. These companies introduced the concept of directory services to information technology and computer networking, their input culminating in the comprehensive X.500 specification,The X.500 series - ITU-T Rec. X.500 to X.521 a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s.
X.500 directory services were traditionally accessed via the X.511 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols.
The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, Colin Robbins of Nexor and Wengyik Yeong of Performance Systems International, circa 1993, as a successor to DIXIE and DAS. Mark Wahl of Critical Angle Inc., Tim Howes, and Steve Kille started work in 1996 on a new version of LDAP, LDAPv3, under the aegis of the Internet Engineering Task Force (IETF). LDAPv3, first published in 1997, superseded LDAPv2 and added support for extensibility, integrated the Simple Authentication and Security Layer, and better aligned the protocol to the 1993 edition of X.500. Further development of the LDAPv3 specifications themselves and of numerous extensions adding features to LDAPv3 has come through the IETF.
In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP. It was renamed with the expansion of the scope of the protocol beyond directory browsing and searching, to include directory update functions. It was given its Lightweight name because it was not as network intensive as its DAP predecessor and thus was more easily implemented over the Internet due to its relatively modest bandwidth usage.
LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP). It is also used as the basis for Microsoft's Active Directory.
Protocol overview A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP and UDP port 389, or on port 636 for LDAPS (LDAP over TLS/SSL, see below). The client then sends an operation request to the server, and a server sends responses in return. With some exceptions, the client does not need to wait for a response before sending the next request, and the server may send the responses in any order. All information is transmitted using Basic Encoding Rules (BER).
The client may request the following operations: StartTLS – use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection Bind – authenticate and specify LDAP protocol version Search – search for and/or retrieve directory entries Compare – test if a named entry contains a given attribute value Add a new entry Delete an entry Modify an entry Modify Distinguished Name (DN) – move or rename an entry Abandon – abort a previous request Extended Operation – generic operation used to define other operations Unbind – close the connection (not the inverse of Bind)
In addition the server may send "Unsolicited Notifications" that are not responses to any request, e.g. before the connection is timed out.
A common alternative method of securing LDAP communication is using an SSL tunnel. The default port for LDAP over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2), but it was never standardized in any formal specification. This usage has been deprecated along with LDAPv2, which was officially retired in 2003.RFC3494
Directory structure The protocol provides an interface with directories that follow the 1993 edition of the X.500 model: An entry consists of a set of attributes. An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema (see below). Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as the full file path and the RDN as its relative filename in its parent folder (e.g. if /foo/bar/myfile.txt were the DN, then myfile.txt would be the RDN).
A DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID might be provided in the set of the entry's operational attributes.
An entry can look like this when represented in LDAP Data Interchange Format (LDIF), a plain text format (as opposed to a binary protocol such as LDAP itself): dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888 555 1232 mail: [email protected] manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top "dn" is the distinguished name of the entry; it is neither an attribute nor a part of the entry. "cn=John Doe" is the entry's RDN (Relative Distinguished Name), and "dc=example,dc=com" is the DN of the parent entry, where "dc" denotes 'Domain Component'. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, "mail" for email address, and "sn" for surname.
A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com" and its children. Servers may also hold references to other servers, so an attempt to access "ou=department,dc=example,dc=com" could return a referral or continuation reference to a server that holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client.
LDAP rarely defines any ordering: The server may return the values of an attribute, the attributes in an entry, and the entries found by a search operation in any order. This follows from the formal definitions: an entry is defined as a set of attributes, and an attribute is a set of values, and sets need not be ordered.
Operations
Add The ADD operation inserts a new entry into the directory-server database.Add section of RFC4511 If the distinguished name in the add request already exists in the directory, then the server will not add a duplicate entry but will set the result code in the add result to decimal 68, "entryAlreadyExists".LDAP result codes LDAP-compliant servers will never dereference the distinguished name transmitted in the add request when attempting to locate the entry; that is, distinguished names are never de-aliased. LDAP-compliant servers will ensure that the distinguished name and all attributes conform to naming standards. The entry to be added must not exist, and the immediate superior must exist. dn: uid=user,ou=people,dc=example,dc=com changetype: add objectClass:top objectClass:person uid: user sn: last-name cn: common-name userPassword: password
In the above example, uid=user,ou=people,dc=example,dc=com must not exist, and ou=people,dc=example,dc=com must exist.
Bind (authenticate) When an LDAP session is created, that is, when an LDAP client connects to the server, the authentication state of the session is set to anonymous. The BIND operation establishes the authentication state for a session.
Simple BIND and SASL PLAIN can send the user's DN and password in plaintext, so the connections utilizing either Simple or SASL PLAIN should be encrypted using Transport Layer Security (TLS). The server typically checks the password against the userPassword attribute in the named entry. Anonymous BIND (with empty DN and password) resets the connection to anonymous state.
Simple Authentication and Security Layer (SASL) BIND provides authentication services through a wide range of mechanisms, e.g. Kerberos or the client certificate sent with TLS.SASL Mechanisms at IANA
BIND also sets the LDAP protocol version by sending a version number as an integer. If the client requests a version that the server does not support, the server must set the result code in the BIND response to the code for a protocol error. Normally clients should use LDAPv3, which is the default in the protocol but not always in LDAP libraries.
BIND had to be the first operation in a session in LDAPv2, but is not required as of LDAPv3. In LDAPv3, each successful BIND request changes the authentication state of the session and each unsuccessful BIND request resets the authentication state of the session.
Delete To delete an entry, an LDAP client transmits a properly formed delete request to the server.RFC4511: delete request A delete request must contain the distinguished name of the entry to be deleted Request controls may also be attached to the delete request Servers do not dereference aliases when processing a delete request Only leaf entries (entries with no subordinates) may be deleted by a delete request. Some servers support an operational attribute hasSubordinates whose value indicates whether an entry has any subordinate entries, and some servers support an operational attribute numSubordinatesBoreham Draft (numSubordinates) indicating the number of entries subordinate to the entry containing the numSubordinates attribute. Some servers support the subtree delete request control permitting deletion of the DN and all objects subordinate to the DN, subject to access controls. Delete requests are subject to access controls; that is, whether a connection with a given authentication state will be permitted to delete a given entry is governed by server-specific access control mechanisms.
Search and compare