InformationWeek

June 22, 1998

X.500, LDAP: Evolutionary Steps In Directory Access

Both emerged from a need to unite disparate systems

By Don Kiely

he dream of a truly distributed, global computer system requires that every computer be given access to the information and resources stored on every other computer. It also requires a management system that can monitor the performance and interaction of the distributed elements of this system. The logical way to make this information available is through a massive directory that can be searched and updated as computing resources change. Directories are repositories of information combined with access methods and related services.

One of the significant problems faced by application developers is managing all the bits and pieces of data used by various applications. For example, a single user may have an entry in an E-mail system, accounting's payroll system, and numerous other systems. Implementing access to all these information sources in custom applications can be a nightmare, complicating the chore of managing application development. Directory services provide a standard solution.

The most common directory is the local telephone book. An electronic version of a directory would be a database of object information sufficient to find a resource. But unlike a traditional computer database, the number of read operations in a directory is dramatically greater than the number of write operations. This is because the directory information changes infrequently but is searched and read frequently. Therefore, the ability to search and return information efficiently is far more important than entering and updating data.

Computer networks have always had some form of directory system for accessing and managing resources, if not to aid in locating those resources. But over the years, different operating systems and applications have stored directory information in a variety of proprietary formats. When each computing system used its own network directory system and the same applications, everyone could get at the data. But different applications use different formats, so a single name might appear multiple times in the E-mail system, accounting system, and database. In the age of distributed systems, there are various computers and networks linked together but running different operating systems and applications, making it hard to share information. This situation compounds a network administrator's trouble, since there has been no easy way to manage the network, computing resources, and applications from a central repository of information.

One solution has been custom bridging software that translates information from one format to another. Another option is to massively replicate directory information in various formats. Both methods are cumbersome at best.

First Open Solution
The X.500 directory services protocol, introduced in 1988, was the first open solution for uniting these disparate directories and computer systems. X.500 was designed to create an integrated local and global form of directory service, defining both how directory information is stored and the protocols used to access it.

The X.500 specification provided the Directory Access Protocol that lets client applications access the directory information and the Directory Service Protocol that designates how user directory requests are passed to other directory servers when the local server cannot satisfy the request. X.500 Directory System Agents support distributed directory servers by linking directories together. Subsequent refinements have added features such as internationalization, an information model, and access control for security.

The X.500 standard defines operations for searching and reading, modifying, and authenticating--each of which is broken into support operations. Each operation can be signed to ensure integrity, using the originating client or server's public key. X.500 supports several authentication methods. X.500 is an immense standard,

requiring robust servers to maintain the directory database, handle user search requests, and coordinate the passing of requests to other servers if the local server cannot handle the request. It's built on the Open Systems Interconnection protocol, requiring complex programs and heavy maintenance. Many features are used infrequently, leading to heavy overhead for little benefit.

These problems have kept X.500 from being adopted on any but the largest networks and only by organizations with the expertise and financial resources to build and maintain directories. Because of these problems, the University of Michigan drove the effort to develop the Lightweight Directory Access Protocol, a slimmed-down version of X.500, focusing on only the protocols that client applications use to access the directory.

When it was first introduced, LDAP required the services of X.500 servers, specifically their directory information storage features and passing of unfilled service requests to other directory servers. Refinements and sample implementations have made LDAP relatively more independent, allowing its use for local network and application-level directory systems, as well as its own directory data store.

There are four primary differences between X.500 and LDAP that make LDAP attractive for wider acceptance and use:

LDAP runs over the much simpler and more common Internet TCP/IP protocol instead of OSI, eliminating the top layers of the OSI stack.
LDAP simplifies the X.500 model by eliminating the list and read operations and emulating them in the search operation, and retaining only the most commonly used features.
LDAP uses a simpler encoding scheme, storing most data items and Distinguished Names as strings.
LDAP chases referrals so clients don't have to. X.500 generally just informs the user that it can't satisfy the user's request, but will refer the user to another server that may have the information. LDAP follows up on the referrals.

X.500 and LDAP rely on a namespace for efficient referencing and retrieval of collections of related information. Both use a hierarchical Directory Information Tree (DIT), similar to the most common disk file directories and B-tree indexing. While the meaning of each level in the hierarchy can vary to adapt its use for various applications, such as a directory of files on a hard drive, employees in a company, or network resources, the standards define one structure shown in the diagram above. This DIT consists of a root directory with no information, followed by countries, organizations, organization units, and individuals. The figure traces through and shows only three of the many thousands of organizations in the United States, and only two of the departments within the University of Alaska at Fairbanks (UAF). An individual scan includes both people and network addresses for computing resources such as servers and printers.

Each node of the hierarchy, except for the root, consists of an object, each with one or more attributes. Depending on the implementation of the directory, some attributes are mandatory and others are optional, as defined by a special object class attribute. At the organization level, the mandatory "o" attribute represents the organization's name and uniquely identifies the object from all others at that level, becoming the object's Relative Distinguished Name (RDN). At the bottom level shown in the figure, the common name attribute, cn, becomes the RDN and contains the individual's regular name. Note that there can be more than one value for an attribute, all of which are searchable entries in the directory.

LDAP supports multiple searching techniques, allowing you to obtain multiple objects back from a search. For example, you can search for all objects of a certain type using the object class attribute, such as to return all employees of a division, or for an individual person by specifying the common name attribute.

Unique Indentifier
Because the RDNs at each level of the hierarchy for this one directory are unique (but not necessarily globally unique across all directory servers), combining all of the RDNs above an object in the hierarchy provides a Distinguished Name that uniquely identifies each object. In the diagram above, my DN in this directory is "c=us, o=UAF, ou=Nors, cn=Don Kiely". Distinguished Name is the most common term, but LDAP documentation sometimes calls it a Directory Name or Designated Name.

One of the LDAP specifications, described in RFC 1959, describes an LDAP Web URL. This makes it possible to submit an LDAP search via the Web. For example, to find my record in a directory: ldap:// ldap.ldapserver.com//c=us,o=UAF, ou=Nors,cn=Don Kiely?one, or to return the E-mail address of all students and faculty in the Northern Studies program at UAF: ldap://ldap.ldapserver.com//c=us,o=ou=Nors?email?one.

One problem inherent in LDAP's hierarchical structure is that each object can have multiple attributes, but have only one parent. So, for example, I'm affiliated with both the Northern Studies and Computer Science departments at UAF, but can be a part of only one parent object. Some LDAP implementations have extensions to support such cross-listing, but at the moment, they are difficult to work with.

Industry Support
The driving force behind LDAP is its support from major software vendors, including Netscape, Microsoft, IBM, Sun Microsystems, and Novell. Netscape's Communicator is an LDAP client, and the company is incorporating LDAP server functions in its Web-server line. Just as it did with HTML, Netscape is working on a number of extensions to the standard to make it even more efficient. Some industry observers have suggested that if Netscape provides robust LDAP server code and releases it as it has with Communicator code, it would become the standard implementation.

Microsoft has committed itself to LDAP through its Active Directory services in Windows NT 5.0, which should be out early next year. Microsoft has also LDAP-enabled its Internet Mail client and Microsoft Exchange Server, and is developing an LDAP application programming interface that will simplify programming access to LDAP, particularly for development tools, such as Visual Basic, that lack the low-level language features of C and C++.

Sun has been casting about for a solid LDAP strategy, alternating between its own implementation and Novell Directory Services, probably the most stable and mature directory service available. But while Sun will probably continue to sell NDS, it is developing Solstice, an X.500 directory server.

Meanwhile, Novell is implementing LDAP support in NDS. IBM is implementing LDAP in many products, including Lotus Notes.

Like Netscape, however, many companies implement more than the LDAP standard, developing extensions that both push forward innovation and potentially resurrect communication problems. The danger is that LDAP will lose its lightweight characteristics as more features are adopted from X.500 and the industry accepts more vendor extensions.

X.500 and LDAP are gaining acceptance, but which of the extensions will also find broad appeal? Stay tuned.

Read the story, "Manage Custom Apps With LDAP."