[1] 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.
Similarly, a telephone directory is a list of subscribers with an address and a phone number.
LDAP is specified in a series of Internet Engineering Task Force (IETF) Standard Track publications known as Request for Comments (RFCs), using the description language ASN.1.
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.
These companies introduced the concept of directory services to information technology and computer networking, their input culminating in the comprehensive X.500 specification,[6] a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s.
The protocol was originally created[7] 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[8] 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.
In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP.
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.
A common alternative method of securing LDAP communication is using an SSL tunnel.
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.
Its parameters are: The server returns the matching entries and potentially continuation references.
MODIFY requests are subject to access controls as implemented by the server.
The MODIFY operation requires that the distinguished name (DN) of the entry be specified, and a sequence of changes.
The following example using LDIF increments employeeNumber by 5: When LDAP servers are in a replicated topology, LDAP clients should consider using the post-read control to verify updates instead of a search after an update.
[19] The post-read control is designed so that applications need not issue a search request after an update – it is bad form to retrieve an entry for the sole purpose of checking that an update worked because of the replication eventual consistency model.
Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), optionally the new parent's DN, and a flag that indicates whether to delete the value(s) in the entry that match the old RDN.
[citation needed] The StartTLS operation establishes Transport Layer Security (the descendant of SSL) on the connection.
By using the SASL/EXTERNAL, the client requests the server derive its identity from credentials provided at a lower level (such as TLS).
A similar Cancel extended operation does send responses, but not all implementations support this.
[22] Clients can abort a session by simply closing the connection, but they should use Unbind.
[24] An LDAP uniform resource identifier (URI) scheme exists, which clients support in varying degrees, and servers return in referrals and continuation references (see RFC 4516): Most of the components described below are optional.
Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema subentry.
Each entry must have an objectClass attribute, containing named classes defined in the schema.
As LDAP has gained momentum, vendors have provided it as an access protocol to other services.
For example, Unix user and group information can be stored in LDAP and accessed via PAM and NSS modules.
An example of such data model is the GLUE Schema,[26] which is used in a distributed information system based on LDAP that enable users, applications and services to discover which services exist in a Grid infrastructure and further information about their structure and state.