Exploring Netscape's Directory Server 3.0

New features expand its capabilities

Netscape was the first company to deliver a commercial Lightweight Directory Access Protocol (LDAP) directory server, Directory Server 1.0. Netscape recently released version 3.0, which supports LDAP 3 (in Request for Comments--RFC 2251). Directory Server 3.0 provides new features that expand Directory Server's capabilities. Although Netscape doesn't call Directory Server a metadirectory product, you can set up a limited metadirectory for NT networks running Netscape Internet and intranet services.

What the Netscape Directory Server Is and Is Not
Directory Server 3.0 is not an operating-system directory, such as Windows NT 5.0's Active Directory (AD). Nor is it an application directory, such as a directory in Microsoft Exchange Server. Rather, Directory Server is a general-purpose LDAP directory that stores, publishes, and centrally manages user, group, and other network information in one directory on your network.

For purposes of setting up a metadirectory, Directory Server 3.0 is the most powerful, yet the least useful, of all the metadirectory products discussed in this issue of Windows NT Magazine. The primary function of Directory Server 3.0 is to provide directory services for the Netscape SuiteSpot servers. As a result, very few third-party applications can use Directory Server's LDAP directory out of the box. You can, however, configure your network so that LDAP-enabled applications and clients use Directory Server's LDAP directory. Such configurations can eliminate the need for separate user databases. To provide extensibility of a single directory database for your enterprise, Directory Server lets you use a relational database management system (such as Oracle, Informix, or Sybase) to store directory information instead of its native database.

Directory Server 3.0 has improved features and added several new ones. But before you can take advantage of these features, you need to design, build, and know how to manage this directory service.

Planning and Setting Up Your Directory Service
According to Netscape, spending several months planning a directory service is common. Your plans must include how you will integrate Directory Server into your NT network and what your directory will contain. (For a complete list of what you need to plan for, see Netscape's Web site at http://home.netscape.com/eng/server/directory/3.0/deploy/contents.html.)

Integrating Directory Server into your network. Directory Server 3.0 runs on NT Server 4.0 and 3.51 and on several UNIX platforms. Figure 1 shows an example of how you might set up Directory Server in an NT network. You can install a directory server, which contains your company's LDAP directory, in the center of your network. You can install another directory server that keeps a backup copy of the directory tree and provides high-availability and good response time for local users. This setup is similar to using a Backup Domain Controller (BDC) for the Primary Domain Controller (PDC) in the NT domain. A BDC is not shown in Figure 1, because Directory Server synchronizes only with the PDC. But not showing a BDC doesn't mean that you don't need one for your NT network. You need a BDC to get updates from the PDC.

Directory Server for NT can synchronize the LDAP directory with the NT domain directory on the PDC, so you can manage user accounts in one place. If you use a Netscape SuiteSpot server, such as Messaging Server or an LDAP-enabled application, the application server can authenticate users through Directory Server for application access. Directory Server also lets an LDAP client, such as Netscape's Directory Server Gateway, update and search LDAP directory information.

Determining the contents of your directory. You need to determine the data you want to keep in your directory, how you will represent that data in the directory, and where the data will be located. This information will help you design your directory information tree (DIT). A DIT is a map of a directory's contents. Because the DIT follows the hierarchy that most computer file systems use (the root entry at the top and leaf entries at the bottom), it resembles an inverted tree.

A DIT often mirrors a company's organizational hierarchy. For example, Figure 2 shows a directory tree for Acme, a fictitious company consisting of three organizational units (ous): Administration, Sales, and Products.

When designing a DIT, you categorize directory entries into classes of objects. As Figure 2 shows, common object classes include organization (o), ou, and person (common name--cn). The object class specifies the required and optional attributes of the objects in that category and the rules governing how you can use the object when building the DIT structure. For example, the common-name object class might have the person's business phone number as a required attribute and the person's home phone number as an optional attribute. The object class also specifies that common-name objects must be contained by (or subordinate to) an organization or organizational unit object. (You can find more information about objects, attributes, and DITs at the University of Michigan's Web site at http://www.umich.edu/~dirsvcs/ldap/index.html and at Critical Angle's Web site at http://www.critical-angle.com/ldapworld.)

Building and Managing the LDAP Directory
Once you have installed and configured Directory Server in your network, it's time to build the directory following your design. Directory Server provides three administrative tools--Directory Server Gateway, Directory Server Manager, and command-line utilities--that let you build and manage the LDAP directory.

Directory Server Gateway. To use this browser-based administrative tool, you must be running Netscape Web server (Enterprise Server or FastTrack Server). Directory Server's LDAP directory schema provides more than 60 object classes and more than 270 attribute types to build a directory with. Directory Server also supports the X.500 directory schema and the Network Applications Consortium's Lightweight Internet Person Schema. (For more information about the relationship between LDAP and X.500, see the sidebar "The Evolution of LDAP.")

In the default configuration, the Directory Server Gateway includes only commonly used object classes and attributes. If the default configuration meets your needs, the Directory Server Gateway is easy to use. However, if you want to include other objects or attributes, you must customize Directory Server Gateway's HTML files. This task requires a thorough understanding of LDAP objects and attributes.

Directory Server Manager. With this powerful administrative tool, you can manage all Directory Server components, including the LDAP directory database, the access control list (ACL), replication, the schema, and all directory server settings. Directory Server Manager is a Web-based tool, but only a server administrator can connect to its interface.

Directory Server Manager has several tools that help you build and manage the LDAP directory database. For example, to build the database, you can use its Add Entries tool, as Screen 1, page 140, shows. This tool uses LDAP Data Interchange Format (LDIF) files (files that express directory entries in a simple, understandable text format) to extend the database. This method of adding directory entries is easier than working with HTML files.

To manage the database, you can use Directory Server Manager's Export and Import tools. Using these tools, you can export the database to an LDIF file, view the entire directory in a text format, and transfer information from one directory to another. The LDIF file can serve as a backup of the directory.

Command-line utilities. Directory Server supplies five command-line utilities: ldapadd, ldapdelete, ldapmodify, ldapmodrdn, and ldapsearch. These utilities let you conduct several LDAP operations, such as add, delete, modify, and search entries in a directory. For example, you can use the command

ldapadd ­h ldap.acme.com ­p 389 ­D "cn=admin,o=acme.com" ­w password ­f e:entries.txt

to log on to the LDAP server ldap.acme.com at TCP port 389 as an administrator and add the entries in the entries.txt LDIF file to the server's directory.

Once you have designed and built the directory service and you know how to manage it, you are ready to take advantage of Directory Server's features. These features let you synchronize your network, protect your data, replicate your directory, speed up your searches, and make intelligent referrals.

Synchronizing the LDAP Directory with NT
An improved feature in Directory Server 3.0 is the Directory Synchronization Service for NT. This synchronization tool is good news for companies that want to standardize NT as their network and desktop operating system (OS) and use Netscape products for their intranet platform. With this service, you can perform two-way synchronization of users, groups, and passwords between the LDAP directory and the NT domain directory. However, you aren't required to synchronize the directories in both directions. If you want to use the LDAP directory as your single point of administration for user accounts, you can perform one-way replications from the Directory Server database to the NT domain directory.

Directory Synchronization Service runs as a service on an NT 4.0 or 3.51 PDC. The service doesn't work on a BDC. However, you can install it on a BDC so that, if your PDC fails, you can start the service right after promoting the BDC to PDC. The service synchronizes one Directory Server's subtree with one NT domain. If you have multiple subtrees in the LDAP directory, you can synchronize each subtree with an individual NT domain. For example, Acme's NT network needs three NT user-account domains, each of which corresponds to an organizational unit (Admin, Sales, and Products) listed in the LDAP directory in Figure 2.

The synchronization service monitors changes in the NT account database. When you add, remove, or edit a user or group in the NT domain, the service will create, delete, or modify the same user or group in the LDAP directory. You can schedule the synchronization to occur at specific intervals (e.g., every 10 minutes). However, when you update the LDAP directory, the synchronization service immediately updates the NT domain.

To use the synchronization service, you need to use Directory Server Manager to enable the Directory Server's Directory Synchronization Service plug-in. You must also include NT-specific object classes and attributes in the LDAP directory's user entries. The service uses an LDAP-over-Secure Sockets Layer (SSL) operation for NT-to-Directory Server synchronization and an encrypted TCP-based, non-LDAP operation for Directory Server-to-NT synchronization. Therefore, directory information (such as usernames and passwords), are encrypted when they are transferred between Directory Server and the PDC.

The NT server running Directory Server doesn't need to be in the same domain as the PDC or in a domain with a trust relationship with the PDC's domain. However, if Directory Server and the PDC are in the same domain or the directory server's domain trusts the PDC's domain, Directory Server will attempt to authenticate users through NT authentication if the user's password doesn't match the password in the LDAP directory.

If the Directory Server is not in the same NT domain as the PDC and there is no trust relationship between those domains, how does Directory Server access and synchronize with the PDC? Directory Server communicates with the directory synchronization service running on PDC through a TCP operation, which doesn't require an NT trust relationship. When the directory synchronization service on the PDC finds changes in the Security Accounts Manager (SAM) at a preset interval, the directory synchronization service sends the updates to Directory Server through that TCP session. When Directory Server sends changes to the directory synchronization service on PDC, the service updates the SAM. However, for Directory Server to authenticate a user through an NT domain, it has to use the NT domain's authentication operation, which requires a trust relationship.

Protecting Your Directory
Another important enhancement in Directory Server 3.0 is in its security features, including its support for LDAP over SSL. The enhanced authentication and encryption processes protect your directory and network.

With Directory Server, you can control not only who can access the directory, but what they can access. To control who has access, you use the ACL to assign rights (including add, compare, read, write, and search rights) to users or groups. To control what users can access, you can give users the right to modify certain attributes of their entries by granting rights to the entity self. (This procedure is easier than granting each user individual rights to attributes.)

In addition, a separate security feature lets administrators limit the directory access of a particular user by requiring that the connection be made from a machine with a specific IP address. This feature prevents spoofing.

When an LDAP-enabled application needs to authenticate a user, it simply uses the LDAP directory to verify the username and password. (LDAP-enabled applications share the LDAP directory.)

When an LDAP client needs to access the LDAP directory, the client submits a username and password to the directory server, which verifies the username and password before the client can log on to the directory. Directory authentication in LDAP parlance is a bind.

In some cases, you might want to let anyone access the LDAP directory. For example, you might want to use the directory to publish a white-pages directory on the Internet. You can let anyone access the directory by enabling anonymous access. With anonymous access, Directory Server does not carry out the authentication process.

If you need to secure directory information being transferred over the network, you can enable LDAP over SSL in Directory Server. With LDAP over SSL, the server authenticates clients via X.509 certificates, and the server and the client use public keys to encrypt the data they are exchanging. For example, Directory Synchronization Service for NT uses LDAP over SSL to protect NT accounts being transferred over the network during NT-to-Directory Server synchronization.

Directory Server permits simultaneous SSL and non-SSL communication, which means that a regular LDAP client can still access the server with a regular username and password, even after you enable SSL in the server. By default, Directory Server uses TCP port 636 for LDAP-over-SSL communication and TCP port 389 for regular LDAP communication.

As long as you have the synchronization function enabled, the passwords of NT domain user accounts are replicated to the LDAP server (and vice versa). This process is secure because the passwords are encrypted.

Replicating the Directory
Directory Services uses LDAP for replication, so you don't need to integrate any other protocol. Because LDAP has its roots in X.500, Directory Server uses the X.500 single-master replication model for replication. (This model is not X.500's more complex Directory Information Shadowing Protocol--DISP.)

In single-master replication, the single-master server storing the original directory database replicates the entire directory or subtrees to one or more slave servers. A slave server stores a read-only copy of the replicated information (i.e., a replica).

Netscape refers to the master server as the supplier server and the slave server as the consumer server. You make all changes to directory entries on the master server and then configure replication by defining a replication agreement between the supplier and consumer servers. The supplier server initiates replication by pushing changes to the consumer server, or the consumer server initiates replication by pulling changes from the supplier server. The supplier server records directory changes in a change log. The replication-initiating server checks this log at preset intervals. When it finds a change, a replication operation occurs.

Directory replication offers many benefits. When Directory Server is close to clients (i.e., on the same network segment as the clients), replication improves response time to client requests. Replication also improves directory availability and fault tolerance. Finally, replication reduces WAN traffic by keeping directory requests local.

For example, suppose Acme's Products department is in Kalamazoo, Michigan, and the other two departments are in Chicago, Illinois. The directory server in Chicago is the supplier server. If you want users in Kalamazoo to access the directory from a local server to avoid WAN traffic, you can install a consumer server in the local network in Kalamazoo and replicate the directory from the supplier server in Chicago to the consumer server in Kalamazoo.

Although effective, single-master replication has two drawbacks. First, unlike with multimaster replication, you can use only the master server to modify the directory database. (With multimaster replication, you can use more than one server to modify the directory database. For more information about multimaster replication, see Mark Minasi, "NT 5.0 Gets Better and Better--Mostly," December 1997.) However, Netscape claims single-master replication is easier to manage than multimaster replication. In addition, Netscape says that single-master replication minimizes the chance of getting different responses when two different applications send two different directories the same query.

The other drawback of single-server replication is that Directory Server doesn't let you physically partition the directory database according to your company's department locations. In other words, you can't divide the directory database into multiple parts and store each part in a different server.

If you want to partition your data, you must set up multiple, separate directories, but managing multiple directories is harder than managing one directory. Directory Server can, however, replicate part of the directory, such as a subtree.

Speeding Up a Search
According to Netscape, a Directory Server database can contain as many as 1 million entries. As a result, searching the database for entries might be slow. Directory Server's index files can improve search performance.

Here's how index files work. Suppose you want to use an LDAP client, such as the Directory Server Gateway tool (shown in Screen 2), to search for all managers at Acme. The client will send a search filter--in this case, title contains manager--to Directory Server. Based on the contents of the search filter, Directory Server determines whether related index files (in this case, an index file for the title attribute) exist.

If related index files exist, Directory Server generates a list of entries from those files; otherwise, Directory Server first generates a list of all entries in the directory database and then examines each entry in that list to find those entries that match the search criterion. In the Acme example, if Directory Server has an index file for the title attribute, it will find the three department managers much faster because it is searching a list that contains several candidates rather than a list that contains all directory entries.

Directory Server supports four types of index files: presence, equality, approximate, and substring. The presence index file lets you search for entries that contain a specific attribute, such as title. The equality index file lets you search for entries that contain an attribute value that is the same as the search value, such as title=Sales Manager. The approximate index file returns entries that contain an attribute value similar to the search value. For example, if your search filter is givenName~=Jon, the directory server with an approximate index file for attribute givenName will return entries having givenName=Jon and givenName=John. The substring index file lets you search for entries containing a specific substring. In the example in Screen 2, the directory server searches for entries having title=*manager*, so it returns the three entries of admin manager, sales manager, and products manager.

Directory Server contains predefined index files for commonly used attributes. For example, it has presence, equality, and substring index files for the attributes of telephone number and NT user domain ID. You can change the default indexes or add new index files to suit your needs.

Index files speed searches in the directory but involve a tradeoff with your system resources. After you add, delete, or modify an entry that contains index file attributes, directory server updates the related index files to reflect the change. Because indexing operations consume CPU cycles, the more index files the Directory Server maintains, the longer it will take to update those files and the more disk space it will use.

Making a Referral Intelligent
Occasionally, Directory Server needs to refer an LDAP client to a different server. For example, a referral might occur when a user attempts to modify an entry in a consumer server, access information stored on a different server from the local server, or access an entry in the local server but the contents of that entry exist elsewhere. When one of these events occurs, Directory Server intelligently sends the client a referral that redirects the client to another server. If the client supports referrals, the client will initiate a new request automatically.

Figure 3 shows a general referral process. When a directory server receives an LDAP request from an LDAP client, it first determines whether the client is asking for local information by examining the directory root entry (for instance, o=acme.com) of the request. If the information isn't local, the directory server will simply return its default referral to the client. If the information is local, the directory server will try to find the requested information locally. If an entry in the search scope is a smart referral, the directory server will automatically chain the request to another directory server or return the referral to the client, according to the defined referral information.

The chaining operation is transparent to the client. When the client receives a referral, it will automatically reformat the original request based on received referral information and reissue the new request to the referred directory server. If this directory server contains the requested information, it will return the result to the client.

Referrals are particularly useful when you want to access another company's directory in your extranet without the requirement of directory replication from that company to your company. Referrals also let you link separate directories if you are running a large intranet with distributed network administration in multiple locations.

An Important, But Limited, Tool
As you have seen, Directory Server 3.0 is a general-purpose directory that you can use for single-point administration of your user accounts and network information. You can also use it to build a secure and reliable directory service for your intranet.

Directory Server is OS-independent. You can implement it in one platform and import it into another one. When you use Directory Server and Netscape SuiteSpot applications for your NT network, users can access any Internet or intranet service with a single account. LDAP-enabled applications no longer need separate user databases. They can simply authenticate users through the LDAP directory and store and look for user or application profiles in the directory.

However, besides Netscape SuiteSpot, few applications on the market are LDAP-enabled. Netscape offers a comprehensive LDAP C/C++ and Java software development kit for developing LDAP-enabled applications, but application developers must go through a culture change and steep learning curve before they can deliver products.

Both Netscape and Microsoft have done a good job to build LDAP lookup function into their browsers. Communicator 4.0 and Internet Explorer (IE) 4.0 can conduct a simple search for a person from public white pages on the Internet (by the address book) or a complex lookup for LDAP information in your network (by LDAP URL). As time passes, you can expect to find more LDAP-enabled applications available for your network.