Appendix D. The Lightweight Directory Access Protocol
SOME OF THE MAIN TOPICS IN THIS APPENDIX ARE
A Quick Introduction to LDAP 1118
The X.500 Protocols and Standards 1118
The Lightweight Directory Access Protocol 1121
A few years ago the term directory services was understood by few, even though Novell’s directory, NDS, and Banyan Vines StreetTalk products had been around for many years. Microsoft was quick to tell you that Windows NT 4.0 Server had a directory service, but it was just the same old Security Accounts Manager database with a few extras added. In Windows 2000, Microsoft finally got around to creating a true directory based on the Lightweight Directory Access Protocol (LDAP) and support for this protocol has continued on in products like Windows Server 2003. NetWare 6.x has improved in the directory field by enabling an interface for NDS that acts as a go-between to allow native LDAP access to what is now called the eDirectory. In this appendix you will learn about the LDAP, and the history behind directory services that led to the development of a lighter version of directory services that is the de facto standard today for networks as well as many Internet services.
A Quick Introduction to LDAP
During the 1980s when PCs were first being accepted into the corporate environment, the computer room, which contained large proprietary mainframe or minicomputers, was in control of computer system managers. Simple terminal devices, such as the VT100 (a landmark in computer history itself), were attached to these large computers; access mechanisms, such as user accounts and passwords, along with file protection schemes, were used to control access to data. Applications were managed from a central location, and any interaction between computers was also the domain of computer system managers.
The introduction of the PC gave users the capability of managing their own applications and data files. PC networks were the next logical step, and suddenly computer system managers became network administrators and realized that the chaotic environment that came with distributed management was plagued with many problems.
At about the same time, many large businesses found it necessary to support multiple proprietary computing platforms, based on things such as application availability and maintenance costs. Supporting multiple operating systems and hardware platforms produced a dilemma: Users needed to access data on different computers, and each department (and sometimes each user) required setting up different access control mechanisms. In addition, locating the services (or applications) that each user needed became a complex task.
To try to conquer this collection of proprietary systems and distributed data, the X.500 set of protocols was proposed. X.500 encompassed network protocols as well as a method for storing information about resources, applications, users, and other data so that a network based on different systems could be easily managed. Although the X.500 protocols were never widely adopted, they did lay the groundwork for what was later to become the Lightweight Directory Access Protocol.
I can’t remember who said it, but it is true that one of the best things about standards is that there are so many to choose from. This is especially the case when it comes to directory services. What started out as a good idea—X.500—spawned all sorts of development of protocols and services that eventually led to the development of LDAP.
The X.500 Protocols and Standards
In 1993, the International Telecommunications Union (ITU) approved the X.500 standard. This later was adopted also by the International Organization for Standardization (ISO). All that said, just what is X.500 and why is it so important for directory services today?
Basically, the X.500 set of standards was developed to provide a common namespace that could be used by various applications so that common data could be consolidated into a single hierarchical namespace. For example, an earlier standard known as X.400 was developed to help standardize email applications on the Internet. Initially, development on X.500 protocols and services was developed to interface with X.400 email-compliant systems so that different products could equally access important information, such as email addresses. However, the hierarchical structure of the namespace described by the X.500 standard was so elegant that it didn’t take long for developers to realize that it could be used to organize all kinds of data.
X.500 is a general term that covers several complex protocols using the hierarchical namespace to access a database. The problem is that when X.500 was developed, the protocols that were proposed were too cumbersome and required too much computing overhead to ever be practically employed on small personal computers. Instead, these protocols were created to run on minicomputers and mainframe computers that were still the mainstay of corporate computing.
Other standard protocols were developed along with X.500, such as the OSI networking protocols. However, by the time anyone got around to actually trying to create a market for the OSI-related protocols and services, the Internet had already been pretty much standardized on the TCP/IP protocol suite. In addition to the OSI protocols, the OSI seven-layer Network Reference Model (described in Appendix A, “Overview of the OSI Seven-Layer Networking Reference Model,”) was created so that network protocols could be discussed in terms that compartmentalized the functions that a computer network performs.
Once again, TCP/IP has become so predominant that even the OSI reference model is a bit dated. Indeed, TCP/IP is based on an earlier model (as described in Chapter 25, “Overview of the TCP/IP Protocol Suite”).
Yet, you don’t throw the baby out with the bath water, as the old saying goes. There were some good ideas in the OSI protocols, and the namespace provided by X.500 was an excellent solution looking for a problem. After the Internet went commercial and larger corporate networks were created, it became apparent that some kind of logical organization was needed to manage diverse kinds of information.
The Domain Name System (yet another child of the TCP/IP protocol suite) was created to handle resolving host computer and network names to IP addresses, and it is still used today on the Internet. However, when it comes to managing users and data and resources on networks, the term “directory services” is where it’s at today.
Novell Directory Services (NDS) was a leader in this kind of technology for several years. NDS is widely deployed still today (reincarnated as the eDirectory), although the newer versions of NetWare have finally accepted TCP/IP as a transport protocol. Microsoft spent several years promising that the Active Directory would solve just about every problem a network administrator could dream of. Of course, we now know that any kind of directory service is going to be complex to manage due to the many types of applications it is used for and the kinds of information that need to be stored in the database.
Acronyms, Acronyms, Acronyms!
But in the beginning there was X.500 and the protocols that were developed to work with it. These were the main protocols developed for X.500:
Directory Access Protocol (DAP)
Directory System Protocol (DSP)
Directory Information Shadowing Protocol (DISP)
Directory Operational Binding Management Protocol (DOP)
DAP, DSP, DISP, DOP, Duh? Well, let’s get a little more specific, and throw in a few more acronyms.
The DIB and the DIT
The Directory Information Base (DIB) is the actual database and the data stored by the directory. Every record in the database is an object that holds some kind of data. Objects are collections of attributes that store the actual values of the properties of objects that are records in the database.
The DIB can be a small database that is hosted on a single computer, or it can be a large, distributed database that resides on many computers. Because the database is organized in a hierarchical fashion, it is easy to locate an object, no matter on which server it actually is stored.
The treelike structure that organizes the objects in the database is called the Directory Information Tree (DIT). At the top of the tree is the entry called the root object. In Microsoft’s case it’s called the Top abstract class. But the name really doesn’t matter. The point is that you can start at a single entry point in the tree structure (the top) and locate an object—using a carefully constructed name—by traversing the branches that make up the tree, until you finally get to the leaf object that contains the actual data you are looking for. In addition to leaf objects that store the real data (as object attributes), there also are container objects in the tree structure that hold other container objects and also leaf objects. Using container objects makes it easy to group objects that have something in common. Another type of object in the DIT is the alias object, which is used to give a nicer name to some other object in the tree to which the alias points.
The DUA, DSA, and DAP
The Directory User Agent (DUA) is the client application that is used to access the database (DIB) that is organized by the tree structure (DIT). The DUA queries the database to find the information that the client application needs to obtain. Specifically, the DUA can perform the following tasks:
Read some or all of the values for attributes of a particular object in the database.
Compare a value with an attribute of an object in the database to see whether they are the same.
List objects that are subordinate in the tree structure to an object specified by the DUA.
Search the database, either all or a portion of it, to find objects that have attributes matching values supplied by the DUA. A search can return more than one object to the DUA, depending on the criteria that the DUA supplies for the search filter.
Abandon the search or any other request that the DUA has previously made to the directory database.
Add an entry, or a new object, to the database, provided that the necessary access permissions allow this.
Modify an object (well, one or more of its attributes) in the database, again provided that permissions allow for it and also provided that the new value the DUA wants to give to an attribute is allowable by the syntax associated with the attribute.
Remove an entry from the database, provided that the client application has permission to do so.
Modify a distinguished name (DN).
Of course, to make matters more complex, DAP is the protocol that governs how the DUA interacts with the DSA. The DSA is the server side of this equation. So basically, you have the Directory User Agent interacting with the Directory Access Protocol that talks to the Directory System Protocol to get all this done. It’s that easy to remember: DUA uses DAP to talk to the DSA, which does all the work the DUA wants done in the directory! The DOP protocol was developed for administrative purposes to manage operational bindings between different DSAs.
The DN and the RDN
The final item in this list might seem insignificant, but it is not because of the method used to name objects in the DIT. Each object has a “common” name, also called the relative distinguished name (RDN), which does not have to be unique in the DIT. For example, you might have several objects in the directory named HPLASERJET. However, the distinguished name (DN) for an object is its common name (or its RDN), concatenated with all the common names of the objects in the directory that are above it. The relative distinguished name doesn’t have to be unique in the directory structure, but the full distinguished name, by the very nature in which it is formed, must be unique.
This is why it is so easy to locate objects in the directory. If you know the object’s distinguished name, you essentially have a path through the tree that leads to the object you want to find.
The Schema
If you have read Chapter 30, “Using the Active Directory,” you probably are aware that to create objects consisting of attributes and organize them into a tree structure, you must have rules about how this all fits together. The schema is this set of rules. The schema is similar to a dictionary in that it defines object classes, which then are used to create the actual objects in the tree. The schema also defines the attributes, and the kinds of data each attribute can hold (the syntax). The schema defines whether certain attributes of an object are mandatory or optional.
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. LDAP is “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/Vista and Windows Server 2003.
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 (introduced in Windows 2000 Server and also a part of Windows Server 2003) 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.
LDAP Directories
LDAP is now found in just about every medium to large-scale network today. If you are running NDS (or the eDirectory), Microsoft Windows 2000, or Windows Server 2003, then using LDAP can make managing the network a much simpler task than trying to manage separate islands of data stored on many computers. In today’s business environment where companies are merging, using LDAP to store user and application information is almost a necessity. LDAP enables the network administrator to consolidate information into a logical hierarchical database, a much simpler task than in years past.
Windows 2000 Server, Windows Server 2003, and NetWare Are Not the Only Choices You Have
In past years the two primary contenders for your network dollars have been Microsoft and Novell. Although NetWare 6.x still includes NDS, now called the eDirectory, Novell is moving away from its core application services and directory services and concentrating on SuSE Linux, which it now owns. Although the eDirectory will probably be around for a few more years to accommodate existing users, the company appears to be focusing now on Internet services, as evidenced by its iPrint and iFolder products. While Microsoft is trying to pull together a wide assortment of technologies by using the Active Directory, Novell is now trying to break apart its offerings into separate pieces so that you can choose what you like. The marketplace will determine who will succeed in this ongoing saga.
Yet, as a network administrator, you need not feel that you are constrained by Microsoft or Novell. Directory services are going to be here for quite some time until someone thinks up a better way to make locating and using network resources an easier task. Many other vendors, such as Netscape, jumped into the fray early on, and you will find that if you do not want to be locked into any particular vendor, there are other solutions. For example, one of the most popular Linux LDAP implemtations is OpenLDAP, which is available from http://www.openldap.org.
Sun includes a directory server developed from the iPlanet Directory Server as part of its Sun Java Enterprise System and Sun Java System Suites. See http://www.sun.com/software/products/directory_srvr_ee/index.xml for more information.
Using a search engine, you can find a large number of software vendors that now offer LDAP directory servers.
Sticking to Standards: Interoperability Between Directories
LDAP was developed to be a standard method for accessing a directory database. Just as TCP/IP allows data transfers and interoperability between different operating systems, the goal of LDAP is to do the same thing for directories.
However, while the structure of the database (the schema) and the protocol for a directory server are defined by the LDAP standards, that doesn’t guarantee that all directory server products will easily interact with one another. This will probably change in the future as directories become more important in the corporate environment.
Import and Export Utilities
The LDAP Data Interchange Format (LDIF) is a specification that lets you export data from an LDAP compliant directory to a flat-file, and then import the data into another directory. LDIF enables you to specify a point in the directory structure from which the export will be performed, and you can also filter selected objects or attributes. Most directory server products support LDIF, including Microsoft’s Active Directory, Novell’s eDirectory, and OpenLDAP.
Metadirectories
In some cases you might find it desirable to maintain different directory servers instead of using LDIF to import data into a single server. For example, following the acquisition of another company, it may be impractical to integrate data into a single directory server product. Or it may be that each directory server provides features, all of which you want to keep. Another reason for maintaining multiple directory products is the cost of training network personnel on new applications. By keeping the same directories in place, business as usual can continue in today’s fast-paced business world. Lastly, one of the features that a metadirectory product can provide is the capability to interface with data stores other than LDAP-based directories. Some applications, such as email products, were not written to work with LDAP servers but can be easily managed using a metadirectory product.