What Is LDAP?

Today, the term LDAP refers to the following things:

• The Lightweight Directory Access Protocol, a standard, extensible Internet protocol used to access directory services

• A set of four models that guide you in your use of the directory: an information model that describes what you can put in the directory, a naming model that describes how you arrange and refer to directory data, a functional model that describes what you can do with directory data, and a security model that describes how directory data can be protected from unauthorized access

• The LDAP Data Interchange Format (LDIF), a standard text format for exchanging directory data

• LDAP server software, including commercial and open -source implementations

• A set of command-line utilities commonly bundled with LDAP servers and LDAP-based applications

• The LDAP application programming interfaces (APIs), used to develop LDAP client applications

All of these are described in further detail in the next several sections.

The LDAP Protocol

In this section we'll discuss the individual LDAP protocol operations and show how clients use them to perform useful tasks . We'll also show how LDAP works "on the wire" by discussing the wire protocol.

It's important to understand that the LDAP protocol is a message-oriented protocol. The client constructs an LDAP message containing a request and sends it to the server. The server processes the request and sends the result(s) back to the client as a series of one or more LDAP messages.

For example, when an LDAP client searches the directory for a specific entry, it sends an LDAP search request message to the server. This message contains a unique message ID, generated by the client. The server retrieves the entry from its database and sends it to the client in an LDAP message. It also returns a result code to the client in a separate LDAP message. All the responses from the server to the client are identified with the message ID provided in the original client request. Figure 2.1 shows this interaction.

Figure 2.1. A Client Retrieves a Single Entry from the Directory

If the client searches the directory and finds multiple entries, those entries are sent to the client in a series of LDAP messages, one for each entry. Each entry has a unique name called a distinguished name ( DN ), which is carried in the LDAP messages as a text string. The entries that constitute the search results are terminated with a result message, which contains an overall result for the search operation, as shown in Figure 2.2.

Figure 2.2. A Client Retrieves Multiple Entries from the Directory

Because the LDAP protocol is message-based, it also allows the client to issue multiple requests at once. For example, a client might issue two search requests simultaneously . The client generates a unique message ID for each request; returned results for a specific request are tagged with the request's message ID, allowing the client to sort out multiple responses to different requests arriving out of order or at the same time.

In Figure 2.3, the client issued two search requests simultaneously. The server processes both operations and returns the results to the client. Notice that the server sends the final result code of message 2, identified in the figure as msgid=2 , to the client before it sends the final result code from message 1. This is perfectly acceptable. These details are hidden from the programmer by an LDAP SDK (software development kit). Programmers writing an LDAP application don't need to be concerned with sorting out these results; the SDKs take care of this automatically.

Figure 2.3. A Client Issues Multiple LDAP Search Requests Simultaneously

Allowing multiple concurrent requests "in flight" enables LDAP to be more flexible and efficient than protocols that operate in a "lockstep" fashion (for example, Hypertext Transfer Protocol, or HTTP). With a lockstep protocol, each client request must be answered by the server before another may be sent. For example, an HTTP client program ”such as a Web browser that wants to download multiple files concurrently ”must open one connection for each file. LDAP, on the other hand, can manage multiple operations on a single connection, reducing the maximum number of concurrent connections a server must be prepared to handle.

The LDAP Protocol Operations

LDAP has nine basic protocol operations, which can be divided into three categories:

1. Interrogation operations: search, compare . These two operations allow you to ask questions of the directory.

2. Update operations: add, delete, modify, modify DN (rename) . These operations allow you to update information in the directory.

3. Authentication and control operations: bind, unbind, abandon . The bind operation allows a client to identify itself to the directory by providing an identity and authentication credentials; the unbind operation allows the client to terminate a session; and the abandon operation allows a client to indicate that it is no longer interested in the results of an operation it had previously submitted.

We will discuss each protocol operation when we describe the LDAP functional model later in this chapter.

A typical complete LDAP client/server exchange might proceed as depicted in Figure 2.4, which shows an LDAP client and server performing the following steps:

Step 1. The client opens a TCP connection to an LDAP server and submits a bind operation. This bind operation includes the name of the directory entry the client wants to authenticate as, along with the credentials to be used for authenticating. Credentials are often simple passwords, but they might also be digital certificates used to authenticate the client.

Step 2. After the directory has verified the bind credentials by checking that the password or digital certificate is correct, it returns a success result to the client.

Step 3. The client issues a search request.

Step 4 and 5. The server processes this request, which results in two matching entries.

Step 6. The server sends a result message.

Step 7. The client then issues an unbind request, which indicates to the server that the client wants to disconnect.

Step 8. The server obliges by closing the connection.

Figure 2.4. A Typical LDAP Exchange

By combining several of these simple LDAP operations, directory-enabled clients can perform complex tasks that are useful to their users. For example, as shown in Figure 2.5, an electronic mail client such as Netscape Communicator can look up mail recipients in a directory, helping a user to address an e-mail message. It can also use a digital certificate stored in the directory to digitally sign and encrypt an outgoing message. Behind the scenes, the user 's e-mail program performs several directory operations that allow the mail to be addressed, signed, and encrypted. But from the user's point of view, it is all taken care of automatically.

Figure 2.5. A Directory-Enabled Application Performing a Complex Task

End-user applications are not the only kind of directory-enabled applications. Server-based applications often benefit from being directory-enabled too. For example, Sun ONE Messaging Server can use an LDAP directory when routing incoming electronic mail, as shown in Figure 2.6.

Figure 2.6. A Directory-Enabled Server Application

LDAP Extensibility

In addition to providing the nine basic protocol operations, LDAPv3 is designed to be extensible via three methods :

1. LDAP extended operations . Entirely new protocol operations, which can be defined by means of LDAPv3 extended operations. If the need arises for a new operation, it can be defined and made standard without changes having to be made to the core LDAP protocol. An example of an extended operation is StartTLS, which indicates to the server that the client wants to begin using Transport Layer Security (TLS) to encrypt and optionally authenticate the connection.

2. LDAP controls . Extra pieces of information that piggyback on existing LDAP operations, altering the behavior of the operation. For example, the ManageDSAIT control is sent along with a modify operation when the client wants to manipulate certain types of metainformation stored in the directory (this metainformation is normally hidden from users of the directory). In the future, additional controls may be defined that alter the behavior of existing LDAP operations in useful ways.

3. Simple Authentication and Security Layer ( SASL ) . A framework for supporting multiple authentication methods. If the SASL framework is used to implement authentication, LDAP can easily be adapted to support new, stronger authentication methods. SASL also supports a framework for clients and servers to negotiate lower-layer security mechanisms, such as encryption of all client/server traffic. SASL is not specific to LDAP, though; its general framework can be adapted to a wide range of Internet protocols.

We'll discuss LDAPv3 extensions in detail in Chapter 3, LDAPv3 Extensions.

The LDAP Protocol on the Wire

What information is transmitted back and forth between LDAP clients and servers? We won't go into a great deal of detail here because this book isn't about protocol design, but there are a few things you should know about the LDAP wire protocol.

LDAP uses a simplified version of the Basic Encoding Rules ( BER ), a set of rules for encoding various data types, such as integers and strings, in a system-independent and compact fashion. BER also defines ways of combining these primitive data types into useful structures such as sets and sequences. The simplified BER that LDAP uses is often referred to as Lightweight BER ( LBER ). LBER does away with many of the more esoteric data types that BER can represent, simplifying implementation.

Because LDAP uses LBER, it is not a simple text-based protocol like HTTP, and you can't simply telnet to the LDAP port on your server and start typing commands. Also, if you want to use a network sniffer program to observe LDAP traffic between a client and server, the sniffer program needs to understand the LDAP protocol to be useful (most state-of-the-art sniffer software does ”for example, there is an LDAP module for Ethereal, which is a well-known open-source sniffer). If you are familiar with text-based Internet protocols such as Post Office Protocol (POP), Internet Message Access Protocol (IMAP), and Simple Mail Transfer Protocol (SMTP), this may seem like an unfortunate limitation. On the other hand, the Domain Name System (DNS), a successful distributed system, uses a protocol that has nontextual protocol primitives. The presence of universal implementations of client libraries for both DNS and LDAP makes this limitation less problematic .