Lightweight Directory Access Protocol (LDAP)

As a general mechanism of the IP-based network for retrieval of the directory information, LDAP is uniformly supported by all products (IP PBXs, multiservice modules, and universal messaging platforms, to name just a few) that require directory access.

The Lightweight Directory Access Protocol (LDAP) was designed by the IETF for accessing directories based on the X.500 data model and directory service. It is a less complex alternative to the Directory Access Protocol defined by the ITU-T for the same purpose. At the time of this writing, the third version of the LDAP specification RFC 2251 has been approved by the IETF as a Proposed Standard.

Before describing LDAP, we should review its foundation: the X.500 data model and directory service. The X.500 data model is hierarchical; the information in the directory is arranged in the form of a tree, called the directory information tree (DIT), where the vertices denote entries representing objects in the real world. An entry is composed of attributes, each with a type and one or more values. Normally, one of the attributes is special in the way it has to assume a unique value for each of the sibling entries (that is, those descending from the same vertex) in the DIT. As a result, the attribute and value pair, called the relative distinguished name (RDN), unambiguously distinguishes an entry from its siblings. The concatenation of the RDN of an entry and the RDNs of all its superior nodes (in descending order) further forms the distinguished name, which uniquely identifies the entry in the entire DIT.

The X.500 directory is a logical concept and is normally distributed across many directories in practice. According to ITU-T Recommendation X.500, the directory provides the directory service upon the requests of users. The requests, subject to security measures such as authentication and access control, are typically to interrogate or modify the directory entries. The directory always reports the outcome of a request, whether the operation succeeds or not. In particular, X.500 permits the directory to return a referral, which suggests an alternative access point where the user can make the request.

In support of the X.500 data model and directory service, LDAP is designed as a client-server protocol, which assumes a reliable connection-oriented underlying transport, such as Transmission Control Protocol/Internet Protocol (TCP/IP). A client sends a server a request describing the operation desired on the X.500 directory. The server performs the operation and then returns one or more responses indicating the results of the operation. RFC 2251 specifies the following LDAP requests:

§  BindRequest. Starts an LDAP protocol session; allows authentication information to be exchanged between the client and server.

§  UnbindRequest. Terminates an LDAP protocol session.

§  SearchRequest. Requests a search based on specified criteria within the directory.

§  AddRequest. Adds an entry into the directory.

§  ModifyRequest. Modifies an entry in the directory.

§  DelRequest. Removes an entry from the directory.

§  ModifyDNRequest. Changes the leftmost component of the name of an entry or moves a subtree of entries to a new location in the directory.

§  CompareRequest. Compares an assertion against the attributes of an entry in the directory.

§  AbandonRequest. Abandons an outstanding operation.

For each of the preceding requests, a matching response is defined.

A notable aspect of LDAP Version 3 is its support of operations defined elsewhere using a special request, ExtendedRequest, which serves as the envelope for foreign operations. The results of the operations are returned in the response to ExtendedRequest. This special request feature enables development of dynamic directory services, which are particularly relevant to services such as IP telephony and Internet call waiting. Dynamic directory services are concerned with the directory entries that exist only for a certain period of time. Such an entry is associated with a time-to-live, which is set upon creation and can be reset as needed. After being set or reset, the time-to-live decreases with each clock tick. When it reaches zero, the entry is removed. An example of dynamic entries is the description of an online user; naturally it exists only for as long as the user stays online. RFC 2598 defines an operation to be used within ExtendedRequest to refresh the time-to-live of a dynamic entry by a client, typically the creator of the entry. In addition, it defines the schema extensions required for representing dynamic entries.

RFC 2251 defines the LDAP syntax in Abstract Syntax Notation One (ASN.1). In addition, it prescribes that ASN.1 Basic Encoding Rules (BER) be used to encode the protocol elements for transfer. Certain restrictions apply to avoid the high overhead associated with BER.