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 31, "Using the Active Directory," or Chapters 33, "Overview of the Novell Bindery and Novell Directory Services," and 34, "Expanding and Enhancing NDS: NetWare's eDirectory," 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.