The Lightweight Directory Access Protocol, or LDAP (IPA: [ˈɛl dæp]), is an application protocol for querying and modifying directory services running over TCP/IP. The Application Layer is the seventh level of the seven-layer OSI model, and the top layer of the TCP/IP model In software engineering a directory is similar to a dictionary it enables the look up of a name and information associated with that name The Internet Protocol Suite (commonly TCP/IP) is the set of Communications protocols used for the Internet and other similar networks [1]
A directory is a set of objects with similar attributes organized in a logical and hierarchical manner. The most common example is the telephone directory, which consists of a series of names (either of persons or organizations) organized alphabetically, with each name having an address and phone number attached. Due to this basic design (among other factors) LDAP is often used by other services for authentication, despite the security problems this causes.
An LDAP directory tree often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. A Directory Information Tree (DIT is data represented in a hierarchical tree-like structure consisting of the Distinguished names (DNs of the directory entries LDAP deployments today tend to use Domain name system (DNS) names for structuring the topmost levels of the hierarchy. The Domain Name System (DNS is a hierarchical naming system for computers services or any resource participating in the Internet. Deeper inside the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else that represents a given tree entry (or multiple entries).
Its current version is LDAPv3, which is specified in a series of Internet Engineering Task Force (IETF) Standard Track Requests for comments (RFCs) as detailed in RFC 4510. In Computer network Engineering, a Request for Comments (RFC is a Memorandum published by the Internet Engineering Task Force (IETF describing
Contents |
Telecommunication companies introduced the concept of directory services to information technology and computer networking, as their understanding of directory requirements was well-developed after some 70 years of producing and managing telephone directories. Information technology ( IT) as defined by the Information Technology Association of America (ITAA is "the study design development implementation support Computer networking is the Engineering Discipline concerned with communication between Computer systems or devices Networking routers The culmination of this input was the comprehensive X.500 specification[2], a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s. X500 is a series of computer networking standards covering electronic Directory services The X The 1980s was the decade spanning from January 1 1980 to December 31 1989.
X. 500 directory services were traditionally accessed via the X. 500 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol stack. Directory Access Protocol (DAP is a Computer networking standard promulgated by ITU-T and ISO in 1988 for accessing an X The Open Systems Interconnection (usually abbreviated to OSI) was an effort to standardize networking that was started in 1982 by the International 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. The Internet Protocol Suite (commonly TCP/IP) is the set of Communications protocols used for the Internet and other similar networks This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols. Dixie is a nickname for the Southern United States. Origin of Dixie According to the Oxford English Dictionary, the origins The Directory Assistance Service ( DAS) is an obsolete protocol and service for accessing X
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. Tim Howes (b September 21, 1963) is the co-inventor of the Lightweight Directory Access Protocol (LDAP the Internet standard for accessing directory The University of Michigan Ann Arbor ( U of M, U-M, UM or simply Michigan) is a top-ranked Coeducational public research Isode Limited is a software company based in the United Kingdom. Wengyik 'Weng' Yeong (1966 – October 2007 was an American Computer scientist. PSINet was one of the first Internet service providers (ISPs based in Northern Virginia, and a major player in the commercialization of the Internet until Year 1993 ( MCMXCIII) was a Common year starting on Friday (link will display full 1993 Gregorian calendar) Further development has been done via the Internet Engineering Task Force.
In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP. It was renamed as the scope of the protocol was expanded to include not only directory browsing and searching functions, but also directory update functions.
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). XML Enabled Directory ( XED) is a framework for managing objects represented using the Extensible Markup Language (XML Directory Service Markup Language (DSML is a representation of Directory service information in an XML syntax SPML (Service Provisioning Markup Language is an XML -based framework being developed by OASIS, for exchanging user resource and service provisioning information The Service Location Protocol (SLP srvloc is a Service discovery protocol that allows computers and other devices to find services in a Local area network
A client starts an LDAP session by connecting to an LDAP server, by default on TCP port 389. The Transmission Control Protocol (TCP is one of the core protocols of the Internet Protocol Suite. In Computer networking, a port is an application-specific or process-specific software construct serving as a communications endpoint used by Transport Layer protocols The client then sends an operation request to the server, and the server sends responses in turn. With some exceptions, the client need not 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. Authentication (from Greek αυθεντικός real or genuine from authentes author is the act of establishing or confirming something (or someone as Transport Layer Security ( TLS) and its predecessor Secure Sockets Layer ( SSL) are Cryptographic protocols that provide secure 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. Transport Layer Security ( TLS) and its predecessor Secure Sockets Layer ( SSL) are Cryptographic protocols that provide secure 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.
LDAP is defined in terms of ASN.1, and protocol messages are encoded in the binary format BER. In Telecommunications and Computer networking, Abstract Syntax Notation One ( ASN The Basic Encoding Rules (BER is one of the encoding formats defined as part of the ASN It uses textual representations for a number of ASN. 1 fields/types, however.
The protocol accesses LDAP directories, which follow the 1993 edition of the X.500 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. A Universally Unique Identifier (UUID is an identifier standard used in Software construction standardized by the Open Software Foundation (OSF as part of the
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. The LDAP Data Interchange Format ( LDIF) is a standard Plain text data interchange format for representing LDAP (Lightweight Directory Access Protocol directory 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 com manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top
dn is the name of the entry; it's not an attribute nor part of the entry. "cn=John Doe" is the entry's RDN, 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 in 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.
The client gives each request a positive Message ID, and the server response has the same Message ID. The response includes a numeric result code which indicates success, some error condition or some other special cases. Before the response, the server may send other messages with other result data - for example each entry found by the Search operation is returned in such a message.
The StartTLS operation establishes Transport Layer Security (the descendant of SSL) on the connection. Transport Layer Security ( TLS) and its predecessor Secure Sockets Layer ( SSL) are Cryptographic protocols that provide secure Transport Layer Security ( TLS) and its predecessor Secure Sockets Layer ( SSL) are Cryptographic protocols that provide secure That can provide data confidentiality (cannot be read by third parties) and/or data integrity protection (protect from tampering). During TLS negotiation the server sends its X.509 certificate to prove its identity. In Cryptography, X509 is an ITU-T standard for a Public key infrastructure (PKI for Single sign-on and Privilege Management Infrastructure The client may also send a certificate to prove its identity. After doing so, the client may then use SASL/EXTERNAL to have this identity used in determining the identity used in making LDAP authorization decisions. Simple Authentication and Security Layer ( SASL) is a Framework for Authentication and Data security in Internet protocols It decouples
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 Start TLS operation) and 2) the LDAPS connection must be closed upon TLS closure.
LDAPS was primarily 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.
The Bind operation authenticates the client to the server. Simple Bind can send the user's DN and password in plaintext, so the connection should be protected using Transport Layer Security (TLS). In Cryptography, plaintext is the information which the sender wishes to transmit to the receiver(s Transport Layer Security ( TLS) and its predecessor Secure Sockets Layer ( SSL) are Cryptographic protocols that provide secure 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. Simple Authentication and Security Layer ( SASL) is a Framework for Authentication and Data security in Internet protocols It decouples g. Kerberos or the client certificate sent with TLS. Kerberos is a Computer network Authentication protocol, which allows individuals communicating over a non-secure network to prove their identity to one
Bind also sets the LDAP protocol version. 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).
The Search operation is used to both search for and read entries. Its parameters are:
The server returns the matching entries and maybe continuation references (in any order), followed by the final result with 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.
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 mean time. Servers may implement extensions which support this, however.
The Extended Operation is a generic LDAP operation which can be used to define new operations. Examples include the Cancel, Password Modify and Start TLS operations.
The Abandon operation requests that the server aborts 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.
The Unbind operation abandons any outstanding operations and closes the connection. It has no response. The name is of historical origin: It is not the opposite of the Bind operation.
Clients can abort a session by simply closing the connection, but they should use Unbind. Otherwise the server cannot tell the difference between a failed network connection (or a truncation attack) and a discourteous client.
An LDAP URL 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. Uniform Resource Locator is an URI which also specifies where the identified resource is available and the protocol for retrieving it
(objectClass=*) (see RFC 4515). 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. As in other URLs, special characters must be percent-encoded. Percent-encoding, also known as URL encoding, is a mechanism for encoding information in a Uniform Resource Identifier (URI under certain circumstances
There is a similar non-standard "ldaps:" URL scheme for LDAP over SSL.
The contents of the entries in a subtree are governed by a schema. A Logical Schema is a Data model of a specific problem domain expressed in terms of a particular data management technology
The schema defines the attribute types that directory entries can contain. An attribute definition includes a syntax, and most non-binary values in LDAPv3 use UTF-8 string syntax. UTF-8 (8- Bit UCS / Unicode Transformation Format) is a variable-length Character encoding for Unicode. For example, a "mail" attribute might contain the value "user@example. com". A "jpegPhoto" attribute would contain photograph(s) in binary JPEG/JFIF format. A "member" attribute contains DNs of other directory entries. Attribute definitions also specify whether the attribute is single-valued or multi-valued, how to search/compare the attribute (e. g. case-sensitive vs. case-insensitive and whether substring matching is supported), etc.
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 list which attributes are obligatory and which are optional. 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 belong to multiple classes, 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 to 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. In Object-oriented programming, a class is a Programming language construct that is used as a blueprint to create objects This blueprint includes attributes In its simplest embodiment an object is an allocated region of storage Object-oriented programming (OOP is a Programming paradigm that uses " objects " and their interactions to design applications and computer programs
The schema also includes various other information controlling directory entries.
Most schema elements have a name and a globally unique Object identifier (OID). In Computing, an object identifier or OID is an Identifier used to name an object (compare URN)
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 define their own schemas in addition to the standard ones. A schema for representing individual people within organizations is termed a 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
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.
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 SQL databases through LDAP, even though LDAP does not readily lend itself to this. X.500 servers may support LDAP as well. X500 is a series of computer networking standards covering electronic Directory services The X
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. Pluggable authentication modules or PAM are a mechanism to integrate multiple low-level Authentication schemes into a high-level Application programming interface In Unix-like Operating systems the Name Service Switch ( NSS) allows Unix configuration databases to be provided by different sources including local files LDAP is often used by other services for authentication.
One reason to choose LDAP for a service is that it is quite widely supported, and data presented in LDAP is thus immediately available to many clients and libraries. Another is that LDAP is very general and includes basic security, and can support many types of applications.
Thus, if one chooses a few general protocols like LDAP and HTTP for various services, one can focus on these few protocols instead of having to maintain and upgrade many specialized protocols. Hypertext Transfer Protocol ( HTTP) is a Communications protocol for the transfer of information on the Internet.
Two common applications of LDAP are for computer user/group data, and for address book information (persons, departments etc). Many e-mail clients support LDAP lookups.
Some tasks LDAP does not handle well are to model a relational database, and data whose ordering must be preserved. (However, an extension does exist for the latter. )
Since an LDAP server can return referrals to other servers for requests the server itself will not/can not serve, a naming structure for LDAP entries is needed so one can find a server holding a given DN. Since such a structure already exists in the Domain name system (DNS), servers' top level names often mimic DNS names. The Domain Name System (DNS is a hierarchical naming system for computers services or any resource participating in the Internet.
If an organization has domain name foo. example, its top level LDAP entry will therefore typically have the DN dc=foo,dc=example (where dc means domain component). If the LDAP server is also named ldap. foo. example, the organization's top level LDAP URL becomes ldap://ldap. foo. example/dc=foo,dc=example.
Below the top level, the entry names will typically reflect the organization's internal structure or needs rather than DNS names.
This is also a descendent of the X. 500 series.
The LDAP terminology one can encounter is rather cumbersome. Some of this is due to misunderstandings, other examples are due to its historical origins, others arise when used with non-X. 500 services that use different terminology. For example, "LDAP" is sometimes used to refer to the protocol, other times to the protocol and the data. An "LDAP directory" may be the data or also the access point. An "attribute" may be the attribute type, or the contents of an attribute in a directory, or an attribute description (an attribute type with options). An "anonymous" and an "unauthenticated" Bind are different Bind methods that both produce anonymous authentication state, so both terms are being used for both variants. The "uid" attribute should hold user names rather than numeric user IDs.
LDAP is currently specified in a series of Request for Comments 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: