LDAP: How It Works

---

This section is intended to provide a "physical understanding" of what the LDAP protocol actually does as information travels over your network. Some of these concepts appear later in the book, so impatient readers can skip this section without losing the continuity of the discussion of LDAP.

The Lightweight Directory Access Protocol is nothing more than a communication protocol. As we have seen, the LDAP standard mediates communication between client and server and does nothing else. Note that LDAP is a standard and is not a program or software you can buy. What you will install on your computer is the implementation of this protocol. This is an important detail. The question of how to store the data is left to the vendor implementing the final standard. The LDAP protocol specification does not even contain the LDAP C API used to access the LDAP server from an application. This API is defined in RFC 1823 instead. Chapter 5 presents more information about APIs for the most important programming languages.

In contrast to TCP, LDAP is a message-oriented protocol. What does this mean? In a conversation on your network, you always have one sending computer and one receiving computer. For a message-oriented protocol, such as LDAP, the logical unit transferred is a message, i.e., as soon as a complete message arrives, the "receive" operation is finished. TCP instead is a stream-oriented protocol, which means that the "receive" operation stops only when a specified number of bytes have arrived. One consequence of this behavior is that LDAP does not need a type of "\r\n" delimiter to specify the end of a request.

As mentioned previously, the basic unit of information transmitted is a message contained in the message envelope. The message envelope has a well-defined format. All messages sent back and forth between server and client are sent in this format, including requests the client sends to the server, results the server sends back to the client, and the result codes. The LDAP message envelope is also called a "protocol data unit" (PDU). The PDU message envelope must contain two pieces of information:

• The message identifier identifying the message

• The operation

The message identifier is very important because the LDAP model does not require the requests and responses to be made synchronously. The message identifier allows the client and the server to assign a corresponding response to every request. The operation can be the request the client made to the server or the response sent back from the server to the client. Exhibit 7 shows the possible protocol operations.

Operation	Description
bindRequest	bind request
bindResponse	bind response
unbindRequest	unbind request
searchRequest	search request
searchResEntry	search result entry
searchResDone	search result done
searchResRef	search result reference
modifyRequest	modify request
modifyResponse	modify response
addRequest	add request
addResponse	add response
delRequest	delete request
delResponse	delete response
modDNRequest	modify DN request
modDNResponse	modify DN response
abandonRequest	abandon request
extendedReq	extended request
extendedResponse	extended response

Exhibit 7: Protocol Operations

Let us now have a closer look at the LDAP message model. The LDAP client sends a request to the LDAP server. The server executes one or more operations as specified in the request. In the case of a successful transmission, the server sends the results; in the case of an error, the corresponding error code is sent back to the client. Every LDAP message — both requests and responses — contains the message ID, an operation code, and data. The message ID is needed to identify the response on behalf of a request.

There is no need to explain these protocol operations in detail here, as they will become clear later on when we speak about the single models laying behind LDAP in Chapter 3. Additional information on this topic is also presented in Chapter 4. For now, it is enough to know that, for nearly all operations, there is a request operation and a response operation. The exceptions include the unbind request and the abandon request, which do not require any response. The search request can have one of three results: the data the search has resulted in, a message indicating the execution of the query, or a reference indicating where the requested data could be found. Chapter 3 provides additional information.

To illustrate this process, consider the following example of searching for an entry in a directory. Exhibit 8 provides an overview of what happens. At the beginning, the client opens a connection to the computer where the directory server is installed. Then the client "binds" to the LDAP server. The process of binding qualifies the client using a valid user ID and password. If the user ID and password are omitted, the server assumes the client wishes a connection as an "anonymous user," a user with the lowest access rights (if any). The server answers with a result code to show if the bind has been successful. Then the client constructs the query and sends it to the server. Again, the server executes the request and sends back the result data, if any, and also sends the result code of the operation in a separate message. If the server finds more than one results set, it sends them back in a number of LDAP messages. At the end of the conversation, the client sends the "unbind" request, upon which the server closes the connection. In Exhibit 8, the ID should show you the message identifier sent with each message.

Exhibit 8: Conversation between LDAP Client and Server

One client can send multiple requests to an LDAP server, but there is no guarantee that the server will answer the requests in the order they are posted. As mentioned before, every message sent to the server by the client has a unique message identifier. The server sends this message identifier back with the answer to let the client know which request corresponds to the answer. Exhibit 9 shows this situation.

Exhibit 9: Multiple Responses to One Client Request

The data being sent back and forth between client and server is encoded. Data has to be encoded because the data stored in the directory contains every data type, ranging from names in ASCII (American Standard Code for Information Interchange) strings to binary data for images. LDAP uses a lightweight version of the ASN.1 (Abstract Syntax Notation One) basic encoding rules, also called "lightweight basic encoding rules" (LBER). This encoding is needed to transmit all of the data structures LDAP knows about, including binary data and encoded passwords, in an operating-system-independent way. This distinguishes LDAP from other application protocols, such as HTTP. Using HTTP, you can open a telnet session to the server using the port it is listening to and type commands (such as a GET of an HTML page). This is not possible using LDAP because the conversation does not consist of simple strings. What you could do instead is to use LDAP URLs in your browser (more about this in Chapter 2).

Here is a sample URL:

• ldap://my.ldap.server.com:389/e=ldap_abc.de?phone?(sn=Voglmaier)

and here is the URL with the syntax:

• ldap://<hostname:port>/<base DN>?<attributes>?<scope>?<search filter>

where

• Hostname is the name of the host where your LDAP server is installed.

• Port is the number of the port your LDAP server is listening on (the standard port is 389).

• Base_DN is the base distinguished name, i.e., the distinguished name where the query has to be started (more about this in Chapter 2).

• Attributes are the fields to be returned by the query.

• Scope specifies how deep the query should enter in the directory tree (again, see Chapter 2).

• Search filter indicates the conditions the entries should meet in order to be returned.

Note, however, that the LDAP URL syntax allows only the search command; other operations are not supported. For additional information about LDAP URLs, see Chapter 4, which provides more details about LDAP, or Chapter 7, which examines LDAP and the Web.

In this section, we learned about the different messages that LDAP understands:

• Bind, unbind, abandon: These messages are needed to connect and authenticate (bind), disconnect (unbind), or abort (abandon) a connection to the server.

• Search, compare: These messages are sent to query information from the directory.

• Add, delete, modify: These messages are needed to manipulate data contained in the directory.

These operations are discussed in greater detail in Chapter 3, which examines various LDAP models.

---