LDAP and the Future of Directory Services, Part 2

LDAP 3 is still in development, but Netscape, Novell, and Microsoft have already committed to its use

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 asingle repository that provides access to services, file servers, databases, andother applications, you need a communications link between the directory serviceand proprietary applications. Lightweight Directory Access Protocol (LDAP)provides this link.

As part 1 of this article explained, LDAP has progressed from aTCP/IP-based X.500 directory access solution to its current status as apotential 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. (Themost recent rewrite is LDAP 3.3. To keep abreast of developments, check theUniversity of Michigan's LDAP Web site athttp://www.umich.edu/~rsug/ldap/ldap.html.) LDAP 3 defines additional featuresthat will let the protocol more effectively communicate with different directoryservices.

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

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

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

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

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

Using LDAP Services for NDS
Because of the extensive period of development, deployment, and real-worlddirectory service experience, Novell's adaptation of NDS to use LDAP was arelatively small task compared to Netscape's and Microsoft's efforts. In late1996, 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 NDSdatabase. Novell bases NDS on the X.500 standard, but NDS's directory schemaspecifies different names for certain objects and attributes, even when theobjects and attributes perform the same function as those in X.500. Therefore,you must reconcile these names for the LDAP server module to effectivelycommunicate with NDS. For this purpose, Novell includes object class andattribute 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 thecommunications process.)

Letting network administrators manually map NDS object classes andattributes to specific LDAP equivalents, as shown in Screen 1, provides twoimportant advantages. First, you can extend the directory schema. If anapplication has new NDS object classes or if existing object classes have newattributes, you can make these new elements available to LDAP clients.Conversely, you can use manual mapping to limit the objects and attributesavailable to LDAP clients. For example, suppose you want to let customers use anLDAP client over the Internet to access employee telephone numbers and emailaddresses stored in a directory, but you want to prevent them from seeingconfidential object information. By mapping only selected attributes, youcontrol the information available to LDAP clients without the need forauthentication.

The second important advantage is that LDAP Services for NDS providesaccess control. NDS security operates at the server level by letting users bindto the directory either with their standard NDS user names or anonymously with aproxy user account (a single access account that all users share). If users bindto the directory with their standard NDS user name, the passwords are notencrypted. 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 youspecify 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 ratifiesthe new version, the primary advantage of NDS and the LDAP Service for NDS isthat they are available now. Netscape and Microsoft are relying on newtechnologies 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 networkoperating system (NOS) has been the lack of an enterprise directory service.Microsoft designed the trusted domain model currently in use for workgroup anddepartmental computing. The model lacks the features (such as object hierarchy,extensible schema, and a data distribution strategy) that would make it adequatefor large networks. Microsoft has promised a more effective directory servicesince it first announced Cairo in 1993, but the company doesn't expect torelease 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 ADimplementation, the individual domains that formed the original NT directoryservice will become DNS domains that are interconnected in a domain tree thatunifies the entire network.

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

AD includes subsets of several different communications protocols thatX.500, LDAP 2, and LDAP 3 use. These protocols are part of a set of APIs calledthe Active Directory Service Interfaces (ADSI). ADSI creates interfaces betweenAD and other applications and directory services. These interfaces let ADcommunicate with the existing directories that both commercial and customnetwork applications use.

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

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

AD supports several different object-naming systems that let users use thenotation they are most comfortable with to refer to directory objects. Apartfrom the distinguished names that LDAP and X.500 use, AD recognizes objectsnamed using the RFC 1959 LDAP universal resource locator (URL) format, the RFC822 Internet naming standard (e.g., john
[email protected]), and theuniversal naming convention (UNC) that is native to NT. Microsoft's AD strategycenters on the assumption that a network uses other directory services (such asLotus Notes or NDS) at the application and operating system levels. Thisassumption 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 LDAPaccess to that directory, Novell has done little to address the logisticalissues involved in using that gateway for practical purposes. For example, youcan use Netscape Communicator's and Microsoft Internet Explorer's (IE's) emailapplications to search for users' telephone numbers and email addresses in anNDS database. But little other functionality is readily available without customprogramming--and Novell provides no help (i.e., libraries or documentation) toapplication developers in this area.

In contrast, Microsoft is concentrating on developing the tools needed tocreate applications that use AD's services and on adapting existing code to usethe more flexible ADSI. If this strategy is successful, application developerswill be able to use gateways for whatever purpose they desire. Microsoft'ssuccess 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 ADas a clearinghouse for existing network directory services. This approach issmart because no AD code is available (other than an alpha version that lackedmany features and was limited to use with a single domain), and Microsoftdoesn't expect an official release until mid-1998.

If AD lives up to its touted capabilities, it will function as ametadirectory for products, as shown in Figure 1. This ace in the hole couldhelp Microsoft regain those users who chose another directory service solutionbecause 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 adirectory service standard. Netscape's Directory Server 3.0 uses an LDAP serveras the basis for the directory service rather than as a gateway to a directorystored on another type of server.

Basing a product on draft standard is risky because modifications to thestandard during the ratification process can easily cause the product to beorphaned. However, Netscape has hired LDAP's original team of designers from theUniversity of Michigan to do the development work. Tim Howes, the inventor ofLDAP and the co-chairman of the IETF working group responsible for LDAP 3, isleading 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 andSecurity Layer (SASL) authentication, and extensible schema. The product canalso interact with the NT 4.0 directory service architecture by synchronizing NTaccounts with the LDAP directory or by using NT as an alternative authenticationmedium, in case an LDAP directory authentication fails.

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

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

Netscape avoids this problem entirely by using a master/slave relationshipin Directory Server 3.0 but sacrifices an important element ofscalability in the process. In addition, although the master/slave relationshipprevents the directory from having to manage the more complex interserverrelationships involved in the use of multiple masters, this relationship imposessignificant delays when you must perform directory administration tasks from aremote location.

Directory Server 3.0 provides services to Netscape's SuiteSpot family ofservers and the Netscape Communicator client. A software development kit isavailable to help develop custom LDAP client implementations. Like NDS,Directory Server 3.0 relies heavily on application developers and customprogramming to provide services outside of the vendor's family of products. Forexample, before you can use Netscape's LDAP directory to authenticate users toyour email application, you must wait until the email vendor provides an LDAPclient 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 becauseonly 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 supportall network applications and services is still some years away, even withtoday's accelerated product cycles. Thus, you can't realistically assume that anew product, such as Directory Server 3.0 or AD, will suddenly be a panacea forall your directory service needs.

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