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.