The whole point of using a directory service is to create a single repository for all your network's authentication and configuration data and to control both users' and applications' access to that repository. To create a single repository that provides access to services, file servers, databases, and other applications, you need a communications link between the directory service and proprietary applications. Lightweight Directory Access Protocol (LDAP) provides this link.

As part 1 of this article explained, LDAP has progressed from a TCP/IP-based X.500 directory access solution to its current status as a potential industry standard for directory service communications (see my article "LDAP and the Future of Directory Services, Part 1," October 1997). Currently, the Internet Engineering Task Force (IETF) is working on LDAP 3. (The most recent rewrite is LDAP 3.3. To keep abreast of developments, check the University of Michigan's LDAP Web site at http://www.umich.edu/~rsug/ldap/ldap.html.) LDAP 3 defines additional features that will let the protocol more effectively communicate with different directory services.

Although LDAP 3 is still in development, the big three in the networking industry--Netscape, Novell, and Microsoft--have already committed to its use for their individual directory service products. This second installment of this two-part series examines how these vendors are implementing LDAP in their directory service solutions, each of which is at a different stage of development. Comparing these three LDAP implementations--Novell's LDAP Services for Novell Directory Services (NDS), Netscape's Directory Server 3.0, and Windows NT 5.0 Active Directory (AD)--demonstrates the protocol's flexibility in different environments and provides additional insight into the directory services.

Novell Directory Services and LDAP
Novell has a considerable advantage over Netscape and Microsoft because its directory service solution has been on the market since 1993. This product was originally called NetWare Directory Services because Novell designed it to store information about NetWare resources. Novell expanded its utility, however, so that it would store information about the entire enterprise network. To reflect this expansion, Novell changed the name to Novell Directory Services in 1996.

Novell largely based NDS on the X.500 directory standard. NDS uses the same organizational principles, many of the same object classes, and a slightly altered namespace. Like X.500, NDS is a distributed directory that lets users see data stored on multiple servers as a unified set.

NDS differs from X.500 in one important respect, however. The communication between the servers follows the NetWare Core Protocol. NCP uses Novell's proprietary IPX protocol for its network layer services.

As part of the effort to expand NDS's functionality beyond the NetWare operating system, Novell has released versions that run on UNIX and promises an NT version before the year end. At this time, however, NetWare servers most often host the directory service. With NetWare servers, you can use Novell Administrator for Windows NT to replicate NT domain user information into an NDS tree. (For more information about this product, see my article "NAdminNT Brings NT Domains and NDS Together," July 1997.)

Using LDAP Services for NDS
Because of the extensive period of development, deployment, and real-world directory service experience, Novell's adaptation of NDS to use LDAP was a relatively small task compared to Netscape's and Microsoft's efforts. In late 1996, Novell released its LDAP Services for NDS, a NetWare loadable module (NLM) that publishes NDS data to LDAP clients on the Internet or an intranet.

NLM uses LDAP 2, which the IETF publishes as Request for Comments (RFC) 1777. Clients can use NLM to access any information stored in an NDS directory, but they can't access non-X.500 directories.

To overcome this disadvantage, NLM adds manual mapping functions to the NDS database. Novell bases NDS on the X.500 standard, but NDS's directory schema specifies different names for certain objects and attributes, even when the objects and attributes perform the same function as those in X.500. Therefore, you must reconcile these names for the LDAP server module to effectively communicate with NDS. For this purpose, Novell includes object class and attribute mapping functions in the LDAP Services for NDS configuration screens. (In the future, LDAP 3 will let a directory publish its schema as part of the communications process.)

Letting network administrators manually map NDS object classes and attributes to specific LDAP equivalents, as shown in Screen 1, provides two important advantages. First, you can extend the directory schema. If an application has new NDS object classes or if existing object classes have new attributes, you can make these new elements available to LDAP clients. Conversely, you can use manual mapping to limit the objects and attributes available to LDAP clients. For example, suppose you want to let customers use an LDAP client over the Internet to access employee telephone numbers and email addresses stored in a directory, but you want to prevent them from seeing confidential object information. By mapping only selected attributes, you control the information available to LDAP clients without the need for authentication.

The second important advantage is that LDAP Services for NDS provides access control. NDS security operates at the server level by letting users bind to the directory either with their standard NDS user names or anonymously with a proxy user account (a single access account that all users share). If users bind to the directory with their standard NDS user name, the passwords are not encrypted. To remedy this problem, you can use LDAP's access control lists (ACLs) to restrict access to the directory at the client level. ACLs let you specify the level of access you want to give specific users. As Screen 2 shows, you can grant access to specific objects and attributes.

Although Novell intends to upgrade its support for LDAP when IETF ratifies the new version, the primary advantage of NDS and the LDAP Service for NDS is that they are available now. Netscape and Microsoft are relying on new technologies that have yet to undergo the ultimate testing of real-world use.

NT 5.0's AD and LDAP
One of the greatest stumbling blocks to the growth of NT as a network operating system (NOS) has been the lack of an enterprise directory service. Microsoft designed the trusted domain model currently in use for workgroup and departmental computing. The model lacks the features (such as object hierarchy, extensible schema, and a data distribution strategy) that would make it adequate for large networks. Microsoft has promised a more effective directory service since it first announced Cairo in 1993, but the company doesn't expect to release this product (AD) until 1998 as part of NT 5.0.

Microsoft's new directory service, AD, uses Domain Name System (DNS) locating technology, X.500 object naming, and LDAP communications. In an AD implementation, the individual domains that formed the original NT directory service will become DNS domains that are interconnected in a domain tree that unifies the entire network.

Communication is an essential part of the AD strategy. One of the directory service's most important features is its ability to subsume and manage other directory services running on the same network. This feature lets you use the information stored in the AD to authenticate user access to applications, such as Lotus Notes, that maintain their own directories. You can also replicate object data from other NOS-based directory services (e.g., NDS) and use AD tools to manage that data.

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.