3. Overview of LDAP

LDAP assumes the same information model and namespace as X.500. It is also client-server based, with one important difference: there are no referrals returned in LDAP. An LDAP server must return only results or errors to a client. If referrals are involved, the LDAP server is responsible for chasing them down. This model is depicted in Figure 2, though the intermediate server shown is not required (i.e., an implementation could choose to have its DSA speak "native" LDAP).


Figure 2. Relationship between LDAP and X.500

The LDAP client-server model includes an LDAP server translating LDAP requests into X.500 requests, chasing X.500 referrals, and returning results to the client.

The LDAP functional model is a subset of the X.500 model. LDAP supports the following operations: search, add, delete, modify, modify RDN, bind, unbind, and abandon. The search operation is similar to its DAP counterpart. A base object and scope are specified, determining which portion of the tree to search. A filter specifies the entries within the scope to select. The LDAP search filter offers the same functionality as the one in DAP but is encoded in a simpler form.

The time and size limit service controls are included directly in the search request. (They are not included with the other operations.) The searchAliases search control and dereferenceAliases service control are combined in a single derefAliases parameter in the LDAP search. The ASN.1 [11] definition of the LDAP search request is shown in Figure 3.

SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2)
},
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
alwaysDerefAliases (3)
},
sizeLimit INTEGER (0 .. MaxInt),
timeLimit INTEGER (0 .. MaxInt),
attrsOnly BOOLEAN,
filter Filter,
attributes SEQUENCE OF AttributeType
}
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeType,
approxMatch [8] AttributeValueAssertion

Figure 3. ASN.1 for the LDAP search operation

The LDAP search operation offers similar functionality to DAP search. It combines search parameters and service controls and simplifies the filter encoding.

The LDAPDN and AttributeType components of the search are encoded as simple character strings using the formats defined in RFC 1779 [5] and RFC 1778 [2], respectively, rather than the highly structured encoding used by X.500. Similarly, the value in an AttributeValueAssertion is encoded as a primitive OCTETSTRING, not a more structured ASN.1 type. The structure is reflected in the syntax of the encoded string, not in the encoding itself.

The results of an LDAP search are sent back to the client one at a time, in separate searchEntry packets. This sequence of entries is terminated by a final searchResult packet that contains the result of the search (e.g., success, a size or time limit was exceeded, etc.). Having a final terminator packet allows clients and servers to stream results more easily, handling one entry at a time. This is especially useful in memory-constrained environments where holding the collection of all entries from a large search is not possible.

The X.500 list and read operations are not included in LDAP. Instead, they are emulated with the LDAP search operation. Read is emulated by a base object search of the entry to read, with a filter testing for the existence of the objectClass attribute. Every entry is required to have an object class and must match this filter. List is emulated by a one level search of the entry to list, also with a filter testing for the existence of the objectClass attribute. If the ability to distinguish alias children from other children (a feature provided by X.500 list) is desired, the objectClass attribute can be retrieved and examined for a value of alias.

The LDAP modify operation also differs slightly from its DAP counterpart. In DAP, four kinds of changes can be made: entire attributes can be added or deleted; individual values can be added or deleted. These capabilities require a client to read an entry before attempting a modify (e.g., when adding a value, to discover whether an add attribute or add value is required).

In LDAP, we simplified the semantics of modify by supporting three operations: add values; delete values; and replace values. If a request is made to add values to an attribute that does not exist in the entry, the attribute is created automatically. If a request is made to delete the last value of an attribute, the entire attribute is deleted. An attribute can also be deleted by specifying a delete values operation without specifying any values. Finally, the replace values construct is used to make an attribute contain the given values after the modify. The LDAP server takes care of translating the replace request into the necessary sequence of modify, add, and delete operations required by X.500.

The LDAP bind operation supports a subset of X.500 bind functionality. It allows only simple authentication, consisting of a clear-text password, and Kerberos version 4 authentication [6], which translates into an X.500 external authentication method. The LDAP bind operation includes a choice of credentials, allowing for future expansion of available authentication methods.

The DAP unbind, abandon, modify RDN, add and delete operations are virtually identical to their DAP counterparts.

[Contents] [Previous] [Next]