As an enterprise network expands from a file-and-print platform to a platform that includes email systems, databases, Web servers, and other applications and services, the need for a universal directory service becomes increasingly apparent. The big three in the networking industry--Novell, Netscape, and Microsoft--are trying to meet this need by developing the definitive directory service solution. Although their solutions are in different stages of development and use different methodologies, all three have committed to using the Lightweight Directory Access Protocol (LDAP) in their directory service products.
How Novell, Microsoft, and Netscape are using LDAP in their directory service 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 to understand LDAP's function, ancestry, birth, and evolution.
Why You Need LDAP
In a typical business network, employees need access to different services
and 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 in
a basic network, employees need access to several protected services on several
platforms. Therefore, businesses need a single directory service that can
provide authenticated access to all of these resources. This directory service
needs to do much more than provide usernames and passwords. It needs to
effectively store many different types of data (such as client contact
information, application configuration data, and personal documents) in a
central location. The directory service also needs to give employees the ability
to access that database from any workstation on the network or from a remote
location.
The main obstacle to developing such a directory service is that many business network services and applications have proprietary user directories. Because the data in proprietary directories cannot be applied to other applications, network administrators must create separate accounts for the various services and applications. Creating separate accounts not only generates additional work, but also makes the task of changing passwords a nightmare.
To create a single user account that provides access to services, file servers, databases, and other applications, you need a communications link between the directory service and proprietary applications. LDAP provides this link.
Meet LDAP's Ancestors
Researchers at the University of Michigan, with support from the National
Science Foundation, originally developed LDAP as a simplified means for clients
to access X.500 directory servers. X.500 is the International Telecommunications
Union (ITU) standard that defines the basic structure and functionality of a
directory service model. According to X.500, a directory service includes five
elements.
1. A directory service has a model that defines the basic structure in which information is stored. A directory service consists of entries, attributes, and values.
Entries represent elements in the directory service. For example, if a directory service has 20 network users, 2 directory shares, and a shared printer, the model would include one entry for each element, giving a total of 23 entries.
Each entry contains attributes. Attributes represent the properties that the directory service needs to classify the entry. For example, the attributes for the entry of network user might be the user surname and the user email address.
Each attribute contains values. Values are the representation of attributes. For example, the value for the attribute of user email address might be [email protected].
2. A directory service has a tree-like hierarchy, called a directory information tree. The DIT stores the directory's entries and uses namespaces to uniquely identify every entry's exact place in the tree. At the top of the tree, you use geographical constructs (i.e., two-letter country identifiers) to determine the hierarchy of entries. As you proceed downward, you use more arbitrary organizational constructs (e.g., departments) to determine the hierarchy of entries. An entry's distinguished name (DN) traces the entry's path in the tree, much like a pathname defines the location of a file in a file system tree. (To see an illustration of a DIT and a DN, see "How to Name and Place Objects in the Directory Information Tree.")
3. A directory service has a collection of command functions that clients can use to manipulate directory entries. These command functions include Read, List, Search, Add, Delete, Modify, and Bind (brings two elements together as a unit).
4. A directory service has a system to authenticate users. The directory service must authenticate users before granting them access to the directory. You can use any of several different authentication methods, including a simple password option and the Kerberos network authentication service.
5. A directory service has a distribution model that lets clients (called directory user agents) view the data stored on multiple servers (called directory system agents) as a single entity. If a server receives a request for data that is stored elsewhere, it passes the request to the appropriate server using one of two methods: chaining or referral.
Chaining is the process by which an X.500 server, after receiving a client's request that it cannot satisfy, sends an identical request to another server. If the second server cannot satisfy the request, it passes the request to a third server. The servers continue this process until the request reaches a server that can respond to it. The response then follows the same route back to the original client, as shown in Figure 1.
Alternatively, a server can respond to a request that it cannot satisfy by supplying the requester with a referral. The referral identifies the server that contains the requested data. The requester, which can be the original client or one of the interim servers, then sends a new request directly to the correct server, as shown in Figure 2.
Novell, Netscape, and Microsoft created their directory service products based on these X.500 specifications. The big three are not the only companies taking advantage of these specs. Many other organizations use them, but for a different purpose. For example, organizations use X.500 specs to build white-page directories.
From the outset, white-page directories have had the potential to store many types of information other than phone numbers and email addresses. But this potential remains largely untapped because of problems with providing client access to the directory server.
Congratulations, It's a Protocol
X.500 states that the Directory Access Protocol (DAP) is the protocol to use
when connecting client systems to the directory server. But DAP requires that
clients use the Open Systems Interconnect (OSI) protocol stack as well as
significant amounts of memory and other system resources. So the University of
Michigan designed LDAP as a subset of DAP. LDAP eliminates much of DAP's
seldom-used functionality. In addition, unlike DAP, LDAP runs over a standard
client TCP/IP connection.
The Internet Engineering Task Force (IETF) defines the current version of LDAP (LDAP 2) in Request for Comments (RFC) 1777 and RFC 1778. LDAP 2, which contains more specifications than most protocols, describes how a client and a server can exchange X.500-based messages.
In the exchange process, the LDAP client uses a TCP connection to send requests to an LDAP server. As Figure 3 shows, the server then uses OSI communications to perform the requested activities on the X.500 directory. The LDAP server can be a separate application that uses an LDAP gateway to communicate with an X.500 server, or it can be part of an X.500 server implementation.
Here is how LDAP systems differ from X.500 systems. LDAP servers use the same directory service structure and namespaces as X.500 servers, but LDAP servers use fewer command functions to provide roughly the same level of functionality. For example, an X.500 server has Read and List commands, while an LDAP 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 have only two options: plain-text password and version 4 of the Kerberos network authentication service.
Unlike an X.500 client, an LDAP client does not participate in the referral process. Instead the LDAP server processes referrals and regenerates requests. The only communications that an LDAP client can receive from a server are the responses to its requests and error messages explaining a server's failure to fulfill a request.
LDAP servers reduce the burden of the directory service client by simplifying the encoding process used to transmit the distinguished names of directory 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/IP
connection, access to X.500 data is no longer limited to OSI clients on
intranets. Clients can use the Internet to access private X.500 directories, a
process that has come to be known as extranetting. Extranetting has led to the
first widespread implementation of LDAP clients, which took the form of address
books for the email applications in Netscape Communicator and Microsoft Internet
Explorer (IE).
Both Communicator and IE let users search for email and telephone addresses in private directories on a local network. In addition, as Screen 1 shows, users can search for email and telephone addresses in Internet white pages that use LDAP servers such as Four11 and Bigfoot. Communicator and IE serve as a model for future application development because these services use an LDAP-client module rather than a proprietary authentication directory.
Netscape used LDAP in another innovative application. To facilitate the use of LDAP over the Internet, RFC 1959 defines a universal resource locator (URL) format that provides direct access to LDAP servers through a browser application. This format includes a new LDAP prefix to replace the HTTP commonly seen 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 email address attribute for all of the objects in the US sales department of the given company. As of this writing, the Netscape Navigator in the Netscape Communicator 4.0 Preview Release 3 is the only browser that supports LDAP URLs.
The potential of LDAP goes beyond access to X.500 directories. Even with LDAP largely replacing DAP for client/server communications, X.500 is a difficult directory to install and maintain, making it impractical for use as an intranet directory service, except in large organizations. So major software vendors are trying to use LDAP servers to communicate with other directory services 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 been mostly unsuccessful. This fact isn't surprising, however, given that RFC 1777 states LDAP 2 is designed to provide access to the X.500 directory. For this reason, work is proceeding on LDAP 3. The current draft specification describes LDAP 3 as being designed to provide access to directories supporting the X.500 model and not necessarily to the X.500 directory itself.
This revision is a critical step in the evolution of the protocol. Many different parties, especially Microsoft, Novell, and Netscape, want to see LDAP developed in ways that best suit their needs. But for the good of the networking industry, partisan interests must not affect the future of the standard.
One primary improvement planned in LDAP 3 is the protocol's ability to modify a directory's structure to accommodate the requirements of specific applications. This modification would involve altering the directory's schema. The schema is a set of rules that governs the nature of a directory entry, its attributes, and the syntax of the attributes' values.
Modifying a directory's schema is not terribly difficult. The problem arises when directories with different schema must communicate with each other. LDAP 2 doesn't address this problem because the LDAP server was expected to always be communicating with an X.500 directory.
To solve incompatible schema problems, several different groups are working to develop standard schema. The groups will face many challenges. Not only do they have to develop a single standard, but they also have to rewrite existing applications using the new schema.
The LDAP 3 draft specification calls for a different, more universal solution to incompatible schema: the use of specialized subschema entries. With subschema entries, people could publish the details of a directory's schema and share those details with another directory. An exchange of schema information would occur before two directories begin to communicate.
The LDAP 3 draft specification proposes other major improvements, such as better support for user authentication. Instead of offering the option of plain-text passwords (which isn't an option if you want a secure network), the LDAP 3 draft promotes the use of the Secure Sockets Layer (SSL) standard, which is commonly used for Internet communications, and a new mechanism called the Simple Authentication and Security Layer (SASL). With SSL and SASL, people will have a real security alternative if they don't want to implement a third-party authentication service, such as Kerberos. Other proposed LDAP improvements include support for international character sets, type-down addressing (which lets search engines narrow their selection as each letter of a query is entered), LDAP server ability to return referrals to a client, and the delivery of search results in individual pages.
Many improvements proposed in the LDAP 3 draft specification are pushing the protocol away from being properly labeled as lightweight. However, when you compare LDAP 3 to X.500, the label remains appropriate. In addition, as the LDAP 3 draft specification approaches the point at which it enters the standards track of the IETF review and development process, some of these features will likely be removed to streamline the protocol.
Look for Part 2
Now that you know about LDAP's function, ancestry, birth, and evolution, you
are ready to explore how Microsoft, Novell, and Netscape are implementing LDAP
in their directory service products. Microsoft's Active Directory, Novell's
Novell Directory Service, and Netscape's Directory Server 3.0 are likely
to 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.
