A directory is simply a set of information and a method -- in computer lingo, a protocol -- for accessing it. In the case of the yellow pages, the set of information is phone numbers and names, and the protocol is "alphabetically by last name." If you think directories sound similar to databases, you're correct, with one caveat: a directory's information typically gets read far more often than it gets written. A directory service, then, is a specialized database designed for frequent lookups and infrequent updates.

Returning to the phone book for a moment: A reverse lookup is difficult unless you have a phone book arranged according to a different protocol -- numerically. Alternatively, you can have a computer do the reverse lookup for you. The advantages of converting directories to electronic form should be obvious: Computers can do the heavy lifting of searches and retrievals much faster than a human, and can be constantly up-to-date, whereas a printed phone book is out of date by the time it reaches the door.

Electronic Directories
Some electronic directories are more relevant to the information technology field than the phone book. The Internet's Domain Name System (DNS) is the most common example. DNS correlates easy-to-remember (usually, anyway) computer names with numerical IP addresses. If configured incorrectly, DNS can be doped with false information, a process known as "cache poisoning." A contaminated DNS server can misdirect queries, perhaps transmitting sensitive information to someone malicious. Security of an electronic directory service is important, then, if you intend it to be useful.

DNS is also a distributed directory: That is, there is no single server that holds all the names in the Domain Name System. Instead, each DNS server is authoritative for a particular DNS zone, or subset of information. Some extensions to DNS have been made. For instance, mail programs needed to be able to locate computers capable of receiving and sending mail. To meet this need, a special type of DNS record was designed: the MX or Mail Exchange record. The information stored in DNS is still useful for only one task, though: locating computers. DNS doesn't have a lot to say about people. To deal with this lack, members of the International Standards Organization (ISO) designed X.500, a generalized directory service protocol that could deal with almost any form of information.

X.500 was designed to be a global directory service, and the general consensus seems to be that it was simply too difficult for most people to implement. To relieve the difficulties of X.500 adoption, the University of Michigan designed LDAP, the Lightweight Directory Access Protocol, an easy-to-implement directory server. Aside from being a directory in its own right, LDAP can also act as a front end to X.500 directories. Most of the commercial directory service implementations on the market are LDAP compliant as well as X.500 compliant.

LDAP in Brief
An LDAP-based directory consists of classes, each with a set of attributes. Attributes can be mandatory or optional. Sometimes you can have multiple instances of an attribute. For instance, a sample LDAP entry for the "person" class might look like the following:

Common Name=Samuel Clemens
Common Name: Mark Twain
Birthplace: Hannibal
State: Missouri
Description: that inveterate liar...

Each LDAP entry also has one attribute, the distinguished name, by which it can be uniquely identified. Note that although Mr. Clemens has more than one common name, only one value is guaranteed to be unique -- the one listed in the distinguished name. A distinguished name for Mr. Clemens, then, might be:

Common Name=Samuel Clemens, Birthplace=Hannibal, State=Missouri, Country=US

Actually, the above example doesn't adhere to the LDAP specification, but it makes the point. A class gets defined in relationship to other classes: that is, a class requires certain classes as its parents, and allows certain others as its children. In this case, the state class is a child of the country class. The "top" class, which acts as a placeholder similar to the way the "/" or root directory does in a Unix file system, has no parents.

The definition of all the classes and attributes that comprise the directory is called the schema. It should be obvious that if we want to hold more information about a given entry, we would extend the schema to include that information. Since "Mark Twain" is actually a nickname rather than a given name, we might want to add a "nickname" attribute. LDAP makes this easy to do, but if we had done a bit more research, we might have discovered that the LDAP developers thought of this already, and that they've defined a number of classes and attributes for us already, including the nickname.

One last thing: LDAP and X.500 only specify a method for accessing your data. How and where data is stored varies from implementation to implementation. Oracle, for instance, markets an LDAP server that's simply a front end to a normal Oracle database.

Vendors
Knowing what you need your directory to do is critical to making the right purchase. As of this writing, these seem to be the major commercial players in the directory services field:

• Active Directory (AD) from Microsoft (included with Windows 2000 Advanced Server)
• iPlanet Directory Server from the Sun/Netscape alliance
• Novell Directory Services (NDS), now known as eDirectory, from Novell
• Oracle Internet Directory from Oracle

Using the default schema included with the reference LDAP version 3 implementation from http://www.openldap.org, you could construct a very useful directory service for your organization. However, you'd probably only be dealing with people. Suppose you also wanted to integrate information about human and other resources: offices, conference rooms, meeting times, even computers and the permissions to use particular pieces of software. You'd have to extend your schema.

This is where the vendors come into play. The real value of the vendor directory service implementations lies not in the fact that they are directories -- almost any implementation meets that definition -- but in the additional schema extensions they've made and what those extensions enable you to do. So knowing what you need your directory to do is largely a matter of knowing what sort of information it needs to store, what applications need to use that information, and finding the vendor that's done most of the legwork for you.

Directory-Enabled Applications
Novell and Microsoft's directory services concentrate on user and resource management, as would be expected from their workgroup server background. Each provides a schema that can store everything from information about a user's password expiration date to the workstations he or she is permitted to use. Other applications can use the information stored in these directories to do things like automatically install software for a recent hire, or lock a recent fire's account. Applications that use the directory as an information store in this manner are usually called "directory-enabled" applications.

The Netscape-Sun and Oracle schemas are less extensive, and don't include as many built-in provisions for resource management. However, this may be an advantage for e-commerce firms, where the administration of in-house physical resources can be kept separate, to a degree, from customer information. For the purpose of managing customer information to provide Web-based services, a simpler schema may be in order.

Vendors muddle the distinction between the directory and the applications accessing it, so don't get confused. In the case of Microsoft Windows 2000, the operating system itself is less standalone product than directory-enabled application, a characteristic that will undoubtedly be more pronounced in future releases. Unfortunately, many directory services are sold as end-to-end solutions, and integration with other technologies doesn't seem to be high on anyone's list.

The advantages of a centralized directory become clear once you extend the meaning of "directory services" to include management of resources, not just storage of information about those resources. However, not all resources can automatically be managed. The directory service has to have a hook on which to hang its hat. Novell and Microsoft use client software to accomplish this (the Novell client and the Active Directory client, respectively). Other vendors may also provide such hooks: Cisco, for one, provides extensions to Active Directory that allow you to manage Cisco hardware via the Windows 2000 interface.

Cisco and Microsoft also began the Directory-Enabled Networks initiative. DEN provides schema definitions and tools to facilitate directory-enabled management. If you're familiar with the Simple Network Management Protocol (SNMP), the DEN specifications provide vendor-independent management standards for application and desktop management, similar to what SNMP did for the management of network devices (routers, switches, network cards). As these standards are more widely adopted, directory services should be able to manage any DEN-equipped device, not just computers with a Microsoft or Novell client.

Other Concerns
There are many other concerns when investing in a directory service. Platform compatibility is on. Novell's directory service has clients for multiple platforms, Microsoft's does not. A heterogeneous computing environment may require a more open directory service.

Since it's the only thing left unspecified by the LDAP specifications, the data store is important. Each directory service uses a different one:

• Oracle Internet Directory uses Oracle.
• NDS uses Novell's proprietary data store, the Directory Information Base (DIB) file.
• Netscape/Sun iPlanet uses a variant of the original University of Michigan data store.
• Active Directory uses the Extensible Schema Engine, the same database used by Microsoft Exchange.

It's worth examining the reputation of each for stability, scalability and recoverability in worst-case scenarios.

What Does it All Mean?
In all honesty, it's very unlikely that a single directory service is going to meet all the needs of any organization. Directory services tend to proliferate, based on things like political control of data, special performance requirements and bad planning.

The wave of the future seems to be metadirectories, which are just what they sound like: directories of directories. Standards are being developed to deal with the technical issues inherent in obtaining and interpreting data from multiple different sources, which will clearly be the main task of any metadirectory product. The Directory Services Markup Language (DSML), a derivative of XML that's intended to be the "glue" between different directories, is the most promising of these. So even if you can't have a single directory, you can build applications that sift out the duplicate, extraneous, or just plain wrong information from a number of directories.

Personally, I won't be giving up my day-planner anytime soon. It uses this pen-and-ink protocol I'm pretty comfortable with.

Discuss this topic: Post your comments/questions on directory services below!