Introduction to Directory Services and the Lightweight Directory Access Protocol (LDAP)

By Tom Larson, 1998

A directory service is a database with only a subset of the usual functionality. The abilities that it does have are focused on a specific purpose. A general-purpose database could also accomplish what a directory service is capable of, but a directory is less complicated to write, use, and maintain. Where a database may use complicated SQL queries to accomplish powerful search operations, a directory achieves simplicity because it is hierarchical, and search operations are likewise simpler. A directory has a specific focus, which makes it much easier to construct, and keep optimized for the job that it is intended to accomplish. The most important aspect of a directory service is that the information within is reachable over the network. The information stored is usually hierarchical in nature, such as personal information of people, who are in a hierarchies of subdivisions, divisions, companies, and countries. This has led to the most popular types of directories, online versions of phone and address directories. Directories can be used for any information, really, and don't even have to be hierarchical. They are intended for situations where there is a high access to update ratio, compared to general-purpose databases. Typically, directory servers deal with small data; when large pieces of data are involved, an address is stored instead of the information itself.

Certain applications deal with the directory information as their main functionality. These are the phone and address servers, where the directory is the sole purpose of the application. Other applications can also benefit from being "directory-enabled", however. This means taking some aspect of it, such as configuration information, and storing it in a directory service, instead of the usual solution, a file. In this type of application, the directory service makes the application easier to use, more extensible, quicker to set up, or enhanced in some other way. The directory service is not absolutely necessary to the application, but does offer some improvements. Directory-enabling an application has at least two advantages: reducing redundancy, and putting information and configurations on the network. Redundancy can occur when you have information such as email addresses stored in multiple, application-specific configuration files for several different email-related applications. If those addresses were instead stored on a directory server, they would only be stored once, avoiding redundancy and possible inconsistency. Information can be put on the network to make it reachable by more than just local users. Making email addresses available to outside users is a common practice of schools, and is a very good use for a directory. If it puts its configuration information on the network, an application can retrieve it from a central server at load time, instead of from a static file. This means that no matter where a user logs in, their applications will behave the same. This is a very desirable feature for users and administrators of a collection of common-use workstations (like RCS).

The original popular directory service was X.500. It was mostly used in Europe, and needed to use the OSI protocol stack. X.500 was very good for containing directory-style information, such as phone and address books, and company organization structures. X.500 was fully network-enabled. The information within could be easily accessed over the network -- an OSI network. The OSI stack and X.500, however, are large, complicated programs, and their heavyweight nature makes them costly to implement on clients. Also, OSI is not as popular as the TCP/IP stack, developed in the U.S. and now the heart of the worldwide Internet. X.500 had the X.500 Directoy Access Protocol, another heavyweight OSI protocol, and there were multiple attempts to put a lightweight front-end on this protocol. First, there were DAS and DIXIE, and now LDAP. LDAP provides 90 percent of the functionality of actual X.500, but at only 10 percent of the cost. LDAP is designed to run on top of TCP, but will also run on OSI's COTS without modification. LDAP has been used as a front-end of X.500 directories, but it is much more popular as a standalone server. For those locations who do not already have X.500 implemented, and don't want to spend the time and money on the extra horsepower X.500 needs, an LDAP server is well-suited.

LDAP was developed by the IETF OSI-DS and ASID working groups, with a lot of research done at the University of Michigan. U-M hosts an LDAP web site with LDAP information, the U-M LDAP SDK, and U-M LDAP server and client implementations, all distributed as source. There is a companion LDAP API specified in RFC 1823, which has become a de facto standard. The API has many useful abilities like setting server-side time and size limits, client-side time limits, and a thorough error-reporting scheme. This API has been implemented by U-M and is freely available for application writers to use. The U-M implementations are not being actively worked on anymore. The team that worked on it originally has mostly moved on to Netscape. Many commercial implementations of LDAP servers are available, and another API is available from Netscape. With much of Netscape's source code becoming freely available, the non-server-related LDAP source has also become open.

LDAP consists of a data-representation scheme, a set of defined operations, and a request/response network protocol. Data is represented as strings rather than the highly-structured data types that X.500 uses. An entry consists of a Distinguished Name, has a type (the objectClass attribute) and a series of attributes, which each contains a type and one or more values. The Distinguished Name (DN) contains part of the hierarchy to uniquely define an entry. An example is , where cn stands for "common name", o stands for "organization name", and c stands for "country name". These shorthand variables and their meanings are described in RFC 1779, along with other variables. A directory designer can use any variables desired to create the hierarchy. There is a common architecture however, and it is beneficial to follow that design, since that would become an extension of the global LDAP directory, distributed amongst individual organizations. Using this DN, a client can get to the information associated with that entry. This could be more cn's, like "Bill Clinton" and "Slick Willy", because any attribute can be multi-valued. There would normally be more information, like phone, email, and food. This additional information is the purpose of the directory server, after all. Again, these variables are completely up to the directory designer, but there are standards for certain data types, like Person. It is possible for a system to ignore the hierarchy; it is not required, although a hierarchy makes DN uniqueness much easier to implement.

LDAP has many operations defined that you would expect in an online database protocol. First, there are bind and unbind operations for authenticating with a server, and setting up or taking down a connection. Then, there is a search operation, with many options for pattern matching, checking existence of attributes, starting point within the hierarchy, and following of aliases. A server will answer a request with a series of responses, each containing one matched entry, and a success or failure indication. It is possible to return one or more matches, but indicate failure, as well as to return no matches and indicate success. There are four operations that are used to change the contents of a directory server: modify, add, delete, and modify RDN. Modify is used to change the values and attributes in an existing entry. Add and delete create or destroy an entry within the server. Modify RDN can change part of the DN (each comma-separated part of the DN is a Relative Distinguished Name), effectively moving an entry to a different part of the hierarchy. Compare can be used to check an assertion concerning a particular entry. The server will return a true, false, or failure result. Finally, abandon is defined in LDAP to allow a client to ask a server to quit executing a specific operation.

With this loose specification of names, structure, and operations, directory administrators and application writers can make use of a directory in many ways. With the LDAP API available from University of Michigan, an application can very easily make use of an LDAP server to hold configuration information. The administrators can then use the server to centralize configuration management, and hold non-redundant information that many applications can share. LDAP also has the benefit of being an Internet-based standard, which various directory services have standardized on. As long as a new directory server supports an LDAP interface, it can be used in an existing directory system to replace an older server, without change to client software.