LDAP and the Future of Directory Services, Part 1

Part 1: A look at LDAP's capabilities and shortcomings

As an enterprise network expands from a file-and-print platform to aplatform that includes email systems, databases, Web servers, and otherapplications and services, the need for a universal directory service becomesincreasingly apparent. The big three in the networking industry--Novell,Netscape, and Microsoft--are trying to meet this need by developing thedefinitive directory service solution. Although their solutions are in differentstages of development and use different methodologies, all three have committedto using the Lightweight Directory Access Protocol (LDAP) in their directoryservice products.

How Novell, Microsoft, and Netscape are using LDAP in their directoryservice products will be the focus of the second part of this two-part article.But before you look at how the big three are using LDAP, you first need tounderstand LDAP's function, ancestry, birth, and evolution.

Why You Need LDAP
In a typical business network, employees need access to different servicesand applications, such as a network drive (such as a Windows NT domain),printers, an email system (such as Lotus Notes), and NetWare servers. So even ina basic network, employees need access to several protected services on severalplatforms. Therefore, businesses need a single directory service that canprovide authenticated access to all of these resources. This directory serviceneeds to do much more than provide usernames and passwords. It needs toeffectively store many different types of data (such as client contactinformation, application configuration data, and personal documents) in acentral location. The directory service also needs to give employees the abilityto access that database from any workstation on the network or from a remotelocation.

The main obstacle to developing such a directory service is that manybusiness network services and applications have proprietary user directories.Because the data in proprietary directories cannot be applied to otherapplications, network administrators must create separate accounts for thevarious services and applications. Creating separate accounts not only generatesadditional work, but also makes the task of changing passwords a nightmare.

To create a single user account that provides access to services, fileservers, databases, and other applications, you need a communications linkbetween the directory service and proprietary applications. LDAP provides thislink.

Meet LDAP's Ancestors
Researchers at the University of Michigan, with support from the NationalScience Foundation, originally developed LDAP as a simplified means for clientsto access X.500 directory servers. X.500 is the International TelecommunicationsUnion (ITU) standard that defines the basic structure and functionality of adirectory service model. According to X.500, a directory service includes fiveelements.

1. A directory service has a model that defines the basic structurein which information is stored. A directory service consists of entries,attributes, and values.

Entries represent elements in the directory service. For example, if adirectory service has 20 network users, 2 directory shares, and a sharedprinter, the model would include one entry for each element, giving a total of23 entries.

Each entry contains attributes. Attributes represent the properties thatthe directory service needs to classify the entry. For example, the attributesfor the entry of network user might be the user surname and the user emailaddress.

Each attribute contains values. Values are the representation ofattributes. For example, the value for the attribute of user email address mightbe [email protected].

2. A directory service has a tree-like hierarchy, called adirectory information tree. The DIT stores the directory's entries anduses namespaces to uniquely identify every entry's exact place in the tree. Atthe top of the tree, you use geographical constructs (i.e., two-letter countryidentifiers) to determine the hierarchy of entries. As you proceed downward, youuse more arbitrary organizational constructs (e.g., departments) to determinethe hierarchy of entries. An entry's distinguished name (DN) traces the entry'spath in the tree, much like a pathname defines the location of a file in a filesystem tree. (To see an illustration of a DIT and a DN, see "Howto Name and Place Objects in the Directory Information Tree.")

3. A directory service has a collection of command functions thatclients can use to manipulate directory entries. These command functionsinclude Read, List, Search, Add, Delete, Modify, and Bind (brings two elementstogether as a unit).

4. A directory service has a system to authenticate users. Thedirectory service must authenticate users before granting them access to thedirectory. You can use any of several different authentication methods,including a simple password option and the Kerberos network authenticationservice.

5. A directory service has a distribution model that lets clients(called directory user agents) view the data stored on multiple servers (calleddirectory system agents) as a single entity. If a server receives arequest for data that is stored elsewhere, it passes the request to theappropriate server using one of two methods: chaining or referral.

Chaining is the process by which an X.500 server, after receiving aclient's request that it cannot satisfy, sends an identical request to anotherserver. If the second server cannot satisfy the request, it passes the requestto a third server. The servers continue this process until the request reaches aserver that can respond to it. The response then follows the same route back tothe original client, as shown in Figure 1.

Alternatively, a server can respond to a request that it cannot satisfy bysupplying the requester with a referral. The referral identifies the server thatcontains the requested data. The requester, which can be the original client orone of the interim servers, then sends a new request directly to the correctserver, as shown in Figure 2.

Novell, Netscape, and Microsoft created their directory service productsbased on these X.500 specifications. The big three are not the only companiestaking advantage of these specs. Many other organizations use them, but for adifferent purpose. For example, organizations use X.500 specs to buildwhite-page directories.

From the outset, white-page directories have had the potential to storemany types of information other than phone numbers and email addresses. But thispotential remains largely untapped because of problems with providing clientaccess to the directory server.

Congratulations, It's a Protocol
X.500 states that the Directory Access Protocol (DAP) is the protocol to usewhen connecting client systems to the directory server. But DAP requires thatclients use the Open Systems Interconnect (OSI) protocol stack as well assignificant amounts of memory and other system resources. So the University ofMichigan designed LDAP as a subset of DAP. LDAP eliminates much of DAP'sseldom-used functionality. In addition, unlike DAP, LDAP runs over a standardclient TCP/IP connection.

The Internet Engineering Task Force (IETF) defines the current version ofLDAP (LDAP 2) in Request for Comments (RFC) 1777 and RFC 1778. LDAP 2, whichcontains more specifications than most protocols, describes how a client and aserver can exchange X.500-based messages.

In the exchange process, the LDAP client uses a TCP connection to sendrequests to an LDAP server. As Figure 3 shows, the server then uses OSIcommunications to perform the requested activities on the X.500 directory. TheLDAP server can be a separate application that uses an LDAP gateway tocommunicate with an X.500 server, or it can be part of an X.500 serverimplementation.

Here is how LDAP systems differ from X.500 systems. LDAP servers use thesame directory service structure and namespaces as X.500 servers, but LDAPservers use fewer command functions to provide roughly the same level offunctionality. For example, an X.500 server has Read and List commands, while anLDAP server uses the Search command to carry out these two functions.

LDAP servers have fewer authentication capabilities than X.500 servers.Whereas X.500 servers offer several authentication methods, LDAP servers haveonly two options: plain-text password and version 4 of the Kerberos networkauthentication service.

Unlike an X.500 client, an LDAP client does not participate in the referralprocess. Instead the LDAP server processes referrals and regenerates requests.The only communications that an LDAP client can receive from a server are theresponses to its requests and error messages explaining a server's failure tofulfill a request.

LDAP servers reduce the burden of the directory service client bysimplifying the encoding process used to transmit the distinguished names ofdirectory entries. X.500 servers do not perform this service.

LDAP's Evolution
As more companies adopt LDAP, they are finding innovative ways to use it.Take, for example, Netscape and Microsoft. Because LDAP runs over a TCP/IPconnection, access to X.500 data is no longer limited to OSI clients onintranets. Clients can use the Internet to access private X.500 directories, aprocess that has come to be known as extranetting. Extranetting has led to thefirst widespread implementation of LDAP clients, which took the form of addressbooks for the email applications in Netscape Communicator and Microsoft InternetExplorer (IE).

Both Communicator and IE let users search for email and telephone addressesin private directories on a local network. In addition, as Screen 1 shows, userscan search for email and telephone addresses in Internet white pages that useLDAP servers such as Four11 and Bigfoot. Communicator and IE serve as a modelfor future application development because these services use an LDAP-clientmodule rather than a proprietary authentication directory.

Netscape used LDAP in another innovative application. To facilitate the useof LDAP over the Internet, RFC 1959 defines a universal resource locator (URL)format that provides direct access to LDAP servers through a browserapplication. This format includes a new LDAP prefix to replace the HTTP commonlyseen in URL notation. For example, a URL like ldap://ldap.mycorp.com/o=Sales,c=US?EmailAddress?one would return the values contained in the emailaddress attribute for all of the objects in the US sales department of the givencompany. As of this writing, the Netscape Navigator in the Netscape Communicator4.0 Preview Release 3 is the only browser that supports LDAP URLs.

The potential of LDAP goes beyond access to X.500 directories. Even withLDAP largely replacing DAP for client/server communications, X.500 is adifficult directory to install and maintain, making it impractical for use as anintranet directory service, except in large organizations. So major softwarevendors are trying to use LDAP servers to communicate with other directoryservices or to function as a directory in itself.

Although Netscape was successful in using an LDAP server as a directory,vendors' attempts to use LDAP to access other directory services have beenmostly unsuccessful. This fact isn't surprising, however, given that RFC 1777states LDAP 2 is designed to provide access to the X.500 directory. For thisreason, work is proceeding on LDAP 3. The current draft specification describesLDAP 3 as being designed to provide access to directories supporting the X.500model and not necessarily to the X.500 directory itself.

This revision is a critical step in the evolution of the protocol. Manydifferent parties, especially Microsoft, Novell, and Netscape, want to see LDAPdeveloped in ways that best suit their needs. But for the good of the networkingindustry, partisan interests must not affect the future of the standard.

One primary improvement planned in LDAP 3 is the protocol's ability tomodify a directory's structure to accommodate the requirements of specificapplications. This modification would involve altering the directory'sschema. The schema is a set of rules that governs the nature of a directoryentry, its attributes, and the syntax of the attributes' values.

Modifying a directory's schema is not terribly difficult. The problemarises when directories with different schema must communicate with each other.LDAP 2 doesn't address this problem because the LDAP server was expected toalways be communicating with an X.500 directory.

To solve incompatible schema problems, several different groups are workingto develop standard schema. The groups will face many challenges. Not only dothey have to develop a single standard, but they also have to rewrite existingapplications using the new schema.

The LDAP 3 draft specification calls for a different, more universalsolution to incompatible schema: the use of specialized subschema entries. Withsubschema entries, people could publish the details of a directory's schema andshare those details with another directory. An exchange of schema informationwould occur before two directories begin to communicate.

The LDAP 3 draft specification proposes other major improvements, such asbetter support for user authentication. Instead of offering the option ofplain-text passwords (which isn't an option if you want a secure network), theLDAP 3 draft promotes the use of the Secure Sockets Layer (SSL) standard, whichis commonly used for Internet communications, and a new mechanism called theSimple Authentication and Security Layer (SASL). With SSL and SASL, people willhave a real security alternative if they don't want to implement a third-partyauthentication service, such as Kerberos. Other proposed LDAP improvementsinclude support for international character sets, type-down addressing(which lets search engines narrow their selection as each letter of a query isentered), LDAP server ability to return referrals to a client, and the deliveryof search results in individual pages.

Many improvements proposed in the LDAP 3 draft specification are pushingthe protocol away from being properly labeled as lightweight. However, when youcompare LDAP 3 to X.500, the label remains appropriate. In addition, as the LDAP3 draft specification approaches the point at which it enters the standardstrack of the IETF review and development process, some of these features willlikely be removed to streamline the protocol.

Look for Part 2
Now that you know about LDAP's function, ancestry, birth, and evolution, youare ready to explore how Microsoft, Novell, and Netscape are implementing LDAPin their directory service products. Microsoft's Active Directory, Novell'sNovell Directory Service, and Netscape's Directory Server 3.0 are likelyto claim the majority of the market share, so taking a glimpse at these products is like taking a glimpse into the future of directory services.