In "Secure Your Email, Part 1," April 2002, InstantDoc ID 24226, I outlined Exchange Server's Advanced Security features. Now I want to show you how to set up and install Advanced Security to work with a Windows 2000 certificate server and Microsoft Outlook 2002 clients. But first you need to install a couple of vital infrastructure components: the Certificate Authority (CA) and Exchange Key Management Service (KMS).
Install the CA
The CA is the security component that issues certificates to users. Microsoft offers two CA products: The Windows NT 4.0 Option Pack includes one, and the other is an optional Win2K component. The Win2K CA boasts several improvements over the NT version, so I recommend that you use the Win2K CA even if you're still using NT 4.0 and Exchange Server 5.5. For this column, I used a combination of the Win2K CA, Exchange 5.5 (Service Pack 3—SP3—or later), and Outlook 2002.
To install the CA, open the Control Panel Add/Remove Programs applet. Click Add/Remove Windows Components to start the Windows Components Wizard. Select Certificate Services. The wizard warns you that after installing the CA, you can't change your computer's name. As a result, you won't be able to rename the computer, join a domain, or leave a domain. (The computer and domain name are embedded in the CA certificate, so if you make any of these changes, you'll invalidate all the certificates you've issued.) Click Details in the Windows Components dialog box to install the Web Services component, which lets users request certificates through a friendly Web interface. (Exchange doesn't require the use of the Web Services component.)
Next, the wizard prompts you to specify the type of CA that you want. You can choose from four types: enterprise root CA, enterprise subordinate CA, standalone root CA, and standalone subordinate CA. The primary distinction between enterprise CAs and standalone CAs is that enterprise CAs require Active Directory (AD) and automatically publish issued certificates in AD. Because you're using Exchange 5.5 to publish certificates, you don't need AD, although you can specify an enterprise CA type if you're installing the CA on a machine that's a member of an AD domain.
The distinction between root and subordinate CAs is also straightforward. All CAs sign the certificates they issue so that clients can ensure the validity of the certificates, but how can you determine whether the CA is trustworthy? A root CA signs its own CA certificates (i.e., self-signed certificates), whereas a subordinate CA's certificate obtains its signature from a higher-level CA (companies often use third-party CAs for this purpose).
Suppose I work for Microsoft and create a root CA called Microsoft. I can then create subordinate CAs for the Windows, Exchange, and SQL Server teams, and the teams can use their own CAs to issue certificates. An outsider who wants to verify a certificate that the Exchange team's CA issued can validate the CA's signature on the certificate, and he or she can also verify the root CA's signature on the issuing CA's certificate. You should create a subordinate CA only if you have a root CA in place. Therefore, check with your security or network infrastructure team before you install a new CA. Typically, Advanced Security installations create a root CA.
After you select the CA type, you must provide identifying information for the CA's certificate. The values you provide will be Unicode-encoded, stored as attributes in the CA's certificate, and signed either by the subordinate CA or by the root CA. You can't change any of these attributes after the system generates the CA certificate, and generating a new CA certificate might result in the need to reissue certificates to all your clients—so be careful about the information you provide.
Next, the wizard asks you to specify a location for your certificate databases. Make sure you place these databases in a location that permits backup—if you lose the ability to restore the CA's private key, you'll need to generate a new private key and reissue certificates to all your clients. After you select a location, Windows finishes the CA installation.
Choose a Policy
Now you need to inform the certificate server about which certificate-issuance policy to use. To install the Exchange-specific policy module and tell the CA to use it, follow these steps:
- From your Exchange 5.5 (SP3 or later) CD-ROM, copy \server\support\kms\expolicy\i386\expolicy.dll to \%systemroot%\system32 on the CA computer.
- Register the policy DLL with the regsvr32 command (regsvr32 expolicy.dll).
- Open the Microsoft Management Console (MMC) Certification Authority snap-in, right-click your CA server's name, and choose Properties.
- Switch to the Policy Modules tab, then click Select.
- Select the Legacy Policy Module option, click OK, and close the Properties dialog box.
- Permit the Certification Authority snap-in to restart the certificate server.
Install and Configure the KMS
Your next step is to install and configure the KMS. Because you can install the KMS only by running the Exchange Setup program, you'll need your Exchange 5.5 server CD-ROM. (If you've already installed Exchange, when you run setup again, you'll need to use the installer's Add/Remove option to add a new component.) To install the KMS, simply select KMS from the Microsoft Exchange Server components:
- Ensure that Microsoft Exchange Server is selected and click Change Option.
- Select the Key Management Server check box.
- Click OK, then click Continue. Setup will verify the service account password.
The next step is crucial: You must enable a password for the KMS. This password controls the KMS, which won't start without it. Exchange Setup generates this random password string and either displays it once so that you can write it down or writes it to a disk. You can't recover the password if it's lost, so be very careful with it. After you record the password, setup finishes the KMS installation, and you can start the service from the Control Panel Services applet. Before the KMS can start, you must provide the password, either by inserting the disk or by filling out the service password field in the KMS's Properties dialog box.
The KMS requires little configuration. In Microsoft Exchange Administrator, you use the Site Encryption Configuration node (underneath the site object for the KMS's home site) to set KMS's options. The General tab includes the display name, directory name, and KM Server location. The Algorithms tab lets you specify which encryption and signature algorithms the KMS will use when it issues certificates.
You can control several KMS settings by using the CA object beneath the site's Configuration node. The most important of these settings is the KMS access password. Don't confuse the access password (which grants access to the KMS) with the KMS password (which the service uses to encrypt its key database). Microsoft sets the default access password to password. One of your first tasks should be to change this default password. Open the CA Properties dialog box, which Figure 1 shows. Go to the Administrators tab and click Change My KM Server Password. You also use the Administrators tab to grant KMS administrator permissions to other accounts.
The Passwords tab lets you specify the number of administrators you want to approve security-sensitive tasks, such as adding administrators, revoking a user's key, or recovering a key. By default, one administrator can accomplish any of these tasks, but you can choose to require two, three, or more administrators to concur.
Enable Advanced Security
After you configure your KMS—passwords and all—you're ready to enroll users. When you enroll a user, the user receives a certificate that's published in the directory. The system updates the user's mailbox attributes to include a reference to the certificate. To enroll a user, open his or her mailbox's Properties dialog box and go to the Security tab. The Enable Advanced Security button permits the user to use Advanced Security and generates a temporary key. If you permit email distribution of temporary keys (on the Enrollment tab), Exchange Administrator will mail the key to the user. If you don't permit email distribution, Exchange Administrator will display the key string, and you can use a different distribution method (e.g., the telephone).
The Enrollment tab lets you determine certificate format. By default, Exchange 5.5 issues X.509 V1 certificates, but Outlook 98 and later (as well as Win2K) can use the more flexible and capable X.509 V3 format. Be sure to enable V3 certificates unless you're using old tools and need V1 certificates. The highlight of this tab is the Bulk Enrollment feature. Who wants to enroll 1000 users one at a time? From the dialog box that this button accesses, you can enroll all the users residing in a container in the KMS site. (You shouldn't be using multiple recipient containers, so bulk enrollment typically enrolls all users in a site simultaneously.) Select the container whose recipients you want to enroll, then click OK.
After users obtain their credentials, they can use Outlook to complete the enrollment process. The KMS and CA work together to issue the certificate and publish it in the Exchange directory. (For more information about how to use Outlook with Advanced Security, see Jan De Clercq, "Advanced Security in Exchange 2000, Part 2," http://www.winnetmag.com, InstantDoc ID 8333.) Your users can now sign and encrypt messages that they send to one another (and outsiders, provided they're using compatible software), protecting them from eavesdropping and tampering regardless of whether they're directly attached to your corporate network.
