LDAP and the Future of Directory Services, Part 2

AD includes subsets of several different communications protocols that X.500, LDAP 2, and LDAP 3 use. These protocols are part of a set of APIs called the Active Directory Service Interfaces (ADSI). ADSI creates interfaces between AD and other applications and directory services. These interfaces let AD communicate with the existing directories that both commercial and custom network applications use.

LDAP 2 includes a collection of low-level C-based APIs (defined in RFC 1823) that let you implement client access to an LDAP server. AD supports these APIs, but ADSI simplifies the programming tasks involved by providing COM-based APIs. Thus, you can use simpler programming and scripting languages, such as Visual Basic and Perl.

External providers, such as Kerberos and Secure Sockets Layer (SSL) 3.0, provide authentication and security for LDAP communications in AD. These external providers use a Security Support Provider Interface (SSPI) designed to permit the use of other compliant providers as they become available. ADSI also facilitates the creation and management of new directory service objects, using LDAP to create equivalent objects in other participating directories.

AD supports several different object-naming systems that let users use the notation they are most comfortable with to refer to directory objects. Apart from the distinguished names that LDAP and X.500 use, AD recognizes objects named using the RFC 1959 LDAP universal resource locator (URL) format, the RFC 822 Internet naming standard (e.g., john
smith@mycorp.com), and the universal naming convention (UNC) that is native to NT. Microsoft's AD strategy centers on the assumption that a network uses other directory services (such as Lotus Notes or NDS) at the application and operating system levels. This assumption is shrewd for two reasons. First, it puts Novell at a disadvantage. Although Novell has a more highly developed NDS directory and a gateway for LDAP access to that directory, Novell has done little to address the logistical issues involved in using that gateway for practical purposes. For example, you can use Netscape Communicator's and Microsoft Internet Explorer's (IE's) email applications to search for users' telephone numbers and email addresses in an NDS database. But little other functionality is readily available without custom programming--and Novell provides no help (i.e., libraries or documentation) to application developers in this area.

In contrast, Microsoft is concentrating on developing the tools needed to create applications that use AD's services and on adapting existing code to use the more flexible ADSI. If this strategy is successful, application developers will be able to use gateways for whatever purpose they desire. Microsoft's success will bring networks a giant step closer to the realization of a single, all-purpose directory service.

Another reason why Microsoft's assumption is shrewd is that it positions AD as a clearinghouse for existing network directory services. This approach is smart because no AD code is available (other than an alpha version that lacked many features and was limited to use with a single domain), and Microsoft doesn't expect an official release until mid-1998.

If AD lives up to its touted capabilities, it will function as a metadirectory for products, as shown in Figure 1. This ace in the hole could help Microsoft regain those users who chose another directory service solution because they were tired of waiting for Microsoft to release its product.

Netscape's Directory Server 3.0
Of the big three, Netscape has made the biggest commitment to LDAP 3 as a directory service standard. Netscape's Directory Server 3.0 uses an LDAP server as the basis for the directory service rather than as a gateway to a directory stored on another type of server.

Basing a product on draft standard is risky because modifications to the standard during the ratification process can easily cause the product to be orphaned. However, Netscape has hired LDAP's original team of designers from the University of Michigan to do the development work. Tim Howes, the inventor of LDAP and the co-chairman of the IETF working group responsible for LDAP 3, is leading the team.

Directory Server 3.0 contains many of the features proposed for LDAP 3, such as intelligent referrals, support for SSL and Simple Authentication and Security Layer (SASL) authentication, and extensible schema. The product can also interact with the NT 4.0 directory service architecture by synchronizing NT accounts with the LDAP directory or by using NT as an alternative authentication medium, in case an LDAP directory authentication fails.

Unlike NDS and AD, Directory Server 3.0 does not support multimaster replication. With multimaster replication, you can make changes to a particular entry on the nearest directory server. This server then propagates the changes to all the other servers. Instead of using multimaster replication, Directory Server uses a master/slave relationship in which you must make all modifications to a particular entry on that entry's master server. The master server then replicates changes to the individual slave servers, as shown in Figure 2.

Problems can arise from both processes. The most serious problem in multimaster replication is the conflict that can occur when two users at different locations attempt to modify the same directory entry at nearly the same time. NDS and AD devote considerable effort to avoid this problem. NDS synchronizes the clocks on its servers and applies timestamps to all directory communications, whereas AD uses update sequence numbers to identify its transactions.

Netscape avoids this problem entirely by using a master/slave relationship in Directory Server 3.0 but sacrifices an important element of scalability in the process. In addition, although the master/slave relationship prevents the directory from having to manage the more complex interserver relationships involved in the use of multiple masters, this relationship imposes significant delays when you must perform directory administration tasks from a remote location.

Directory Server 3.0 provides services to Netscape's SuiteSpot family of servers and the Netscape Communicator client. A software development kit is available to help develop custom LDAP client implementations. Like NDS, Directory Server 3.0 relies heavily on application developers and custom programming to provide services outside of the vendor's family of products. For example, before you can use Netscape's LDAP directory to authenticate users to your email application, you must wait until the email vendor provides an LDAP client or gateway between the two directories or you must create one yourself.

The Jury Is Still Out
You can't fairly assess these three directory service products yet because only one (NDS) has been officially released. In addition, Netscape, Microsoft, and Novell will certainly modify their products as LDAP 3 approaches completion.

Reaching the goal of having a single directory that can reliably support all network applications and services is still some years away, even with today's accelerated product cycles. Thus, you can't realistically assume that a new product, such as Directory Server 3.0 or AD, will suddenly be a panacea for all your directory service needs.

In the meantime, however, LDAP is useful as a gateway to directory information. It lets Internet and intranet users use a standard Web browser to access information. In addition, more full-featured LDAP clients, such as SWIX (see the sidebar "LDAP Clients and Directory Services," page 193) can give network administrators the ability to manage directory data from remote locations with the protection of authenticated access.