Lesson 2: Deploying a Public-Key Infrastructure for Exchange 2000 Server | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

Exchange Full Administrators can access all messages in the Information Store service. Even if users download the messages to their local workstations, it is still possible to capture the data for later analysis. In each mailbox store’s General tab, for instance, a system administrator can specify a mailbox or mail-enabled public folder to archive all sent and received messages. This may represent a concern for companies that consider outsourcing their messaging infrastructure, because users might want to exchange internal or confidential data with each other not meant for the eyes of an ASP. To address this concern, ASPs can deploy a PKI for Exchange 2000 Server and enroll users with advanced security. This enables the users to encrypt sensitive data, which ensures that only the desired recipients can interpret the information. There is one restriction, however: OWA is unable to encrypt or decrypt messages.

This lesson explains how to implement Exchange 2000 Key Management Server (KM Server) into an existing messaging infrastructure to support advanced security features in MAPI-based and Internet mail clients. You can read about the purpose of public key technology and the differences between message signing and sealing. You also learn how to establish a PKI using Microsoft Windows 2000 Certificate Services and how to integrate Exchange 2000 Server.

After this lesson, you will be able to

Use X.509 encryption technology to send signed and sealed messages to users in your own and foreign messaging organizations
Use Windows 2000 Certificate Services and KM Server to establish a PKI for advanced security
Design a PKI and advanced security environment for organizations that use Exchange 2000 Server for messaging and collaboration

Estimated time to complete this lesson: 60 minutes

Understanding Public Key Technology

Public key encryption technology relies on a pair of public and private encryption keys, which are used to encrypt and decrypt data. The private key, as its name implies, is available exclusively to the user to whom it belongs. The public key, on the other hand, is distributed to all users in the organization either via a common directory or in e-mail messages. All users, including the user to whom the key pair belongs, use the public key for encryption. It is possible to exchange public keys across the boundaries of an organization. The X.509 standard, defined by the ITU-T, describes the handling of private/public key pairs within computer systems. Figure 9.10 illustrates their use for message sealing.

Figure 9.10 - The principle of public key encryption technology

Exchange 2000 Server uses a dual key-pair system, which means that its advanced security features rely on two separate public and private keys. Dual key-pair systems provide a higher level of security than single key-pair systems because each key pair has a dedicated purpose. Keys are not interchangeable. One set of keys is used for digitally signing and verifying messages and the other for sealing (encrypting) and unsealing (decrypting) messages.

In an Exchange 2000 organization, Outlook users can work with the following security keys:

Private keys MAPI-based clients use a private signing key for signing messages; the private sealing key is used for decrypting sealed messages. Windows 2000 stores private keys in protected format in the Registry database. If you configure server-based user profiles, you can use the keys on every workstation you log on to. It is very important that these keys are not disclosed.
Public keys Recipients can use the public signing keys of message originators to verify the digital signatures; MAPI-based clients use the public sealing key of each recipient to encrypt messages. Public keys are available to everyone across the entire messaging organization.
Bulk encryption key This key, also known as a secret key or session key, is a security string (password) used for both encryption and decryption of information. MAPI-based clients use a secret key to encrypt and decrypt private keys. Secret key cryptography is also used in conjunction with public keys to encrypt messages.

Message Signing and Sealing

Advanced security has two purposes. It allows you to verify that an originator was truly the sender of a message and that the message content has not been tampered with on its way to your mailbox. This is possible if the sender attaches a digital signature to the message; however, the message is still transmitted in clear text. To encrypt the message entirely, the originator must seal the content using your public sealing key. A "man-in-the-middle" may redirect and intercept the sealed message, but any unauthorized person will find the message unreadable.

Note

A sealed message does not necessarily carry a digital signature, and a signed message is not automatically sealed.

Table 9.3 summarizes the processes of message signing and sealing.

Table 9.3 Message Signing and Sealing with MAPI-Based Clients

Advanced Security Feature	Encryption Process
Message signing	1. Client calculates a digest (a hash value) for the message contents. 2. The user’s private signing key is used to encrypt the message digest. 3. The message plus encrypted digest and public sealing key are transmitted to the server. 4. When the recipient checks the signature, the client obtains the public sealing key from the message and decrypts the message digest. 5. The client performs the hashing of the message again and com- pares this hash to the decrypted message digest. 6. If both digests are the same, the message is okay and the sender was truly the originator of the message.
Message sealing	1. The sender’s client obtains the recipient’s public sealing key from Active Directory and generates a bulk encryption key to encrypt the message. 2. The client encrypts the message using the bulk encryption key and then encrypts the bulk encryption key using the recipient’s public sealing key, thus creating a lockbox for the recipient. 3. Encryption of the bulk encryption key using the sender’s public sealing key also ensures that the originator can read the message later if it is saved in a Sent Mail folder. 4. The encrypted bulk encryption keys are added to the message and the message is transmitted to the recipients. 5. The recipients can use their private sealing key to decrypt the bulk encryption key, which in turn is used to decrypt the message.

Advanced Security Feature

Encryption Process

Message signing

1. Client calculates a digest (a hash value) for the message contents.

2. The user’s private signing key is used to encrypt the message digest.

3. The message plus encrypted digest and public sealing key are transmitted to the server.

4. When the recipient checks the signature, the client obtains the public sealing key from the message and decrypts the message digest.

5. The client performs the hashing of the message again and com- pares this hash to the decrypted message digest.

6. If both digests are the same, the message is okay and the sender was truly the originator of the message.

Message sealing

1. The sender’s client obtains the recipient’s public sealing key from Active Directory and generates a bulk encryption key to encrypt the message.

2. The client encrypts the message using the bulk encryption key and then encrypts the bulk encryption key using the recipient’s public sealing key, thus creating a lockbox for the recipient.

3. Encryption of the bulk encryption key using the sender’s public sealing key also ensures that the originator can read the message later if it is saved in a Sent Mail folder.

4. The encrypted bulk encryption keys are added to the message and the message is transmitted to the recipients.

5. The recipients can use their private sealing key to decrypt the bulk encryption key, which in turn is used to decrypt the message.

X.509 Certificates

By default, users do not possess encryption keys. The client has to generate them and ask a CA in an explicit process to certify the keys. Each encryption key pair requires its own X.509 certificate, which contains information about the supported encryption methods and ensures the legality of the keys. For instance, mailbox-enabled user accounts enrolled with Exchange 2000 advanced security hold an X.509 certificate in Active Directory that contains their public sealing key. Every user in the organization has access to this information via the GC. The X.509 certificates bind the public keys to their corresponding users and ensure that nobody has tampered with a sealing key.

To conform to X.509, advanced security certificates must contain the following information:

CA’s distinguished name and digital signature
Expiration date for the certificate
Location of the Certificate Revocation List (CRL), which must be checked to verify that the certificate has not been revoked
Public encryption key and a description of its purpose
Unique serial number generated by the CA to identify the certificate
User’s distinguished name
Version 3 Extensions, such as key identifiers, certificate policies, alternate names, and so on

Foreign X.509 Certificates

It is possible to obtain sealing certificates from persons in other messaging organizations to send those users encrypted messages. Just exchange your sealing certificate with the desired persons manually. In Outlook 2000, from the Tools menu, select Options. In the Options dialog box, click the Security tab, and then click Setup Secure E-Mail. Make sure the Send These Certificates With Signed Messages option is enabled to include a copy of your sealing certificate into any signed messages. Send each person a signed message and ask the recipients to send you a signed message as well. As soon as you have received a digitally signed message, open it, right-click the name in the From field, and then select Add To Contacts. If you have a contact object for this person in your Contacts folder already, you are given the option of updating the information. You can check the existence of the sealing certificate in the contact’s Certificates tab.

To send a user in another organization a sealed message, make sure you select the contact explicitly from the Outlook Address Book (you cannot simply reply to the digitally signed message and encrypt the content because the sealing certificate would then not be available). Furthermore, your client must trust the recipient’s CA that issued the user’s certificate. This may require you to import the root certificates of outside organizations as trusted root certification authorities into your security store. Alternatively, you may publish them in your organization’s internal Certification Trust List (CTL) using the Certificates snap-in on a DC. With the latter approach, all users in your organization automatically trust the external certificate, which is known as cross-certification. You can read more about the purpose of CTLs in the Windows 2000 product documentation.

Note

Microsoft Outlook 98, Outlook 2000, and Outlook XP are able to encrypt messages in Secure/Multipurpose Internet Mail Extensions (S/MIME) format, which is a widely accepted industry standard. You can exchange signed and sealed messages with any other user who uses a messaging client that supports S/MIME, such as Outlook Express.

Establishing a Public-Key Infrastructure

To issue X.509 certificates to your Exchange 2000 users, you need to establish a PKI in your network environment based on Windows 2000 Certificate Services. Certificate Services can operate as a self-signed root CA or a subordinate of another CA, such as a third-party entity like VeriSign. Regardless of the CA type, you must integrate Certificate Services with Active Directory if you wish to support Exchange 2000 Server. In other words, you have to install enterprise CAs for certificate issuance and revocation. All servers running Certificate Services are trusted throughout the forest because they are referenced in a default CTL maintained in a Group Policy object. You can read more about Certificate Services in the Windows 2000 product documentation.

The characteristics of subordinate and root CAs are as follows (see Figure 9.11):

Subordinate CA Another CA has issued the CA’s certificate and both form a hierarchy of trusted authorities. The public key in the subordinate CA’s certificate and the key used to sign this certificate are different.
Root CA The origin of one or many certificate chains. Root CAs are self-signed CAs, which means that the public key in the CA’s certificate and the key used to sign this certificate are the same. You can add the root CA certificates of other organizations to your organization’s CTL to cross-certify (trust) the other organizations’ issuing CAs.

Note

Certificate Services deals with X.509 version 3 certificates. The Key Management Service (KMS) of Exchange 2000 Server integrates with Certificate Services to support X.509 version 3. Exchange 2000 Server can also issue X.509 version 1 certificates for backward compatibility with Microsoft Outlook 97 and earlier clients.

Enrolling X.509 Certificates without Key Management Server

Certificate Services integrates with IIS 5.0 to issue user certificates for secure e-mail communication. Users can connect to http://<CA server name>/Certsrv to begin the enrollment process. This URL is registered by default for the Certificate Services’ Web interface, which is an Active Server Pages–based application that works independently of the user’s operating system or Web browser. The Web interface generates the encryption keys and IIS directs a request for certification to Certificate Services, which in turn generates the corresponding X.509 certificate, stores it in Active Directory (if the CA is an enterprise CA), and sends the certificate back to IIS. IIS provides the certificate to the user. It is also possible to enroll users of Microsoft Windows 2000 Professional with S/MIME certificates using the Certificate Enrollment Wizard, a component of the Certificates console.

You can use S/MIME certificates with Outlook 2000, Outlook XP, and Internet mail clients, such as Outlook Express, for message signing and sealing. However, these certificates are not integrated with Exchange 2000 Server, thus requiring each user to maintain certificates individually. If a user loses access to a certificate (for instance, because of file corruption), the encryption keys cannot be recovered and the user can no longer read existing encrypted messages. KM Server overcomes this problem.

Figure 9.11 - Root CAs, subordinate CAs, and cross-certification

Integrating Exchange 2000 Key Management Server with Windows 2000 Certificate Services

To integrate KM Server with Certificate Services, you need to install three additional templates in your enterprise CA (see Figure 9.12). The template called Enrollment Agent (Computer) enables the KMS to request certificates on behalf of the users. The other templates, Exchange User and Exchange Signature Only, specify the format and content of these certificates. Exchange Signature Only is for signing keys; Exchange User certificates are issued for both message signing and sealing. Remember that every Exchange 2000 user enabled with advanced security works with two private/public key pairs.

Figure 9.12 - Certificate templates required for KM Server

You also need to grant the KM server Manage permission for the CA. On the server running Certificate Services, launch the Certificate Authority console, right-click your enterprise CA, select Properties, and then click the Security tab. Add the KM server’s computer account to the list of accounts with permissions, and then select the Allow check box for the Manage permission to grant the KMS the required rights.

Deploying KM Server in an Organization with Multiple Administrative Groups

KM Server supports centralized and decentralized management of security information. If you have decentralized Exchange system administration using multiple administrative groups, you can deploy KMS individually in each of these groups to decentralize the management of advanced security as well. In any given administrative group, one Exchange 2000 server can run KMS (see Figure 9.13). However, it is also possible to service multiple administrative groups or the entire Exchange 2000 organization with just one KM server by creating a reference to the central KMS in remote administrative groups. To specify the location of the KM server, open the Advanced Security container in each administrative group, display the properties of the Encryption Configuration object, and then, in the General tab, click Change to select the KM server.

Figure 9.13 - Multiple KM servers in a single organization

KM Server Passwords

The KMS maintains a repository, known as the KM database, to store security key histories for Exchange 2000 users who are enabled with advanced security. Key history is required for key recovery and revocation, which are explained later in this lesson. Simply put, the KM database contains the private sealing keys of all users who belong to the KM server. This is critical to understand, because unauthorized persons can read encrypted messages from your mailbox if your private sealing key is compromised. To prevent unauthorized access to security keys, the KM database is encrypted using a KM database master encryption key, which in turn is encrypted using the KM Server password, which is generated during KMS installation.

Note

Make sure unauthorized persons do not have access to the KM database. It is important to include the KM database in regular server backups to save the security key history of all users.

To start the KMS successfully, you need to provide the service with the KM Server password during startup. Otherwise, the service is unable to decrypt the KM database. During KMS installation, you need to specify how to maintain the KM Server password. You can write it to a text file named KMSERVER.PWD on the server’s hard disk, which is the least secure choice. You can also save the password file to a floppy disk. This may be a more secure approach, provided you keep these disks in a secure place. To start the KMS, you need to insert the disk in the server’s floppy drive. You can also provide the password by typing it in the Startup Parameters box in the service’s startup properties. Then in the General tab of the Services tool, click Start. Using the Exchange System Manager snap-in locally on the KM server, it is possible to change the KM Server password and its file location (right-click Key Manager, point to All Tasks, and then select Change Startup Password).

Requiring Multiple Key Management Administrators

By default, only the Exchange 2000 administrator who installed the KM Server is able to manage advanced security features. However, you can designate additional KM server administrators in the Exchange System Manager snap-in’s Key Manager object in the Administrators tab. You can also enforce a policy that requires two or more administrators to specify their passwords before advanced security administration is allowed using the Key Manager object’s Passwords tab. A multiple-password policy provides a higher level of security. In fact, multiple-password policies are the most critical, because a malicious user who has the right to perform the tasks listed below is capable of compromising the entire KMS.

To limit the amount of damage a malicious user can do with a single administrator’s password, require multiple passwords on policies that allow:

Changing the multiple password policies
Adding or removing administrators
Recovering a user’s certificates

Note

You should use the Administrators tab immediately after the KMS installation to change the KM Server administrator password, which is case sensitive and must contain at least six characters. The default password is password.

Enrolling Users with Advanced Security

The process of enrolling Exchange 2000 users with advanced security differs significantly from enrolling Windows 2000 users with S/MIME certificates. An Exchange administrator with key management permissions and the KM Server are involved in this process of enrolling Exchange 2000 users with advanced security. The KM Server administrator must first enable advanced security for the user, and the user must complete the process using Outlook 2000. KM Server requests the certificates from the enterprise CA on behalf of the user (see Figure 9.14).

The steps to enroll a user with advanced security are as follows (see Figure 9.14):

The KM administrator uses the Active Directory Users and Computers console or the Exchange Advanced Security snap-in (stand-alone or integrated in the Exchange System Manager snap-in) to enable advanced security for users. The Exchange Advanced Security snap-in can be used to enroll multiple users at one time (right-click Key Manager, point to All Tasks, and select Enroll Users), whereas the Active Directory Users and Computers console allows you to enable advanced security for individual users (access the user account properties, select the Exchange Features tab, and click E-Mail Security).
KM Server generates a 12-character security key, known as a security token, and communicates with Certificate Services to create the sealing key pair on behalf of the user. The keys are stored in the KM database.
Working with the Exchange Advanced Security snap-in, the security token is written to a file called ENROLL.LOG in the \Program Files\Exchsrvr\ KMSData directory. When using the Active Directory Users and Computers console, the security token is displayed on the screen in a message box. The KM Server administrator must pass the security token to the user without disclosing it to others. E-mail or a phone call may be used, but hand delivery is more secure.
Having received the security token, the user can complete the process of enabling advanced security in Outlook 2000 (from the Tools menu, access the Options dialog box, click the Security tab, and click Get A Digital ID). Because the user is requesting certificates from KMS, he or she must select the Set Up Security For Me On The Exchange Server option. After that, the user has to define a Digital ID Name, provide the 12-character security token, and define a security password for the new digital ID. Outlook 2000, running on Windows 2000 Professional, encrypts the user’s private keys using the specified security password and stores them in the following location in the Registry:
```
 HKEY_CURRENT_USER  \SOFTWARE    \Microsoft    \Cryptography    \Microsoft Exchange Cryptographic Provider    \<Digital ID Name> 
```
Outlook generates the user’s signing key pair, stores the private signing key in the user’s new digital ID, and sends the public signing key in an e-mail message to the KM server to request an X.509 certificate for it. The e-mail message is encrypted using the 12-character security token and addressed to the System Attendant service.
The KM server receives the request message and asks the enterprise CA for approval of the certificate requests.
The KM server returns the approved signing and sealing certificates, together with the public and private sealing keys, in another encrypted message to the user. KM Server also includes its own signing certificate.
The user opens the received security message and is asked for his or her security password. Outlook decrypts the message and retrieves the security information to place it in the local security store. If you have installed an enter- prise root CA, the CA’s self-signed root certificate is added to the trusted root certification authorities store on the local computer to allow the user to use the Exchange certificates.
Outlook 2000 publishes the user’s public sealing certificate, which includes the public sealing key, in the userCertificate and userSMIMECertificate attributes of the corresponding user account in Active Directory. The user is now fully enabled with advanced security.

Figure 9.14 - Enabling advanced security via KM Server

A single Windows 2000 user can have multiple digital IDs, which might be required if you work with different MAPI profiles to access different mailboxes on the same workstation. However, you should not request additional S/MIME certificates, for instance through the Web interface of Certificate Services, for the same user account. If you are using different certificates and keys in different e-mail clients while working with the same mailbox, you might experience problems with mismatching security keys. Exchange certificates can be used in Outlook 2000 and Internet mail clients, such as Outlook Express.

Recovering Security Information

A user can quickly lose access to his or her encryption keys. For instance, if a user changes the workstation without exporting the security information in Outlook 2000 beforehand (by selecting Options from the Tools menu, selecting the Security tab, and then clicking Import/Export), the keys are lost. You can address this by creating server-based user profiles that contain the security store and are available on all workstations. However, a user’s cryptographic keys might simply get corrupted or accidentally deleted or the user might forget the security password; there are many possibilities. An administrator might delete the user profile. In all these cases, you need to recover the keys and certificates; otherwise, all existing encrypted messages are unreadable.

To recover security information, use the Recover Keys command in the Exchange Advanced Security snap-in. You can also work with the Active Directory Users and Computers console, in which case you need to display the properties of the affected user account, click the Exchange Features tab, select the E-Mail Security option, and then click Recover Key to launch the recovery routines. During recovery, the KM Server restores the original sealing key pair from the KM database and returns a 12-character security token that you must pass to the user.

From the user’s perspective, the process of recovering advanced security is the same as the process of enabling it. Outlook 2000 must create a new signing key pair and a signing certificate request, because the old private signing key is irretrievably lost, as it was only stored in the user’s security store. The client sends the new signing certificate request to the KM Server in the recovery message. KM Server forwards the request to the enterprise CA, where a new certificate is issued. This certificate, together with the sealing key pair, is then returned to the user, who completes the process of recovering advanced security. The public sealing key certificate, on the other hand, is still available in Active Directory and doesn’t need to be requested again from the enterprise CA.

Revoking Security Keys

On occasion, it might be necessary to revoke a user’s security keys before they expire as defined in the certificate if, for example, a user suspects that an unauthorized person has gained access to the keys. To disable advanced security for a user, use the Revoke Certificates option in the Exchange Advanced Security snap-in or in the Active Directory Users and Computers console. Accordingly, KM Server adds the user’s private sealing key to an internal revocation list in the KM database. The user’s sealing certificate is also invalidated in the enterprise CA and Active Directory. To revoke the certificate, the enterprise CA adds the unique serial number of the user’s sealing certificate to its CRLs.

Certificate Services configured as an enterprise CA publishes CRLs weekly in the Configuration naming context of Active Directory as well as in the \Winnt\System32\CertSrv\CertEnroll directory, which is published as an HTTP virtual directory with the URL http://<server name>/CertEnroll/<CRL Name>.crl (for example, http://vip-ca.adventure-works.com/CertEnroll/Adventure Works.crl ). You should update published CRLs manually after revoking certificates. In the Certificate Authority snap-in, right-click the Revoked Certificates container, point to All Tasks, and select Publish. This immediately prevents users from sending sealed messages to the revoked mailbox because clients check the CRL to determine whether a recipient’s sealing certificate is valid or revoked. Every X.509 version 3 certificate has a CRL Distribution Points attribute that points to the location of the CRL. When the certificate reaches its original expiration date, it is removed from the CRL to keep the size of the list small.

Note

The KM Server does not delete revoked security keys, but stores them in the KM database. They also remain in the user’s security store because they are needed to decrypt existing messages. You can re-enable advanced security for a revoked user. In this case, the user receives the old security keys along with new security information.

Updating Keys and Certificates

The enterprise CA issues Exchange X.509 certificates with a lifetime of 12 months, but certificates can be renewed as necessary. The client performs the update automatically. When certificates are nearing expiration, the client sends a request to the KM Server asking for the certificates to be updated for an additional time period, and the user receives new signing and sealing key pairs. With revoked security keys, the old private sealing key remains in the user’s security store to decrypt existing messages.

Different Versions of Advanced Security in One Organization

Due to export and import restrictions, there are three different versions of advanced security: a safe North American (3DES) version for the United States and Canada, a less secure Other version (RC2-40) for other countries, and a third version called No Advanced Security for France. The X.509 sealing certificate, stored in the user account in Active Directory, provides information about supported encryption methods.

You can use all three versions of advanced security in the same messaging organization. The messaging client determines the supported encryption method from the intended recipient’s sealing certificate to ensure the recipient can actually decrypt the message. This implies that a French user cannot receive any encrypted messages, for instance. If you specify multiple recipients for one message, the client must check for a common security level supported by all recipients of a message to find the best available encryption method. Messages are encrypted using a bulk encryption key of an appropriate length, so they cannot be encrypted for each recipient separately. For example, if you address a message to recipients in the United States and France, you cannot encrypt the message because the maximum common advanced security level is None.

Note

In the United States and Canada, you can enable strong (128-bit) encryption for Windows 2000 Professional and Windows 2000 Server by installing the Windows 2000 High Encryption Pack. To download the Microsoft High Encryption Pack, go to the Microsoft Web site (www.microsoft.com ) and search for the phrase "Windows 2000 High Encryption Pack."

Designing an Exchange 2000 PKI

When designing an advanced security environment for an Exchange 2000 organization, you need to clarify whether and how the users within your organization will use advanced security and whether your users want to exchange confidential information with other organizations, such as corporate partners and customers. Table 9.4 provides a concise list of the most important design questions.

Table 9.4 Considerations for PKIs

Design Issue	Comment
Do your users work with a client that supports advanced security?	If your users work with OWA or a similar client that does not support advanced security, and if you cannot provide the users the users with a client that supports message signing and sealing, such as Outlook Express, it is pointless to deploy a PKI for Exchange 2000 Server. However, you might want to obtain a server certificate for your Web servers to encrypt the client communication using SSL, which was discussed in Lesson 1.
Do your users still work with Outlook 97 or earlier clients?	If so, and you cannot upgrade to Outlook 2000 or Outlook XP, install KM Server and issue X.509 version 1 certificates.
Do your users still work with multiple workstations?	If so, configure server-based profiles to make the security information available on all workstations. If you cannot configure server-based profiles for any reason, ask your roaming users to export their security keys to a floppy disk and import the information into the security stores on the other computers.
Do you need to integrate Windows 2000 Certificate Services into an existing PKI?	The answer to this question determines whether you should install an enterprise root CA in a new PKI or an enterprise subordinate CA in an existing PKI. A single root CA may besufficient for small companies. For large companies, however, Microsoft strongly recommends a certificate hierarchy to address administrative requirements and scalability issues. In a large organization, many CAs can be used to issue X.509 certificates. If you plan to establish a new PKI, you should consider the advantages and disadvantages of configuring a subordinate authority to a commercial Internet- based root CA. The primary advantage is that the configuration of certificate trust relationships is greatly simplified, because Windows 2000 and other operating systems trust well-known Internet-based root CAs by default. The main disadvantages involve cost and certain organizational dependencies. For instance, if the commercial root CA goes out of business, you need to redesign your PKI. To avoid dependence on an external organization, you may want to create a self-hosted root CA. For more information about establishing a PKI using Certificate Services, consult the Windows 2000 product documentation.
Are you allowed to use strong encryption technology?	If your organization or a part of your company is in the United States or Canada, you should deploy the High Encryption Pack. International users may continue to exchange messages with less secure encryption keys. Microsoft recommends installing the High Encryption Pack on all CAs, KM servers, and Windows 2000 Professional workstations.
Do your users need to exchange encrypted messages with users in other organizations?	If users are going to exchange sensitive information with recipients in another organization infrequently, ask them to manage the sealing certificates in personal contact items and let them manually import the root certificate of the other organization into trusted root certification authorities of their security stores. This is not required if Windows 2000 already trusts the root CA. If users need to exchange sensitive information frequently, consider adding the other organization’s root CA to your organization’s CTL. Choosing to do this requires a significant commitment of effort and will be worth the investment for the most closely partnered, security-conscious companies. The other organization’s PKI must support the X.509 standard, and both organizations must publish their CRLs in such a way that all users can access this information. Apart from CTLs and CRLs, you also need to find a way to conveniently exchange sealing certificates. In the simplest case, users can access each other’s directory information via LDAP. If this is not feasible, consider manual directory synchronization using LDIFDE.EXE or CSVDE.EXE, as discussed in Chapter 4, "Assessing the Current Messaging Infrastructure." Make sure you synchronize the userCertificate and userSMIMECertificate attributes. If access to a common server-based directory is not possible, users have to exchange certificates manually and maintain this information in personal contact objects.
Do you intend to provide KMS for your Exchange 2000 users?	As explained earlier, users can enroll with X.509 certificates even if you don’t deploy KM Server. To provide a sophisticated PKI for Exchange 2000 Server, however, you should install this component.
Do you need to distribute the KMS administration among multiple departments?	Large organizations with decentralized system administration by departments or business units can implement multiple KM servers and possibly integrate these with different enterprise CAs to allow each administrative group to manage its own security certificates. Organizations with centralized administration that use a single administrative group only need to deploy one KM server to support the entire messaging environment.
Does your organization require a high level of security for KMS administration?	Generally, this is the case. Make sure you save the KM Server password only to floppy disks and keep them in a secure place. Grant multiple administrators the right to manage KMS and require multiple passwords to perform administrative tasks. Advanced security is pointless if the password for KMS is unprotected.

Designing a PKI for Consolidated Messenger

Consolidated Messenger, an Oregon-based broadcasting company introduced in Chapter 1, has successfully migrated its MS Mail and Lotus Notes environments to Exchange 2000 Server and Outlook 2000. The messaging organization consists of three administrative groups. Two groups manage the resources separately for company headquarters and the video department (formerly Southridge Video). The third administrative group contains the organization’s routing group, as outlined in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server." The current administrative and routing infrastructure of Consolidated Messenger is displayed in Figure 9.15.

"Company management requires the ability to send sensitive and confidential information in a secure way," says Gregory J. Erickson, Senior IT Administrator at Consolidated Messenger. "Advanced security is not required for every employee, but we must enroll all supervisors, directors, and general managers. Again, our video department has demanded separate management of security keys and certificates. The video department’s administrators want to manage advanced security for their users themselves."

Figure 9.15 - The Exchange 2000 organization of Consolidated Messenger

Erickson worked out the following advanced security strategy for Consolidated Messenger:

Our users work with Outlook 2000, which supports Exchange 2000 Server’s X.509 version 3–based advanced security features. Our messaging organization can fully benefit from an integration of KM Server into our existing PKI.
Supervisors, directors, and managers work with personal workstations as well as notebooks. We will create server-based profiles to save the security information on a server. Users can then download the information to all of their computers.
We already have deployed a PKI based on Windows 2000 Certificate Services, which currently is installed as a stand-alone root CA. To support Exchange 2000 KMS, we need to optimize our PKI and implement an enterprise root CA. One CA will be sufficient for the entire organization.
To support the best possible encryption technology, Consolidated Messenger will install the Microsoft High Encryption Pack on the enterprise root CA, our KM servers, and the Windows 2000 Professional workstations. We still need to develop a strategy for this deployment to all workstations.
Because our users do not exchange encrypted messages with users in other organizations, we do not need to add certificates to our CTLs.
To support distributed management of security keys, Consolidated Messenger will install KM Server in the headquarters administrative group as well as in the video department administrative group. Both KM servers will communicate directly with our enterprise root CA. Headquarters and the video department still have to name their KM Server administrators. To achieve a high level of security for KMS administration, we will implement a multiple- password policy.
The KMS password must not be written to the servers’ hard disks. Floppy disks must be used, and these must be stored together with our backup tapes in a fireproof safe. To start KMS, the administrator must provide the KMS password manually in the startup parameters of the service.

Activity: Designing PKI for Exchange 2000 Server

In this activity, you will design PKIs for two companies that plan to provide advanced security for their Exchange 2000 resources. The companies are Northwind Traders, introduced in Chapter 8, and Woodgrove Bank, introduced in Chapter 3.

Tip

You can use Figure B.26 in Appendix B as a guideline to accomplish this activity.

Scenario: Northwind Traders

Northwind Traders has implemented a sophisticated infrastructure of FE servers and firewalls to support its trading centers across the United States. The trading centers use OWA for messaging. A separate HTTP virtual server is available for each virtual organization. To provide the trading centers with the ability to exchange sensitive and confidential information via e-mail, Northwind Traders is considering an implementation of Certificate Services and Exchange 2000 KM Server.

It is your task to recommend an appropriate advanced security strategy for Northwind Traders:

Taking into consideration that the users of Northwind Traders primarily use OWA, which advanced security strategy would you recommend?

Scenario: Woodgrove Bank

Woodgrove Bank, a fictitious bank in Switzerland, has successfully migrated its Swiss MS Mail environment to Exchange 2000 Server. "It was amazingly simple to integrate Exchange 2000 Server into our global messaging backbone and replace our legacy messaging switch," says Luis Bonifaz, Chief Information Officer at Woodgrove Bank. "Our 600 users in Switzerland now enjoy working with Outlook 2000 in an Exchange 2000 organization. We also have implemented an SMTP-based messaging backbone. However, upper management is concerned that SMTP messages are easily redirected and intercepted. The bank has therefore issued a new security policy, which forces us to enroll the users in all locations with encryption technology. All users, regardless of their messaging environment, must be able to exchange encrypted messages. The same is true for communication with governmental institutions, such as the Internal Revenue Service. As a bank, we have to deal with an enormous amount of sensitive and confidential information, of course." Figure 9.16 depicts the global messaging environment of Woodgrove Bank.

Figure 9.16 - The global messaging environment of Woodgrove Bank

Tip

Woodgrove Bank has thoroughly deployed Active Directory in all locations. The Active Directory environment consists of a single forest with 10 domains. For more information about the Active Directory environment of Woodgrove Bank, refer to Figure 3.17 in Chapter 3, "Assessing the Current Network Environment."

It is your task to recommend an appropriate advanced security strategy for Woodgrove Bank:

Do all Swiss users of Woodgrove Bank work with a client that supports advanced security features?
Woodgrove Bank has not yet deployed a PKI. According to upper management, the bank must remain independent of external entities under all circumstances. How should Woodgrove Bank establish the required PKI for Exchange 2000 Server?
Is Woodgrove Bank able to use strong encryption technology in Switzerland?
Do Woodgrove Bank’s users need to exchange encrypted messages with users in other organizations?
Where should Woodgrove Bank install the KMS of Exchange 2000 Server?
Should Woodgrove Bank consider distributing the KMS administration?
Does Woodgrove Bank require a high level of security for KMS administration?

Lesson Summary

To participate in advanced security (that is, sign or seal messages), users need to obtain public and private keys certified by a trusted CA. You can use Windows 2000 Certificate Services to install a root CA or a subordinate of another root CA in your organization, which ultimately results in a certificate hierarchy. To support Exchange 2000 Server in your PKI by means of KMS, you need to integrate Certificate Services with Active Directory; in other words, you need to install an enterprise root or enterprise subordinate CA.

Even without installing the KMS of Exchange 2000, users can enroll with S/MIME certificates using the Web interface of Certificate Services. An administrator can also accomplish this on behalf of the users by using the Certificates console. These S/MIME certificates can be used with MAPI-based and Internet mail clients. However, without installing a KM server in the Exchange 2000 organization, it is difficult to implement structured management and maintenance of security keys.

KMS allows you to structure the management of advanced security according to the decentralized or centralized approach. To decentralize the environment, deploy a separate KM server in each administrative group. All KM servers in an organization can use the same or different enterprise CAs. For centralized management, install one KM server for the entire organization. Even with a single KMS instance, though, it is advantageous to designate multiple KM Server administrators. Among other things, this allows you to tighten security by implementing a multiple-password policy. Remember to store the KM Server password in a secure place.

It is possible to exchange signed and sealed messages with users in other organizations, provided the other organizations’ root CA’s certificates are trusted and the users have access to each other’s sealing keys. Users can manually exchange their sealing certificates via e-mail and add the other users’ root CA’s certificates to their own security store. However, this tactic doesn’t work well if the number of users is large. If organizations have a close relationship with each other and a high demand for encrypted messages, consider adding the other organizations’ root certificates to the CTL in your forest. All your users then automatically trust the sealing certificates of the other users. The final task is to provide convenient access to these sealing certificates. Manual directory synchronization or access to the other organizations’ directories via LDAP represent possible solutions.