LDAP: The next-generation directory?
Lightweight Directory Access Protocol promises
good method for accessing different directories
October 1996
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
LDAP: The next-generation directory?
Lightweight Directory Access Protocol promises
|
October 1996
|
Despite all the progress in messaging, corporate directories are still a bit of a mess. On LANs, each e-mail system has its own directory, which is not interoperable with those of other vendors. On larger systems using TCP/IP, there's no single directory standard -- certainly not one that's routinely used on the scale of intranets. X.500, the CCITT standard for directories, offers promise for large-scale directories but is large and unwieldy to implement, plus its specifications call for use of the OSI protocol stack. Add to that the ungainly nature of X.500 addresses and user acceptance has been slow, at best.Although no single directory specification is likely to become the global standard, LDAP, or the Lightweight Directory Access Protocol, ties together various directories in a useful manner. (2,700 words)
 Mail this article to a friend |
Any directory service depends on what is known as a namespace, which provides for efficient referencing and retrieval of collections of related information, such as a person's name, organization, physical address, and e-mail address. In X.500, the namespace is explicitly stated and is hierarchical. Such namespaces require relatively complicated management schemes.
The naming model defined in X.500 is concerned mainly with the structure of the entries in the namespace, not the way the information is presented to the user. Every entry in a X.500 Directory Information Tree, or DIT, is a collection of attributes, each attribute composed of a type element and one or more value elements.
The X.500 standard defines 17 object classes for directories as a baseline. Being extensible, X.500 directories may include other objects defined by implementors. The 17 basic object classes include:
Objects in these object classes are defined by their attributes. Some of the basic 40 attribute types include:
Putting this all together, an unambiguous entry for an addressee would
be specified by its distinguished name, say
{C=US, O=Acme, OU=Sales, CN=Fred}
![[Example of X.500 hierarchy]](/sunworldonline/swol-10-1996/swol-10-ldap.1.gif)
Applications and users access the directory via a directory user agent, or DUA. A DUA transfers the directory request to a DSA, or Directory System Agent, via DAP, the Directory Access Protocol. The directory itself is composed of one or more DSAs. The DSAs can either communicate among themselves to share directory information or may perform what is called a referral, i.e., direct the DUA to use a specific DSA. Referrals may occur when DSAs are not set up to exchange directory information, perhaps due to lack of interworking agreements between the administrators, or for security reasons.
![[Directory example]](/sunworldonline/swol-10-1996/swol-10-ldap.2.gif)
X.500 is an application-level protocol. In a pure OSI environment, DAP uses the OSI stack to communicate over the network. But the complete OSI stack, including directory services, requires a great deal of memory and generates a great deal of operational overhead. It's far from ideal for implementation at the desktop, even on today's relatively high-powered hardware.
Enter LDAP. At the outset, the emphasis in LDAP was on the L, for lightweight. The idea was to create a protocol for accessing X.500 directories so that clients could run on desktop computers without dampening performance.
Initially, LDAP was designed so that a client using TCP/IP protocols interacts with a single LDAP server which, in turn, interacts with one or more X.500 servers via OSI protocols on behalf of the client. The first specifications for LDAP, as put forth in RFC 1487, a IETF Standard, did not provide for communications between LDAP servers, for server replication, or for industrial-strength security. It was, as the name implies, lightweight, depending on the X.500 protocols to handle maintenance of the directory tree and server updates, for instance. But it worked.
|
|
|
|
|
Capabilities of LDAP
Today, LDAPv2 is the Internet standard as defined by the IETF standards
process. The standards document, RFC 1777, dates back to March 1995. A
newer spec, LDAPv3, is currently a draft in review that is expected to soon
become a new standard, superseding RFC 1777.
Like X.500, LDAP bases its directory model on entries, where the distinguished name is used to refer to an entry without ambiguity. But rather than use the highly structured X.500 data encodings, LDAP adopts a simple, string-based approach for representing directory entries. This simplifies an application's requirement for processing directory entries, as the strings use a minimal subset of BER (Basic Encoding Rules). The full distinguished name format is described in RFC 1779.
Since LDAP entries generally are typed by an
objectclass attribute, searching an LDAP directory can be
simplified. For example, you could restrict searches of the directory
to entries whose objectclass=acl to locate only entries
that are supposed to be access control lists.
Some recent work has focused on integrating LDAP with Web access. The LDAP URL format, as specified in RFC 1959, makes it possible to contain search parameters for automatically filtering subsets of large directories. For example,
ldap://ldap.megacorp.com/ou=marketing,o=megacorp,c=us?one
will automatically filter down the directory tree to entries in the marketing department. Similarly,
ldap://ldap.megacorp.com/ou=marketing,o=megacorp,c=us?postalAddress?one
will return only the postalAddress attribute of the
matching entries.
But LDAP limits the ability of its clients to search an X.500 directory. With DAP, if a server finds several possible listings for a particular query, it sends them and lets the DAP client sort them out. If the directory server cannot satisfy a query, DAP allows it to initiate a search on another server or refer the inquiring client there. LDAP thus far has no provisions for such referrals, although they are part of the LDAPv3 specs.
On the security side, simple authentication -- use of a clear text password -- and Kerberos 4 are supported in versions 1 and 2 of LDAP. In the proposal for LDAP 3, support for strong authentication via X.509 is being added. Since LDAP can represent arbitrary attribute/value pairs as entries in the directory, this will enable LDAPv3-compliant servers to store user's public key in X.509v3. A draft IETF document currently in circulation explores how to store public PGP keys in an LDAP directory as well.
Masters, slaves, and stand-alone servers
Providing X.500-style directory access to clients running TCP/IP is a
real boon, but, as you might expect, using a single LDAP server/gateway
to large X.500 systems would inhibit good performance. Add to that the
complexity of maintaining X.500 directories and the desire to enhance
LDAP to support its own system of stand-alone, distributed directory
services grew.
That led to LDAPv2, in which LDAP servers could be designed to run independently of X.500 directories within a distributed directory topology, though one that's not as complex as that found in X.500. Now that stand-alone LDAP servers were possible, LDAP could be used to access X.500 directories, and LDAP and X.500 servers could interoperate.
In the LDAP scheme of things, slave servers are connected to master directory servers. Master servers have the capability of updating the subtree's directories located on the slaves. One difficulty with master servers as defined here is that a server cannot be both an internal tree participant and a slave to an external LDAP server. The scheme as currently implemented allows LDAP servers to serve the function of intranet-scale directories well, since you could set up a master server for each administrative division in a company and make all other servers lower in the hierarchy as slaves. But if you wish to share corporate directory info with outside sources, such as project partners, LDAP requires that you rely on other methods for replicating that directory information. furthermore, LDAP doesn't contain mechanisms for masters to learn about and communicate with each other automatically.
Much of this will change in version 3 and other proposed extensions. Although LDAP is defined as a replication protocol, it does support the the basic operations -- reading, writing, comparing, modifying, and deleting data -- required for creating and maintaining replicated servers. Although most companies have expressed their intentions to use LDAP as a directory browsing protocol, Netscape is the one company planning to utilize LDAP as a replication protocol as well.
Also, to handle failed queries, version 3 employs a referral capability that allows an LDAP server to refer a query to another server. The referral capability is also used to refer all write operations to the master server. LDAP does not, however, allow multiple trees (in other words, multiple master servers) to learn about each other and their contents automatically. The University of Michigan has been working on extensions to LDAP that would allow master servers to create indices of their contents and pass them on to other master servers. These so-called forwarding indexes would allow referrals to be made more dynamically.
The evolution of LDAP
As time goes on, LDAP is being converted from the original lightweight
access protocol to more of a middleweight directory protocol. Although
much of the impetus for these modifications originally came from the
LDAP development team at the University of Michigan, some of that
effort has been assumed by Netscape, since it hired three members of the original
LDAP team.
Some of the extensions being driven by Netscape (in addition to replication, mentioned earlier) include running LDAP over the SSL (Secure Sockets Layer) protocol and support for access control lists. Implementing LDAP over SSL will enable used authentication, data encryption, and data integrity protection so files cannot be changed after they are transmitted. In the case of access control lists, Netscape needed to include such functionality for proper administration of its server line.
Another focus of attention has been on formats for directory interchange. Drafts are circulating through the IETF for a MIME-based application/directory content-type representation, which is what Netscape plans to support in its Directory Server, but that format has not yet been widely accepted in the industry. Another proposal, Versit's vCard format, is also circulating through the IETF and appears to have more support.
Conclusions
The built-in extensibility of the LDAP architecture makes it
easier to modify the protocol for new situations and needs. But be wary
of a single vendor "calling the shots" for protocol extensions. For
instance, Netscape has been actively plotting extensions to LDAP,
including replication as mentioned previously. These extensions are
likely to create some nervousness among managers and users who
understand the need to add functionality but also want to make sure
that all LDAP implementations work together.
When you're making a checklist for an LDAP server, be sure to determine how the vendor plans support for LDAP as a replication protocol between servers, version 3 of the protocol, and Netscape's extensions beyond version 3. Each of these issues will be important options for determining interoperability among LDAP systems.
LDAP is not the ultimate directory protocol. Even as it grows to
include stand-alone and replicated servers, LDAP should be thought of
as a good method for accessing information from a variety of
directories. With so many vendors (Lotus, IBM, Novell, and Microsoft,
for example) adding support for LDAP in their directories, LDAP has a
good chance of being the glue that ties together all of the information
found in these directories for use on intranets. But if you're looking
to combine disparate directory information with different schemas into
a single meta-directory, you'll have to wait for other protocols or
products.
|
|
Resources
About the author
Dave Kosiur, Ph.D., is an independent networking consultant and freelance writer. He has published two books on networking, including The Macworld Networking Bible ( IDG Books), which won a Computer Press Association award in 1995. He's now concentrating on electronic commerce, e-mail and security issues, as well as the World Wide Web (isn't everyone?).
Reach Dave at dave.kosiur@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright96.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-10-1996/swol-10-ldap.html
Last modified: