The Lightweight Directory Access Protocol

Now that all this is perfectly clear in your mind, let's talk about LDAP. Throw out most of the acronyms in the first part of this chapter and you're left with a clever method of naming and organizing data in a directory database. The only problem is that implementing DAP, DSP, DISP, DOP, and all those other protocols is just too complex, and a lot of the functionality can be performed by simpler protocols. That's why LDAP was developed. It's "lightweight" compared to the overhead involved in the original directory service protocols. If Microsoft had decided to implement the original X.500 directory service as envisioned by the original developers, Bill Gates would still be trying to get Windows 2000 out the door, much less Windows XP.

Because the Internet is standardized on TCP/IP, it was decided that a new set of protocols, also based on TCP/IP, could be developed that could query, add to, and modify a database that was based on the X.500 tree structure. Version 2 of LDAP (described in RFC 1777) was the first practical implementation of LDAP, whereas version 3 (described in RFC 2251) more fully delineates the client/server nature of the functions that are performed for accessing the directory database. Microsoft's Active Directory supports both LDAPv2 and LDAPv3. LDAPv3 provides for additional operations that were not supported in the earlier versions of LDAP and allows for paging and sorting of information. Additionally, LDAPv3 is extensible , that is, it defines a concept called extended operations , so that future developers can implement operations that are not provided for in the current protocol. This extended operations capability allows a vendor to customize his version of LDAP applications, yet still allows his product to interact with other LDAPv3-compliant products (more or less).

Tip

The next version of LDAP, version 4, is already being readied for use. This version uses XML technology and will go a long way toward making different directories interoperate more easily. You can learn about other features being considered for LDAPv4 by doing a quick search of the Internet.

Another interesting thing that LDAPv3 does is to allow the schema to be defined in the directory. Unlike the Domain Name System (DNS), which usually is implemented as a flat file that must be read into memory when the service is started, LDAPv3 allows for the very definitions of the object classes and related attributes to be defined in the directory. This might not seem important at first, but just think about it. Because the definition of all the classes and attributes is stored in the directory itself, applications can query the database to find out just what kinds of objects it contains.

Note

Ever have one of those nights when you had guests who just didn't know when it was time to go home? The next time that happens, try pulling out some of the following RFCs and reading them out loud:

RFC 2252, "Attribute Syntax Definitions"

RFC 2253, "UTF-8 String Representation of Distinguished Names "

RFC 2254, "The String Representation of LDAP Search Filters"

RFC 2255, "The LDAP URL Format"

RFC 2256, "A Summary of the X.500 User Schema for Use with LDAPv3"

RFC 2247, "Using Domains in LDAP X.500 Distinguished Names"

Actually, these documents, available through a quick search on the Internet, can give you more insight into the details of how LDAP works. They also can put you to sleep.

The LDAP Protocol

LDAP requests and replies are sent as an LDAP Protocol Data Unit (PDU) using either TCP or UDP to get from here to there. The kinds of functions that LDAP can provide include the following:

• Connecting to an LDAP server and authenticating the client to the server.

• Searching the directory and doing something with the results that are returned to the client.

• Managing memory on the client and handling any errors that pop up.

Binding to the Server

The client uses a bind request to make a connection to the LDAP-based directory database server. This must be done before the client can begin to query the directory for information. The request should contain the version number of the LDAP protocol the client uses, the name of the directory object to which the client wants to bind, and the information that is used for authentication. The server can respond in several ways (all described in the RFCs), but it basically comes down to one of the following:

• Operations error ” In other words, this is how the server tells the client, "You screwed up."

• Protocol error ” The server doesn't use the same version of LDAP that the client wants to use.

• Authentication method not supported ” LDAP allows for many different authentication schemes, and this is the message sent back when the server doesn't use the one that the client wants to use.

• Strong authentication required ” Similar to the preceding item, the server is telling the client that a strong authentication method must be used if you want to get any data from this server.

• Referral ” This is sort of like when your doctor hasn't a clue about what's wrong with you, so he refers you to another doctor. The server is telling the client that it doesn't have the object, or information, that the client is requesting, but gives the client a referral to another LDAP server that might have the info .

• SASL bind in progress ” The LDAP server is requesting that the client send in another bind request using SASL.

• Inappropriate authentication ” The client wants to use an "anonymous bind" but the server won't allow it.

• Invalid credentials ” The server can't process the authentication information sent by the client, or perhaps the client has forgotten the password.

• Unavailable ” Just an information message to tell the client that the server is shutting down.

Searching the Database

After the client has successfully binded with the server, it can send in a request to search for the data required by the client application. The client can specify where in the directory tree the search should begin, because searching the entire directory database is not very practical in most large databases. This means that the client must have at least some information regarding the kind of object about which it wants more information. The client's request also can specify the maximum number of objects it will accept back from the server in response to the search. If the client specifies a zero number of objects, the server can send back all the data it finds that matches the search criteria. Of course, the server can have limits for this set by the administrator of the database.

In its request, the client can specify how much time it wants the server to spend on the search, and again, zero means "Take all the time you want; I'm in no hurry." The client can query the server to return the types of attributes of the objects found, or both the attribute types and their values. Finally, the client can specify a filter to be used for the search and a list of the attributes it would like to receive, provided they are found in the database.

Adding, Modifying, or Deleting Information in the Directory

The client also can add information to the database, as long as it has the necessary permissions to do so, by specifying the distinguished name (so that the database will know exactly where in the database to put the new object) and values for all the mandatory attributes for the particular object class of which the client wants to create an instance. Take into consideration that for the addition to succeed, the relative distinguished names that make up the portion of the distinguished name that should be superior to the object in the tree must already exist.

To modify or delete an object from the database, the client again must specify the distinguished name of the object so that the server can locate it in the database. If the client just wants to modify an object, it must use one of several methods . It can add one more value to an attribute, delete one or more values for an attribute, or replace values for attributes of an object. But there is an exception to this: The relative distinguished name (RDN) of the object (its common name) can't be modified with a simple modify request, and neither can the relative distinguished names of objects above it in the hierarchy be modified. Instead, a special modify DN operation is used. This is because changing one of the RDNs can cause the object to be moved to a new location in the tree. This affects both the object and any child objects that exist under it in the tree.

Comparing Information in the Directory

The compare operation allows the client to simply supply the values for selected attributes of an object and ask the server to compare them with the actual values stored in the object and the method to be used for the comparison. Although the same thing could be accomplished by having the client read the database and make the comparison itself, this method can be used for things such as comparing passwords and other authentication information.