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).
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.
The LDAP ProtocolLDAP 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:
Binding to the ServerThe 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:
Searching the DatabaseAfter 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 DirectoryThe 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 DirectoryThe 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. ![]() |