Lightweight Directory Access Protocol
Encyclopedia
The Lightweight Directory Access Protocol (LDAP; icon) is an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol
(IP) network. LDAP is defined in terms of ASN.1
and transmitted using BER
.
Directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate electronic mail directory. 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 Requests for comments
(RFCs). The latest version is Version 3, published as RFC 4510.
and computer networking, their input culminating in the comprehensive X.500
specification, a suite of protocols produced by the International Telecommunication Union
(ITU) in the 1980s.
X.500 directory services were traditionally accessed via the X.500 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.
Standalone LDAP directory servers soon followed, as did directory servers supporting both DAP and LDAP. The latter has become popular in enterprises, as LDAP removed any need to deploy an OSI network. Today, X.500
directory protocols including DAP can also be used directly over TCP/IP.
The protocol was originally created by Tim Howes
of the University of Michigan
, Steve Kille
of Isode Limited
, and Wengyik Yeong
of Performance Systems International
, circa 1993. 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).
(DSA), by default on TCP
port
389. The client then sends an operation request to the server, and the 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.
The client may request the following operations:
In addition the server may send "Unsolicited Notifications" that are not responses to any request, e.g. before it times out a connection.
A common alternate method of securing LDAP communication is using an SSL tunnel
. This is denoted in LDAP URLs by using the URL scheme "ldaps". 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.
model:
Be aware that 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)
(LDAP itself is a binary protocol
):
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: john@example.com
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's 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 e-mail 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 which 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.
, so the connection should be protected 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. SASL
(Simple Authentication and Security Layer) Bind provides authentication services through a wide range of mechanisms, e.g. Kerberos or the client certificate sent with TLS.
Bind also sets the LDAP protocol version. The version is an integer and at present must be either 2 (two) or 3 (three), although the standard supports integers between 1 and 127 (inclusive) in the protocol. 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 in LDAPv3 (the current LDAP version).
baseObject : The DN (Distinguished Name) of the entry at which to start the search,
scope : What elements below the baseObject to search. This can be
filter : Criteria to use in selecting elements within scope. For example, the filter
derefAliases : Whether and how to follow alias entries (entries which refer to other entries),
attributes : Which attributes to return in result entries.
sizeLimit, timeLimit : Maximum number of entries to return, and maximum time to allow search to run. These values, however, cannot override any restrictions the server places on size limit and time limit.
typesOnly : Return attribute types only, not attribute values.
The server returns the matching entries and potentially continuation references. These may be returned in any order. The final result will include the result code.
The Compare operation takes a DN, an attribute name and an attribute value, and checks if the named entry contains that attribute with that value.
Modify takes a list of attributes to modify and the modifications to each: Delete the attribute or some values, add new values, or replace the current values with the new ones.
Add operations also can have additional attributes and values for those attributes.
Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), optionally the new parent's DN, and a flag which says whether to delete the value(s) in the entry which match the old RDN. The server may support renaming of entire directory subtrees.
An update operation is atomic: Other operations will see either the new entry or the old one. On the other hand, LDAP does not define transactions of multiple operations: If you read an entry and then modify it, another client may have updated the entry in the meantime. Servers may implement extensions which support this, though.
(the descendant of SSL
) on the connection. It can provide data confidentiality (to protect data from being observed by third parties) and/or data integrity protection (which protects the data from tampering). During TLS negotiation the server sends its X.509
certificate to prove its identity. The client may also send a certificate to prove its identity. After doing so, the client may then use SASL
/EXTERNAL. By using the SASL/EXTERNAL, the client requests the server derive its identity from credentials provided at a lower level (such as TLS). Though technically the server may use any identity information established at any lower level, typically the server will use the identity information established by TLS.
Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as "LDAP over SSL") protocol on a separate port, by default 636. LDAPS differs from LDAP in two ways:
1) upon connect, the client and server establish TLS before any LDAP messages are transferred (without a StartTLS operation) and
2) the LDAPS connection must be closed upon TLS closure.
LDAPS was used with LDAPv2, because the StartTLS operation had not yet been defined. The use of LDAPS is deprecated, and modern software should only use StartTLS.
Clients can abort a session by simply closing the connection, but they should use Unbind. Unbind allows the server to gracefully close the connection and free resources that it would otherwise keep for some time until discovering the client had abandoned the connection. It also instructs the server to cancel operations that can be canceled, and to not send responses for operations that cannot be canceled.
format exists which clients support in varying degree, and which servers return in referrals and continuation references (see RFC 4516):
ldap://host:port/DN?attributes?scope?filter?extensions
Most of the components, which are described below, are optional.
For example, "
.
There is a similar non-standard
known as a directory information tree
(DIT).
The schema of a Directory Server defines a set of rules that govern the kinds of information that the server can hold. It has a number of elements, including:
Attributes are the elements responsible for storing information in a directory, and the schema defines the rules for which attributes may be used in an entry, the kinds of values that those attributes may have, and how clients may interact with those values.
Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema subentry.
The schema defines object classes. Each entry must have an objectClass attribute, containing named classes defined in the schema. The schema definition of the classes of an entry defines what kind of object the entry may represent - e.g. a person, organization or domain. The object class definitions also define the list of attributes that must contain values and the list of attributes which may contain values.
For example, an entry representing a person might belong to the classes "top" and "person". Membership in the "person" class would require the entry to contain the "sn" and "cn" attributes, and allow the entry also to contain "userPassword", "telephoneNumber", and other attributes. Since entries may have multiple ObjectClasses values, each entry has a complex of optional and mandatory attribute sets formed from the union of the object classes it represents. ObjectClasses can be inherited, and a single entry can have multiple ObjectClasses values which define the available and required attributes of the entry itself. A parallel to the schema of an objectClass is a class
definition and an instance in Object-oriented programming
, representing LDAP objectClass and LDAP entry, respectively.
Directory servers may publish the directory schema controlling an entry at a base DN given by the entry's subschemaSubentry operational attribute. (An operational attribute describes operation of the directory rather than user information and is only returned from a search when it is explicitly requested.)
Server administrators can add additional schema entries in addition to the provided schema elements. A schema for representing individual people within organizations is termed a white pages schema
.
For example, data storage in the server is not specified - the server may use flat files, databases, or just be a gateway to some other server. Access control is not standardized, though there has been work on it and there are commonly used models. Users' passwords may be stored in their entries or elsewhere. The server may refuse to perform operations when it wishes, and impose various limits.
Most parts of LDAP are extensible. Examples: One can define new operations. Controls may modify requests and responses, e.g. to request sorted search results. New search scopes and Bind methods can be defined. Attributes can have options that may modify their semantics.
databases through LDAP, even though LDAP does not readily lend itself to this. X.500
servers may support LDAP as well.
Similarly, data which were previously held in other types of data stores are sometimes moved to LDAP directories. For example, Unix user and group information can be stored in LDAP and accessed via PAM
and NSS
modules. LDAP is often used by other services for authentication.
An example of such data model is the GLUE Schema , 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.
An organization with the domain example.org may use the top level LDAP DN
Primarily two common styles of naming are used in both X.500 [2008] and LDAPv3 which are documented in the ITU specifications and IETF RFCs. The original form takes the top level object as the country object, such as c=US, c=FR. The domain component model uses the model described above. An example of country based naming could be c=FR, o=Some Organization, ou=Some Organizational Unit L=Locality, or in the US: c=US, st=CA, o=Some Organization ou=Organizational Unit, L=Locality, and CN=Common Name.
documents:
The following RFCs detail LDAP-specific Best Current Practices:
The following is a partial list of RFCs specifying LDAPv3 extensions:
LDAPv2 was specified in the following RFCs:
LDAPv2 was moved to historic status by the following RFC:
Internet Protocol
The Internet Protocol is the principal communications protocol used for relaying datagrams across an internetwork using the Internet Protocol Suite...
(IP) network. LDAP is defined in terms of ASN.1
Abstract Syntax Notation One
Data generated at various sources of observation need to be transmitted to one or more locations that process it to generate useful results. For example, voluminous signal data collected by a radio telescope from outer space. The system recording the data and the system processing it later may be...
and transmitted using BER
Basic Encoding Rules
The Basic Encoding Rules is one of the encoding formats defined as part of the ASN.1 standard specified by the ITU in X.690.-Description:...
.
Directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate electronic mail directory. Similarly, a telephone directory
Telephone directory
A telephone directory is a listing of telephone subscribers in a geographical area or subscribers to services provided by the organization that publishes the directory...
is a list of subscribers with an address and a phone number.
LDAP is specified in a series of Internet Engineering Task Force
Internet Engineering Task Force
The Internet Engineering Task Force develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standards bodies and dealing in particular with standards of the TCP/IP and Internet protocol suite...
(IETF) Standard Track Requests for comments
Request for Comments
In computer network engineering, a Request for Comments is a memorandum published by the Internet Engineering Task Force describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.Through the Internet Society, engineers and...
(RFCs). The latest version is Version 3, published as RFC 4510.
Origin and influences
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 technologyInformation technology
Information technology is the acquisition, processing, storage and dissemination of vocal, pictorial, textual and numerical information by a microelectronics-based combination of computing and telecommunications...
and computer networking, their input culminating in the comprehensive X.500
X.500
X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by ITU-T, formerly known as CCITT, and first approved in 1988. The directory services were developed in order to support the requirements of X.400 electronic mail exchange and...
specification, a suite of protocols produced by the International Telecommunication Union
Itu
Itu is an old and historic municipality in the state of São Paulo in Brazil. The population in 2009 was 157,384 and the area is 641.68 km². The elevation is 583 m. This place name comes from the Tupi language, meaning big waterfall. Itu is linked with the highway numbered the SP-75 and are flowed...
(ITU) in the 1980s.
X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol
Directory Access Protocol
Directory Access Protocol is a computer networking standard promulgated by ITU-T and ISO in 1988 for accessing an X.500 directory service. DAP was intended to be used by client computer systems, but was not popular as there were few implementations of the full OSI protocol stack for desktop...
(DAP), which required the Open Systems Interconnection
Open Systems Interconnection
Open Systems Interconnection is an effort to standardize networking that was started in 1977 by the International Organization for Standardization , along with the ITU-T.-History:...
(OSI) protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500
X.500
X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by ITU-T, formerly known as CCITT, and first approved in 1988. The directory services were developed in order to support the requirements of X.400 electronic mail exchange and...
directory services through the simpler (and now widespread) TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE
DIXIE
DIXIE is an obsolete protocol for accessing X.500 directory services. DIXIE was intended to provide a lightweightmeans for clients to access X.500 directory services. DIXIE allowed TCP/IP clients to connect a DIXIE-to-DAP gateway which would provide access to the X.500 Directory Service...
and Directory Assistance Service
Directory Assistance Service
The Directory Assistance Service is an obsolete protocol and service for accessing X.500 directory services. DAS was intended to provide a lightweightmeans for clients to access X.500 directory services via a split-Directory User Agent model...
protocols.
Standalone LDAP directory servers soon followed, as did directory servers supporting both DAP and LDAP. The latter has become popular in enterprises, as LDAP removed any need to deploy an OSI network. Today, X.500
X.500
X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by ITU-T, formerly known as CCITT, and first approved in 1988. The directory services were developed in order to support the requirements of X.400 electronic mail exchange and...
directory protocols including DAP can also be used directly over TCP/IP.
The protocol was originally created by Tim Howes
Tim Howes
Tim Howes is the co-inventor of the Lightweight Directory Access Protocol , the Internet standard for accessing directory servers. The main purpose was to handle situations that the X.500 protocol suite could not address....
of the University of Michigan
University of Michigan
The University of Michigan is a public research university located in Ann Arbor, Michigan in the United States. It is the state's oldest university and the flagship campus of the University of Michigan...
, Steve Kille
Steve Kille
Steve Kille is an English software engineer.He has worked on Internet technologies since 1980, and was one of the principal engineers behind the ISODE open-source implementation of the OSI protocol stack....
of Isode Limited
Isode Limited
Isode Limited is a software company based in the United Kingdom. Isode develops and markets messaging and directory server software based on the LDAP and X.500 protocols and SMTP, IMAP, POP3, XMPP and X.400 protocols .-History:...
, and Wengyik Yeong
Wengyik Yeong
Wengyik 'Weng' Yeong was an American computer scientist. He is principally known for his work on the X.500, LDAP, and SNMP Internet protocols....
of Performance Systems International
PSINet
PSINet was one of the first internet service providers , based in Northern Virginia, and a major player in the commercialization of the Internet until the company's bankruptcy in 2001 during the dot-com bubble and acquisition by Cogent Communications in 2002.-Growth:PSINet was founded in 1989 by...
, circa 1993. Mark Wahl of Critical Angle Inc., Tim Howes
Tim Howes
Tim Howes is the co-inventor of the Lightweight Directory Access Protocol , the Internet standard for accessing directory servers. The main purpose was to handle situations that the X.500 protocol suite could not address....
, and Steve Kille
Steve Kille
Steve Kille is an English software engineer.He has worked on Internet technologies since 1980, and was one of the principal engineers behind the ISODE open-source implementation of the OSI protocol stack....
started work in 1996 on a new version of LDAP, LDAPv3, under the aegis of the Internet Engineering Task Force
Internet Engineering Task Force
The Internet Engineering Task Force develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standards bodies and dealing in particular with standards of the TCP/IP and Internet protocol suite...
(IETF). LDAPv3, first published in 1997, superseded LDAPv2 and added support for extensibility, integrated the Simple Authentication and Security Layer
Simple Authentication and Security Layer
Simple Authentication and Security Layer is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses...
, 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
Internet Engineering Task Force
The Internet Engineering Task Force develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standards bodies and dealing in particular with standards of the TCP/IP and Internet protocol suite...
.
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
XML Enabled Directory
XML Enabled Directory is a framework for managing objects represented using the Extensible Markup Language . XED builds on X.500 and LDAP directory services technologies....
(XED), Directory Service Markup Language
Directory Service Markup Language
Directory Services Markup Language is a representation of directory service information in an XML syntax.The DSML version 1 effort was announced by creator Bowstreet on July 12, 1999. Initiative supporters include AOL-Netscape, Sun Microsystems, Oracle, Novell, Microsoft, and IBM...
(DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol
Service Location Protocol
The Service Location Protocol is a service discovery protocol that allows computers and other devices to find services in a local area network without prior configuration. SLP has been designed to scale from small, unmanaged networks to large enterprise networks...
(SLP).
Protocol overview
A client starts an LDAP session by connecting to an LDAP server, called a Directory System AgentDirectory System Agent
A Directory System Agent is the element of a X.500 directory service that provides User Agents with access to a portion of the directory . X.500 is an international standard developed by the International Organization for Standardization and the International Telecommunication Union...
(DSA), by default on TCP
Transmission Control Protocol
The Transmission Control Protocol is one of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite, complementing the Internet Protocol , and therefore the entire suite is commonly referred to as TCP/IP...
port
TCP and UDP port
In computer networking, a port is an application-specific or process-specific software construct serving as a communications endpoint in a computer's host operating system. A port is associated with an IP address of the host, as well as the type of protocol used for communication...
389. The client then sends an operation request to the server, and the 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.
The client may request the following operations:
- StartTLS — use the LDAPv3 Transport Layer SecurityTransport Layer SecurityTransport Layer Security and its predecessor, Secure Sockets Layer , are cryptographic protocols that provide communication security over the Internet...
(TLS) extension for a secure connection - Bind — authenticateAuthenticationAuthentication is the act of confirming the truth of an attribute of a datum or entity...
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 it times out a connection.
A common alternate method of securing LDAP communication is using an SSL tunnel
Tunneling protocol
Computer networks use a tunneling protocol when one network protocol encapsulates a different payload protocol...
. This is denoted in LDAP URLs by using the URL scheme "ldaps". 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.
Directory structure
The protocol accesses LDAP directories, which follow the 1993 edition of the X.500X.500
X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by ITU-T, formerly known as CCITT, and first approved in 1988. The directory services were developed in order to support the requirements of X.400 electronic mail exchange and...
model:
- A directory is a tree of directory entriesDirectory Information TreeA directory information tree is data represented in a hierarchical tree-like structure consisting of the Distinguished Names of directory service entries....
. - 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).
Be aware that 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
Universally Unique Identifier
A universally unique identifier is an identifier standard used in software construction, standardized by the Open Software Foundation as part of the Distributed Computing Environment ....
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)
LDAP Data Interchange Format
The LDAP Data Interchange Format is a standard plain text data interchange format for representing LDAP directory content and update requests. LDIF conveys directory content as a set of records, one record for each object...
(LDAP itself is a binary protocol
Binary protocol
A binary protocol is a protocol which is intended or expected to be read by a machine rather than a human being, as opposed to a plain text protocol such as IRC, SMTP, or HTTP...
):
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: john@example.com
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's 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
Domain name system
The Domain Name System is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities...
'. 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 e-mail 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 which 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
Set (computer science)
In computer science, a set is an abstract data structure that can store certain values, without any particular order, and no repeated values. It is a computer implementation of the mathematical concept of a finite set...
of attributes, and an attribute is a set of values, and sets need not be ordered.
Operations
- Expand discussion of referral responses to various operations, especially modify, for example where all modifies must be directed from replicas to a master directory.
Bind (authenticate)
The Bind operation establishes the authentication state for a connection. Simple Bind can send the user's DN and password in plaintextPlaintext
In cryptography, plaintext is information a sender wishes to transmit to a receiver. Cleartext is often used as a synonym. Before the computer era, plaintext most commonly meant message text in the language of the communicating parties....
, so the connection should be protected using Transport Layer Security
Transport Layer Security
Transport Layer Security and its predecessor, Secure Sockets Layer , are cryptographic protocols that provide communication security over the Internet...
(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. SASL
Simple Authentication and Security Layer
Simple Authentication and Security Layer is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses...
(Simple Authentication and Security Layer) Bind provides authentication services through a wide range of mechanisms, e.g. Kerberos or the client certificate sent with TLS.
Bind also sets the LDAP protocol version. The version is an integer and at present must be either 2 (two) or 3 (three), although the standard supports integers between 1 and 127 (inclusive) in the protocol. 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 in LDAPv3 (the current LDAP version).
Search and Compare
The Search operation is used to both search for and read entries. Its parameters are:baseObject : The DN (Distinguished Name) of the entry at which to start the search,
scope : What elements below the baseObject to search. This can be
BaseObject
(search just the named entry, typically used to read one entry), singleLevel
(entries immediately below the base DN), or wholeSubtree
(the entire subtree starting at the base DN).filter : Criteria to use in selecting elements within scope. For example, the filter
(&(objectClass=person)(|(givenName=John)(mail=john*)))
will select "persons" (elements of objectClass person
) who either have the given name "John" or an e-mail address that begins with the string "john".derefAliases : Whether and how to follow alias entries (entries which refer to other entries),
attributes : Which attributes to return in result entries.
sizeLimit, timeLimit : Maximum number of entries to return, and maximum time to allow search to run. These values, however, cannot override any restrictions the server places on size limit and time limit.
typesOnly : Return attribute types only, not attribute values.
The server returns the matching entries and potentially continuation references. These may be returned in any order. The final result will include the result code.
The Compare operation takes a DN, an attribute name and an attribute value, and checks if the named entry contains that attribute with that value.
Update Data
Add, Delete, and Modify DN - all require the DN of the entry that is to be changed.Modify takes a list of attributes to modify and the modifications to each: Delete the attribute or some values, add new values, or replace the current values with the new ones.
Add operations also can have additional attributes and values for those attributes.
Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), optionally the new parent's DN, and a flag which says whether to delete the value(s) in the entry which match the old RDN. The server may support renaming of entire directory subtrees.
An update operation is atomic: Other operations will see either the new entry or the old one. On the other hand, LDAP does not define transactions of multiple operations: If you read an entry and then modify it, another client may have updated the entry in the meantime. Servers may implement extensions which support this, though.
Extended operations
The Extended Operation is a generic LDAP operation which can be used to define new operations that were not part of the original protocol specification. StartTLS is one of the most significant extensions. Other examples include the Cancel and Password Modify.StartTLS
The StartTLS operation establishes Transport Layer SecurityTransport Layer Security
Transport Layer Security and its predecessor, Secure Sockets Layer , are cryptographic protocols that provide communication security over the Internet...
(the descendant of SSL
Transport Layer Security
Transport Layer Security and its predecessor, Secure Sockets Layer , are cryptographic protocols that provide communication security over the Internet...
) on the connection. It can provide data confidentiality (to protect data from being observed by third parties) and/or data integrity protection (which protects the data from tampering). During TLS negotiation the server sends its X.509
X.509
In cryptography, X.509 is an ITU-T standard for a public key infrastructure and Privilege Management Infrastructure . X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation...
certificate to prove its identity. The client may also send a certificate to prove its identity. After doing so, the client may then use SASL
Simple Authentication and Security Layer
Simple Authentication and Security Layer is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses...
/EXTERNAL. By using the SASL/EXTERNAL, the client requests the server derive its identity from credentials provided at a lower level (such as TLS). Though technically the server may use any identity information established at any lower level, typically the server will use the identity information established by TLS.
Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as "LDAP over SSL") protocol on a separate port, by default 636. LDAPS differs from LDAP in two ways:
1) upon connect, the client and server establish TLS before any LDAP messages are transferred (without a StartTLS operation) and
2) the LDAPS connection must be closed upon TLS closure.
LDAPS was used with LDAPv2, because the StartTLS operation had not yet been defined. The use of LDAPS is deprecated, and modern software should only use StartTLS.
Abandon
The Abandon operation requests that the server abort an operation named by a message ID. The server need not honor the request. Unfortunately, neither Abandon nor a successfully abandoned operation send a response. A similar Cancel extended operation has therefore been defined which does send responses, but not all implementations support this.Unbind
The Unbind operation abandons any outstanding operations and closes the connection. It has no response. The name is of historical origin, and is not the opposite of the Bind operation.Clients can abort a session by simply closing the connection, but they should use Unbind. Unbind allows the server to gracefully close the connection and free resources that it would otherwise keep for some time until discovering the client had abandoned the connection. It also instructs the server to cancel operations that can be canceled, and to not send responses for operations that cannot be canceled.
LDAP URLs
An LDAP URLUniform Resource Locator
In computing, a uniform resource locator or universal resource locator is a specific character string that constitutes a reference to an Internet resource....
format exists which clients support in varying degree, and which servers return in referrals and continuation references (see RFC 4516):
ldap://host:port/DN?attributes?scope?filter?extensions
Most of the components, which are described below, are optional.
- host is the FQDN or IP address of the LDAP server to search.
- port is the network port (default port 389) of the LDAP server.
- DN is the distinguished name to use as the search base.
- attributes is a comma-separated list of attributes to retrieve.
- scope specifies the search scope and can be "base" (the default), "one" or "sub".
- filter is a search filter. For example
(objectClass=*)
as defined in RFC 4515. - extensions are extensions to the LDAP URL format.
For example, "
ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com
" refers to all user attributes in John Doe's entry in ldap.example.com
, while "ldap:///dc=example,dc=com??sub?(givenName=John)
" searches for the entry in the default server (note the triple slash, omitting the host, and the double question mark, omitting the attributes). As in other URLs, special characters must be percent-encodedPercent-encoding
Percent-encoding, also known as URL encoding, is a mechanism for encoding information in a Uniform Resource Identifier under certain circumstances. Although it is known as URL encoding it is, in fact, used more generally within the main Uniform Resource Identifier set, which includes both Uniform...
.
There is a similar non-standard
ldaps:
URL scheme for LDAP over SSL. This should not be confused with LDAP with TLS, which is achieved using the StartTLS operation using the standard ldap:
scheme.Schema
The contents of the entries in a subtree are governed by a schemaLogical schema
A Logical Schema is a data model of a specific problem domain expressed in terms of a particular data management technology. Without being specific to a particular database management product, it is in terms of either relational tables and columns, object-oriented classes, or XML tags...
known as a directory information tree
Directory Information Tree
A directory information tree is data represented in a hierarchical tree-like structure consisting of the Distinguished Names of directory service entries....
(DIT).
The schema of a Directory Server defines a set of rules that govern the kinds of information that the server can hold. It has a number of elements, including:
- Attribute Syntaxes—Provide information about the kind of information that can be stored in an attribute.
- Matching Rules—Provide information about how to make comparisons against attribute values.
- Matching Rule Uses—Indicate which attribute types may be used in conjunction with a particular matching rule.
- Attribute Types—Define an object identifierObject identifierIn computing, an object identifier or OID is an identifier used to name an object . Structurally, an OID consists of a node in a hierarchically-assigned namespace, formally defined using the ITU-T's ASN.1 standard. Successive numbers of the nodes, starting at the root of the tree, identify each...
(OID) and a set of names that may be used to refer to a given attribute, and associates that attribute with a syntax and set of matching rules. - Object Classes—Define named collections of attributes and classify them into sets of required and optional attributes.
- Name Forms—Define rules for the set of attributes that should be included in the RDN for an entry.
- Content Rules—Define additional constraints about the object classes and attributes that may be used in conjunction with an entry.
- Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry may have.
Attributes are the elements responsible for storing information in a directory, and the schema defines the rules for which attributes may be used in an entry, the kinds of values that those attributes may have, and how clients may interact with those values.
Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema subentry.
The schema defines object classes. Each entry must have an objectClass attribute, containing named classes defined in the schema. The schema definition of the classes of an entry defines what kind of object the entry may represent - e.g. a person, organization or domain. The object class definitions also define the list of attributes that must contain values and the list of attributes which may contain values.
For example, an entry representing a person might belong to the classes "top" and "person". Membership in the "person" class would require the entry to contain the "sn" and "cn" attributes, and allow the entry also to contain "userPassword", "telephoneNumber", and other attributes. Since entries may have multiple ObjectClasses values, each entry has a complex of optional and mandatory attribute sets formed from the union of the object classes it represents. ObjectClasses can be inherited, and a single entry can have multiple ObjectClasses values which define the available and required attributes of the entry itself. A parallel to the schema of an objectClass is a class
Class (computer science)
In object-oriented programming, a class is a construct that is used as a blueprint to create instances of itself – referred to as class instances, class objects, instance objects or simply objects. A class defines constituent members which enable these class instances to have state and behavior...
definition and an instance in Object-oriented programming
Object-oriented programming
Object-oriented programming is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction,...
, representing LDAP objectClass and LDAP entry, respectively.
Directory servers may publish the directory schema controlling an entry at a base DN given by the entry's subschemaSubentry operational attribute. (An operational attribute describes operation of the directory rather than user information and is only returned from a search when it is explicitly requested.)
Server administrators can add additional schema entries in addition to the provided schema elements. A schema for representing individual people within organizations is termed a white pages schema
White pages schema
A white pages schema is a data model, specifically a logical schema, for organizing the data contained in entries in a directory service, database, or application, such as an address book...
.
Variations
A lot of the server operation is left to the implementor or administrator to decide. Accordingly, servers may be set up to support a wide variety of scenarios.For example, data storage in the server is not specified - the server may use flat files, databases, or just be a gateway to some other server. Access control is not standardized, though there has been work on it and there are commonly used models. Users' passwords may be stored in their entries or elsewhere. The server may refuse to perform operations when it wishes, and impose various limits.
Most parts of LDAP are extensible. Examples: One can define new operations. Controls may modify requests and responses, e.g. to request sorted search results. New search scopes and Bind methods can be defined. Attributes can have options that may modify their semantics.
Other data models
As LDAP has gained momentum, vendors have provided it as an access protocol to other services. The implementation then recasts the data to mimic the LDAP/X.500 model, but how closely this model is followed varies. For example, there is software to access SQLSQL
SQL is a programming language designed for managing data in relational database management systems ....
databases through LDAP, even though LDAP does not readily lend itself to this. X.500
X.500
X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by ITU-T, formerly known as CCITT, and first approved in 1988. The directory services were developed in order to support the requirements of X.400 electronic mail exchange and...
servers may support LDAP as well.
Similarly, data which were previously held in other types of data stores are sometimes moved to LDAP directories. For example, Unix user and group information can be stored in LDAP and accessed via PAM
Pluggable Authentication Modules
Pluggable authentication modules are a mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface . It allows programs that rely on authentication to be written independent of the underlying authentication scheme...
and NSS
Name Service Switch
The Name Service Switch is a facility in Unix-like operating systems that provides a variety of sources for common configuration databases and name resolution mechanisms...
modules. LDAP is often used by other services for authentication.
An example of such data model is the GLUE Schema , 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.
Usage
An LDAP server may return referrals to other servers for requests that it cannot fulfill itself. This requires a naming structure for LDAP entries so one can find a server holding a given DN or distinguished name, a concept defined in the X.500 Directory and also used in LDAP. Another way of locating LDAP servers for an organization is a DNS server resource record (SRV).An organization with the domain example.org may use the top level LDAP DN
dc=example,dc=org
(where dc means domain component). If the LDAP server is also named ldap.example.org, the organization's top level LDAP URL becomes ldap://ldap.example.org/dc=example,dc=org
.Primarily two common styles of naming are used in both X.500 [2008] and LDAPv3 which are documented in the ITU specifications and IETF RFCs. The original form takes the top level object as the country object, such as c=US, c=FR. The domain component model uses the model described above. An example of country based naming could be c=FR, o=Some Organization, ou=Some Organizational Unit L=Locality, or in the US: c=US, st=CA, o=Some Organization ou=Organizational Unit, L=Locality, and CN=Common Name.
See also
- Federated Naming ServiceFederated Naming ServiceIn computing, the Federated Naming Service or XFN is a system for uniting various name services under a single interface for the basic naming operations...
- Global Directory ServerGlobal Directory ServerA Global Directory Server is a central repository for user information and application data that spans the Internet, intranets and organization-specific extranets...
- Hesiod (name service)Hesiod (name service)In computing, the Hesiod name service originated in Project Athena . It uses DNS functionality to provide access to databases of information that change infrequently...
- Hierarchical database model
- Key server (cryptographic)Key server (cryptographic)In computer security, a key server is a computer that receives and then serves existing cryptographic keys to users or other programs. The users' programs can be working on the same network as the key server or on another networked computer....
- LDAP Application Program InterfaceLDAP Application Program InterfaceThe LDAP Application Program Interface, described by RFC 1823, is an Informational RFC that specifies an application programming interface in the C programming language for version 2 of the Lightweight Directory Access Protocol. Version 2 of LDAP is historic. Commonly available LDAP C APIs do not...
- List of LDAP software
- Simple Authentication and Security LayerSimple Authentication and Security LayerSimple Authentication and Security Layer is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses...
(SASL)
External links
- Devshed.com, Understanding LDAP, A simple, light introductory tutorial for LDAP.
- Skills-1st.co.uk, LDAP schema design
- Capitalhead.com, Troubleshooting LDAP SSL connection issues between Microsoft ILM/MIIS & Novell eDirectory 8.7.3
- Prasannatech.com, LDAP schema design - A Case Study
RFCs
LDAP is specified in a series of Request for CommentsRequest for Comments
In computer network engineering, a Request for Comments is a memorandum published by the Internet Engineering Task Force describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.Through the Internet Society, engineers and...
documents:
- RFC 4510 - LDAP: Technical Specification Road Map (Obsoletes: RFC 2251, RFC 2252, RFC 2253, RFC 2254, RFC 2255, RFC 2256, RFC 2829, RFC 2830, RFC 3377, RFC 3771)
- RFC 4511 - LDAP: The Protocol (Obsoletes RFC 2251, RFC 2830 & RFC 3771)
- RFC 4512 - LDAP: Directory Information Models (Obsoletes RFC 2251, RFC 2252, RFC 2256 & RFC 3674)
- RFC 4513 - LDAP: Authentication Methods and Security Mechanisms (Obsoletes RFC 2251, RFC 2829 & RFC 2830)
- RFC 4514 - LDAP: String Representation of Distinguished Names (Obsoletes RFC 2253)
- RFC 4515 - LDAP: String Representation of Search Filters (Obsoletes RFC 2254)
- RFC 4516 - LDAP: Uniform Resource Locator (Obsoletes RFC 2255)
- RFC 4517 - LDAP: Syntaxes and Matching Rules (Obsoletes RFC 2252 & RFC 2256, Updates RFC 3698)
- RFC 4518 - LDAP: Internationalized String Preparation
- RFC 4519 - LDAP: Schema for User Applications (Obsoletes RFC 2256, Updates RFC 2247, RFC 2798 & RFC 2377)
The following RFCs detail LDAP-specific Best Current Practices:
- RFC 4520 (also BCP 64) - Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) (replaced RFC 3383)
- RFC 4521 (also BCP 118) - Considerations for Lightweight Directory Access Protocol (LDAP) Extensions
The following is a partial list of RFCs specifying LDAPv3 extensions:
- RFC 2247 - Use of DNSDomain name systemThe Domain Name System is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities...
domains in distinguished names (Updated by RFC 4519 & RFC 4524) - RFC 2307 - Using LDAP as a Network Information ServiceNetwork Information ServiceThe Network Information Service, or NIS is a client–server directory service protocol for distributing system configuration data such as user and host names between computers on a computer network...
- RFC 2589 - LDAPv3: Dynamic Directory Services Extensions
- RFC 2649 - LDAPv3 Operational Signatures
- RFC 2696 - LDAP Simple Paged Result Control
- RFC 2798 - inetOrgPerson LDAP Object Class (Updated by RFC 3698, RFC 4519 & RFC 4524)
- RFC 2830 - LDAPv3: Extension for Transport Layer Security
- RFC 2849 - The LDAP Data Interchange Format (LDIF)
- RFC 2891 - Server Side Sorting of Search Results
- RFC 3045 - Storing Vendor Information in the LDAP root DSE
- RFC 3062 - LDAP Password Modify Extended Operation
- RFC 3296 - Named Subordinate References in LDAP Directories
- RFC 3671 - Collective Attributes in LDAP
- RFC 3672 - Subentries in LDAP
- RFC 3673 - LDAPv3: All Operational Attributes
- RFC 3687 - LDAP Component Matching Rules
- RFC 3698 - LDAP: Additional Matching Rules
- RFC 3829 - LDAP Authorization Identity Controls
- RFC 3866 - Language Tags and Ranges in LDAP
- RFC 3909 - LDAP Cancel Operation
- RFC 3928 - LDAP Client Update Protocol
- RFC 4370 - LDAP Proxied Authorization Control
- RFC 4373 - LBURP
- RFC 4403 - LDAP Schema for UDDI
- RFC 4522 - LDAP: Binary Encoding Option
- RFC 4523 - LDAP: X.509 Certificate Schema
- RFC 4524 - LDAP: COSINE Schema (replaces RFC 1274)
- RFC 4525 - LDAP: Modify-Increment Extension
- RFC 4526 - LDAP: Absolute True and False Filters
- RFC 4527 - LDAP: Read Entry Controls
- RFC 4528 - LDAP: Assertion Control
- RFC 4529 - LDAP: Requesting Attributes by Object Class
- RFC 4530 - LDAP: entryUUID
- RFC 4531 - LDAP Turn Operation
- RFC 4532 - LDAP Who am I? Operation
- RFC 4533 - LDAP Content Sync Operation
- RFC 4876 - Configuration Profile Schema for LDAP-Based Agents
- RFC 5020 - LDAP entryDN Operational Attribute
LDAPv2 was specified in the following RFCs:
- RFC 1777 - Lightweight Directory Access Protocol (replaced RFC 1487)
- RFC 1778 - The String Representation of Standard Attribute Syntaxes (replaced RFC 1488)
- RFC 1779 - A String Representation of Distinguished Names (replaced RFC 1485)
LDAPv2 was moved to historic status by the following RFC:
- RFC 3494 - Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status