LDAP and the Future of Directory Services, Part 2

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.

   Previous  [1]  2  Next