Integrating Directory and Certificate Services

USING NETSCAPE'S DIRECTORY SERVER AND CERTIFICATE SERVER CAN BE A TAG-TEAM EFFORT

If you spend much time surfing the Internet or combing over your company's intranet, you've probably encountered digital certificates and directory services. Businesses often use digital certificates to secure transactions on their Web sites, and companies rely on directories to provide information about their employees and services to customers and other employees. A systems administrator can configure directory and certificate services to operate independently under Windows NT, but these services can also work together in a tag-team effort to let users and systems interact with one another securely.

This article describes how to install Netscape's Directory Server and Certificate Server to work together. I'll also explain how you can configure these servers for a large corporate environment to support a large user base and improve overall performance.

A Certificate and Directory Services Primer
Digital certificates are digital documents that verify that users and systems are who they say they are. Digital certificates can create a secure communication channel between applications. For example, you can obtain digital certificates before creating a Secure Sockets Layer (SSL) connection and use them for SSL communication between a Web browser and a secure Web server. Likewise, a Secure Electronic Transmission (SET) uses digital certificates, and indirect communication via Internet mail messages can use digital certificates for Secure MIME (S/MIME) and pretty good privacy MIME (PGP/MIME) protocols. (For more information about digital certificates, see the sidebar "Digital Certificates 101.") You manage digital certificates using a certificate server.

If you run a Web server, you probably also run a directory server to identify and manage your site's users. Directory servers support the Lightweight Directory Access Protocol (LDAP), which lets applications locate information about people and items on an intranet or portions of the Internet. A digital certificate is just one item that a directory server can store. You can operate a Web server without using a directory server, but I don't recommend this practice.

You can run independent directory and certificate servers, but by pairing the servers, your users can store their public key certificates on the directory server so that other users who use the directory server can access those certificates. For example, paired directory and certificate servers let a user who wants to send an encrypted message simply use LDAP to find the recipient's entry on the directory server and use the public key in the matching certificate to encrypt the message. You can store servers' digital certificates in the same way you store users' certificates. Combining a directory server with a certificate server makes a perfect adjunct to other intranet servers such as mail servers and Web servers.

Netscape SuiteSpot Overview
Netscape provides a directory server and a certificate server that can operate as standalone services, but the servers work best when you use them together with other Netscape servers. The company's SuiteSpot software offers a collection of Internet and intranet servers. Netscape SuiteSpot Standard Edition includes Enterprise (Web) Server Pro, Messaging Server, Directory Server, and other intranet servers. You can purchase Netscape's Certificate Server as a separate product or as part of SuiteSpot Professional Edition, which adds Certificate Server, Proxy Server, and Compass Server to SuiteSpot Standard Edition.

Enterprise Server Pro typically exists on the same system as the other SuiteSpot servers and provides Web-based management for these other products. Although most users see Enterprise Server Pro when they use a Web browser to visit a Web site running SuiteSpot, Directory Server is the server that is central to all others, as Figure 1 shows. Directory Server provides directory assistance information (e.g., names, email addresses, telephone numbers) to users and provides system information (e.g., security data) to other SuiteSpot servers. Directory Server uses the Directory Synchronization Service (DSS) to synchronize mailbox creation with Messaging Server. For information about Directory Server, see Tao Zhou, "Exploring Netscape's Directory Server 3.0," April 1998.

Directory Server lets you securely access the other Netscape servers on your network using usernames and passwords, but this approach isn't sufficient for securely exchanging information between users across the Internet. To ensure secure Web communication, you need to use digital encryption keys and authorized keys in the form of digital certificates.

Certificate Server lets you create, sign, and manage digital certificates using SSL. Certificate Server can act as a Certificate Authority (CA) and a certificate directory system that keeps a list or directory of certificates it issues. You can install Certificate Server on the same system as Enterprise Server Pro, but many IS professionals install Certificate Server on a separate system for security reasons. If users can access Certificate Server, they can create new, signed certificates. Therefore, isolating Certificate Server limits exposure to unwanted hacking because users can access only Directory Server.

The process of pairing Directory Server with Certificate Server is relatively straightforward when the certificate server functions as the CA. However, this configuration becomes more complex as you add more servers.

Scaling Directory and Certificate Services
You can integrate multiple directory servers and certificate servers. Multiple directory servers can distribute the load in an environment where many users need directory access and increase efficiency by providing a directory of remote information locally. Users can access a local directory when creating email to remote users. Many email packages provide this functionality, but a directory server doesn't require users to maintain a personal address book.

You use referrals and replicas to link multiple directory servers. A referral involves forwarding a realtime request from one directory server to another. One server requests directory information from another, the second server responds to the first server's referral, and the first server provides the information to the requestor as if it maintained the requested information. Referrals are useful for occasional external references. They are standard LDAP requests, in which one directory server acts as an LDAP client communicating with an LDAP-compatible directory server. Machine's running Netscape's Directory Server can request referral information from any LDAP-compatible directory server.

Replicas duplicate parts of a remote directory locally. The directory server typically creates and updates the duplicate directory entries on a regular schedule. Replicas work best when one communication can update several entries, application access to a local directory server is more efficient than accessing a remote directory server, and users access the replicated data often. You can locate the remote directory server behind a firewall that application requests can't pass through but directory server requests can. You can also restrict the directory servers to use a secure communication route that isn't available to user applications.

You can configure replica and referral support on the same directory server, as Figure 2 shows. The local directory includes any data you replicate from other directory servers and forwards any request for information it doesn't find in the local directory to a referred directory server.

You can link multiple certificate servers to ensure trusted signing of certificates and to exchange Certificate Revocation Lists (CRLs). When a certificate server that functions as a CA provides a signing certificate (i.e., a certificate that lets a subordinate CA sign new certificates) to a subordinate CA, it generates a public and private key. The public key includes a certificate that the subordinate CA can incorporate into new certificates that the subordinate CA signs. The public key certificate links the new certificates to the higher level CA. Netscape's Certificate Server generates these new certificates, but the certificate exchange isn't part of the automatic communication between CA certificate servers.

A certificate server doesn't have to function as a CA if it simply distributes existing certificates, and a CA can distribute certificates that it didn't sign. Netscape plans to enable automatic generation and exchange of CRLs between certificate servers. However, the version of the software I tested provides only automatic updates of a server's CRL, but no cross-server updates.

Installing SuiteSpot
To use Netscape's Directory Server and Certificate Server, I installed Netscape's SuiteSpot Professional Edition on a server running NT Server 4.0 with Service Pack 3 (SP3). Netscape's installation assumes you have assigned IP addresses to every server running SuiteSpot products, either statically or using a Dynamic Host Configuration Protocol (DHCP) server, and that you've installed a Domain Name System (DNS). You need to set up the DNS with the IP addresses and names for any servers you use.

I installed Enterprise Server Pro first to provide Web services that Directory Server and Certificate Server use. I installed Messaging Server next on a different NT server to improve SuiteSpot's performance. Both installations follow the standard installation process and don't significantly affect the installation or configuration of Directory Server or Certificate Server.

Installing and configuring Directory Server. The first step to installing Directory Server is copying the appropriate Directory Server and DSS files to disk. Next, you use a Windows-based application to configure DSS, as Screen 1 shows. You can set up DSS after you install Directory Server if necessary. You must specify a distinguished name (DN) for the Directory Server administrator and directory base at this time. You'll need to know both DNs when you configure Directory Server, so write them down. Both entries contain the root DN, which in Screen 1 is o=Win NT Labs, c=US. For information about DNs, see the sidebar "Accessing the Directory Database Using Distinguished Names."

DSS performs several tasks. For starters, it synchronizes the information in the Directory Server directory with the NT domain names. DSS places the NT names into an organizational unit (ou) known as ou=NT domain 1. This naming scheme is handy when you link directory servers that have to keep track of multiple NT domains. DSS can also synchronize NT's user database with Messaging Server so that Messaging Server can create and manage mailboxes for each NT user. To provide this functionality, the administrator must provide Messaging Server's domain name at this stage of the Directory Server setup. This domain name can be on the same system as Directory Server or on a different server.

During the Directory Server installation, you can also set the DSS synchronization schedule by selecting the Synchronization Schedule tab you see in Screen 1. You'll want to set the synchronization schedule for a short interval so that DSS can automatically synchronize changes instead of you having to manually force a synchronization.

After you finish configuring DSS, you configure Directory Server using a Web browser to connect to a management Web server. The Directory Server installs this management Web server when it copies the Directory Server files to your hard disk. Password protection on the management Web server provides secure configuration even when you're browsing the server from a remote PC. The first screen of the management Web server lets you create a new directory server using a Web-based wizard. You also create the certificate server on the initial management Web server page, but this Web page doesn't display the button for creating the certificate server until after you install the Certificate Server files.

A key item that you must specify on the first page of the Directory Server installation wizard is the root DN (e.g., Database Subtree) and administrator's user entry (e.g., Unrestricted User), which in this case shares a common name (cn) with the Directory Manager Administrator DN entry. You can also enable encryption from the first page of the wizard, but you must provide a digital certificate. I suggest you disable encryption at this point and enable it later.

After you complete the installation wizard, you must manually start Directory Server before you configure Certificate Server. The Directory Server interface displays in the same Web browser you used to access the management Web server.

Changing Directory Server settings is as simple as clicking the name of each setting, as Screen 2 shows, and changing its value. For example, the default LDAP access is set for unencrypted operation. You can click the Encryption Enabled link and change this setting through the Web browser. Online Help is available for every setting. Although the Directory Server installation wizard doesn't let you configure performance settings, you can use this interface to make changes.

If you're running multiple directory servers, you can configure the LDAP referral server setting to find remote directory entries. You simply provide the domain name of the LDAP server you want to use, and Directory Server will look to that server for requested entries that aren't in the local directory.

You can link Enterprise Server Pro to Directory Server for LDAP authentication instead of using the NT authentication that you typically use with a Web browser. LDAP authentication works the same in NT and non-NT environments (e.g., Netscape servers running on UNIX). To set up the link, you use Netscape's Administration Server LDAP Configuration program, as Screen 3 shows. This program requires that you provide the base DN that you specified during the DSS and Directory Server installation. Selecting the Use LDAP-based authentication check box in Screen 3 configures Directory Server to service LDAP requests, which requires an LDAP client such as an LDAP-enabled mail application.

To provide a Directory Server Web-based interface for users who need access to the directory but don't have an LDAP-enabled client, you must set up Enterprise Server Pro to use the Common Gateway Interface (CGI) files that come with Directory Server. The HTML file setup and CGI file setup direct the Web server (i.e., Enterprise Server Pro) to the Directory Server Web pages so that anyone with the URL and a Web browser can search the directory. One advantage of Directory Server's Web-based interface is the ability to interactively manage Directory Server. The alternative to this approach is to edit text files that contain configuration and database information. The Web-based interface lets you easily make individual changes, but importing massive changes through the text files is easier.

To finish setting up your first directory server, you need to create the container (i.e., ou) that DSS will use for synchronization. The Web-based interface lets administrators create new users and ou's such as NT Domain 1, as Screen 4 shows.

The next step in configuring your network's Directory Server architecture is to set up a second directory server on another NT server so you can link the two directory servers using Netscape's replica support. You must configure both servers using the management Web server for the replica support to operate. You can replicate all or part of one server's directory database to another server. To configure two directory servers to exchange portions of their local directories, you must set up replication twice because the replica support uses a supplier and consumer architecture.

One directory service can support multiple consumers. Both suppliers and consumers must be running Directory Server. The supplier and consumer directory servers don't have to connect all the time, only during scheduled or manually initiated updates.

You'll want to set up the consumer Directory Server first. A consumer can have more than one supplier, but all of a consumer's suppliers must use the same replication supplier service entry that you create in the consumer's directory database. You'll want to password-protect this entry (all supplier Directory Servers use the same supplier service entry name and password). You must then set up the replication supplier service entry in the consumer Directory Server's Replica Config section, as Screen 5 shows. The consumer entry of every supplier that provides directory information to this consumer will use the same Supplier DN that you see in Screen 5.

The next step is to set up the supplier Directory Server. You can open two Web browser windows so that you can access both the consumer and the supplier servers at the same time and copy the necessary DNs from one window to the other. Alternatively, you can write down the DNs and enter them manually at the respective sites.

The supplier has one consumer entry for each Directory Server that it sends replicated data. You use the DN and password I mentioned previously in the consumer Directory Server setup in the consumer entry form, as Screen 6 shows. You must also include the name of the container or ou you want to replicate so you can specify which subset of the directory you want to replicate. You can use an encrypted link to connect the supplier and consumer Directory Servers. Replication can occur only once per day. You can configure any number of consumers, and each consumer has a schedule that the supplier maintains.

At this point, Directory Server configuration is complete. Directory Server will refer requests for unknown names to a referral server and replicate directory information from one or more suppliers. It might also provide replicas to one or more consumers.

Installing and configuring Certificate Server. Whereas Directory Server maintains its database, Certificate Server uses the Informix SQL Server database that comes with SuiteSpot Professional Edition. You must have the Informix SQL Server software running before you start Certificate Server.

You create and start Certificate Server from the management Web server. The Netscape Certificate Server Installation Wizard is a Web-based application that steps through the installation process. Unfortunately, many of the installation steps are manual, so keeping a DOS window open helps speed the process.

One of the manual steps is generating CA signing keys. Certificate Server can obtain a key and digital signing certificate from another CA if this particular certificate server is not the root. The wizard sets up all the necessary keys and certificates for a standalone certificate server that serves as a CA. You must set up these keys and certificates before configuring the rest of Certificate Server.

Informix SQL Server has a setup and configuration process that uses Windows-based applications. The default settings are all you need if you use the Informix SQL Server only with Certificate Server. You can use Informix SQL Server for other purposes, but I don't recommend doing so. Informix SQL Server sits in the background; you just start it and leave it. Maintenance consists of backing up the database, if necessary. (You can back up the database to a disk because the certificate database is typically small compared with other databases.)

The CA signing support lets Certificate Server create new certificates and log them in to the certificate database. At this point, you can create signing certificates and distribute them to trusted certificate servers in a CA hierarchy. The certificate servers don't automatically exchange certificates, and the signing certificates contain private signing keys. After you link Certificate Server and Directory Server, users and other servers can access the certificates through Directory Server's LDAP support.

Certificate Server has a Web-based interface for searching, posting, and requesting certificates, as Screen 7 shows. This interface uses the same type of interface as Directory Server, and the Web-based interface setup procedures are identical for both servers. You don't have to make the Web-based interface available to the public if you're the only one who needs to add certificates and you've linked Certificate Server to Directory Server. Limiting access to Certificate Server helps make it more secure.

Linking Directory Server with Certificate Server
When you link Directory Server with Certificate Server, Certificate Server adds new certificates to Directory Server's database. Once Directory Server and Certificate Server are running, linking the two is simple. You begin by adding a directory entry for Certificate Server with a password in Directory Server's database. You can easily create this entry using Directory Server's Web-based interface. Keep the DN for this entry handy because you'll need it during the next step.

Next, you need to set up Certificate Server to send new certificates and certificate changes to Directory Server. A certificate server can synchronize with only one directory server, but that directory server can be a supplier and replicate the certificate server's information to any number of consumer directory servers. The certificates that Certificate Server sends to Directory Server contain the DN of an entry in Directory Server. Directory Server adds the signed certificate to the attributes of the matching DN in Directory Server when Certificate Server synchronizes with Directory Server. Directory Server also automatically updates the database when Certificate Server revokes certificates. Certificate Server can store its CRL in a Directory Server entry.

After you configure Certificate Server and Directory Server to exchange information, you can set up Netscape Navigator's mail client to use LDAP so that users can look up email recipients and their public keys. Configuring Navigator's mail client for this purpose is simple. All you need to provide is the directory server's domain name, then you can search the directory for a particular entry.

You can use the public key certificate that Certificate Server signs and Directory Server stores to verify the digital signature of a particular user's message. You can also use the certificate's public key to encrypt a message that only the owner of the matching private key can decrypt.

Directory Server and Certificate Server operate with minimal maintenance. You'll want to periodically check log files, including those that track server synchronization. You can automate the process of issuing certificates. Netscape provides a sample CGI script for this automation, but this process assumes you have some method (i.e., using IP addresses or passwords) to recognize the requestor. In a future article, I'll show you how to perform this same integration using Exchange Server.