Previous Page TOC Next Page



— 17 —
Exchange Messaging Security with Key Management Server


by Liz Hookway

The Need for Advanced Security (Key Management Server Software)


There are more reasons why you should install the Key Management Server (KMS) software on your system than reasons why you should not. If your users send e-mail to other users via the Internet, if your Exchange servers use the Internet Mail Connector for intra-site connections, or if your company requires encryption on internal or external communications, you will need the encryption features of the Key Management Server. If your users or groupware applications require signature approval on requests, forms, applications, or just verification of messaging origination, you will need the digital signature feature of the Key Management server.

Overview


Microsoft Exchange Key Management Server (KMS) hosts a complex security environment for the messages originating and arriving in your Exchange organization above and beyond the Windows NT and Exchange security subsystem. In general, the KMS tools enable the Exchange administrator to turn on this advanced security for their servers and sites, to determine which users are allowed this advanced security, and to then create unique security tokens for these users. These unique tokens then enable the Exchange users to encrypt their messages, to place digital signatures on their messages, to use both methods, or to use neither.

This chapter focuses on the implementation details for installing KMS in your Exchange organization and getting your KMS server set up correctly. It then covers how to enable security for the clients in your organization and how to perform basic administrative tasks. Finally, the chapter includes a section on how your clients will turn on security from their Exchange client and then subsequently utilize the secure messaging features.

Brief KMS Security and Terminology Introduction


Microsoft bases its advanced security implementation on the X.509 CCITT recommendation. It uses a combination of public and private keys to originate the encryption or digital signature and then uses another combination for the user to decrypt or verify the digital signature. These keys are managed or tracked by certificates.

You can think of certificates as performing similar container functions as an NT Access Token. An NT Access Token is given to a user when he or she logs on to NT and has supplied the correct password. The Access Token that stays with the user while he or she is logged on contains the Security ID (SID) plus specific permissions and rights assigned to the user (groups, permissions, default inheritance).

Similar to an NT Access Token, an Exchange user is assigned a certificate. The user is allowed to access this certificate when he or he provides his assigned secure token/password. This certificate has a unique number and information about the user's security keys, security directories, and other relevant advanced security features. The Certification Authority (CA) subsystem manages the tokens and the corresponding certificates during all encryption, decryption, signatures, verifications, and so on.

The Microsoft Exchange Concepts and Planning guide and the Microsoft Exchange Administrator's Guide go into detail on how the KMS architecture and underlying security subsystems interoperate. Please review these if you would like more information. Also, check the latest Microsoft TechNet CD for extra information and white papers on KMS.

Installation Overview Installation Overview


The first Exchange server in the Exchange Organization that has KMS installed will become the Primary Key Management Server for the entire Exchange Organization. There is only one Key Management Server in the Exchange organization, and it is responsible for storing and managing the security database. It also performs various aspects of security authentication (known as certificate authentication) for the Exchange users. All other Exchange servers in the organization that will use KMS security will utilize the Primary KMS Server for their security authentication needs. See Figure 17.1 for an example of a typical Exchange organization with KMS installed.

Figure 17.1. Key Management Server in an Exchange organization.

If there are multiple sites within the Exchange organization, it will be necessary to configure one Exchange server per site to forward requests to the primary KMS server. This is covered later in the chapter.

The Exchange administrator turns on security for Exchange clients' mailboxes by opening a user's mailbox, enabling advanced security for that user, and then communicating the security token to the user.

After the user receives his or her personal token, the user can then turn on advanced security in his or her profile by enabling security via the Microsoft Exchange Server Information Service and by supplying his or her personal token. The user can then assign his or her own unique password to use this option. When sending e-mail, the user can then choose to encrypt messages, to sign messages digitally, or to do both or neither.

Figure 17.2 gives you an overview of an Exchange server distributing access tokens to users.

Figure 17.2. The KMS server creates user tokens for client distribution.



Advanced security is not available in France, due to government laws barring import of data encryption. If the laws do change, contact Microsoft for availability of this product change.


Installation on Primary Server


The first step to install is to decide which Exchange server in your organization will be the Primary Key Management Server. All Exchange servers in the organization that will use KMS security should be able to access this server. (You might have some Exchange servers that do not use KMS, based on your organization's requirements.)

To install KMS, you need the Exchange server install CD and a blank floppy disk.

  1. Change directories to the architecture platform (I386, ALPHA, MIPS), and you should see an EXCHKM directory.

  2. Run SETUP.EXE to install the Key Management software. You have only one option—a Typical install—but you can choose the install drive and directory. The default directory is Security, but D:\ExchSecure is chosen in Figure 17.3.

  3. Figure 17.3. Choosing a typical install for KMS.

  4. You are asked to select your Country Code (see Figure 17.4). The default is US, but the selections for other countries are available via the drop-down arrow, as shown in Figure 17.5). You are also given the option to utilize a KM Server startup disk.

  5. Figure 17.4. The default country code selection.

    Figure 17.5. The drop-down menu you use to select another country.

  6. A unique password to start up KMS on the Exchange server is generated during the installation and placed in a kmspwd.ini file on the startup floppy disk. Figure 17.6 illustrates what the kmspwd.ini file looks like. Later, when you start up the Key Management Server, the system will look for this file on the startup floppy before starting. You will get a startup error if the startup floppy is not in the drive. You therefore should ensure that the server is in a physically secure area. If you decide not to use a startup floppy disk, then the administrator needs to enter the password manually to start the KMS service.

  7. Figure 17.6. The contents of the kmspwd.ini file.

  8. During the installation, the NT Event Log will log all the setup changes that KMS makes to the Exchange system. These installation functions give you insight into how the CA works with the KMS subsystem, but the administrator does not need to take action.

  9. The setup process is fairly quick. Make sure you look at the password in the kmspwd.ini file and write it down in a secure area.

  10. You can start and stop the Microsoft Exchange Key Manager service by choosing the Service icon from the Control Panel. Make sure that you use the correct account and password to start up this service. I recommend that you use the Microsoft Exchange Service account that starts up Exchange on your server, as I've done in Figure 17.7.

  11. Figure 17.7. KMS service startup parameters.

  12. Figure 17.8 shows the error you get if the startup account is set up incorrectly. Also look in the Event Viewer if you need extra information.

  13. Figure 17.8. The error message for incorrect service account information.

  14. Installation is complete. Now open the Exchange Administrator for your site. You should see two additional containers for your site: CA and Encryption. CA is used by KMS; the administrator cannot modify CA's properties. You learn about the Encryption container in the following sections. You should have a similar site hierarchy to the one shown in Figure 17.9.

Figure 17.9. Exchange Administrator displaying CA and Encryption containers.

Key Management Server (KMS) Administration


As the Exchange administrator, you are responsible for overall security for the Exchange sites in the entire Exchange organization. You are responsible for enabling the users in your organization to utilize the KMS security features and for distributing personal security tokens to them. This section focuses on how to administer the KMS security features within your Exchange organization. Administration is not complete without backup and restore functionality, so this section concludes with a review of backup for the KMS security database.

Site Administration


After KMS is up and running, you need to change the default password of the KMS administrator.

  1. Open the Exchange Administrator, and find the Encryption container for your site.

  2. Select the Security tab in the Encryption Properties dialog box, as shown in Figure 17.10.

  3. Figure 17.10. The Security tab for the KMS encryption container.

  4. Choose Key Management Server Administrators, and enter password as the default password in the Key Management Server Password dialog box, as shown in Figure 17.11. (You should change this password—see step 5.)

    Exchange gives you an option to continue working for five minutes without having to reenter the password. If you do not select this option, Exchange continually prompts you whenever you attempt to change advanced security attributes. This feature ensures that if you walk away from the terminal, no one else can enable advanced security.

  5. Figure 17.11. The Key Management Server Password dialog box.

  6. The Key Management Server Administrators dialog box then enables you to add users to also be KMS Administrators, as shown in Figure 17.12. Here is also where you would change the KMS server password from password to a unique password.

Figure 17.12. KMS server administrative functions.

Mailbox Security Administration


Now that the site administration is out of the way, you can begin to enable advanced security for the Exchange users at your site.

Security Enabling

Use the simport command-line utility if you want to batch-add a group of users. Otherwise, highlight an Exchange mailbox (not custom recipients, distribution lists, or public folders because they are not allowed to use KMS security). Select the Security tab of the Properties dialog box. Figure 17.13 shows the Properties dialog box for Clint Jones.

Figure 17.13. The Properties dialog box for Clint Jones.

This page contains a few options, but to enable security initially, first choose Enable Advanced Security. A token is then generated for the user, as shown in Figure 17.14. Give this token to the user in a secure manner, as in a sheet of paper or a personal phone call. Do not send this information to the user as an e-mail.

Figure 17.14. A user security token.

Recover Security Key

If a user forgets his or her security token, you can create a new one by choosing Recover Security Key from the Security tab of the Properties dialog box. KMS doesn't recover the actual security token, because a new token is established. Figure 17.15 shows a new token, and now the old one has become invalid.

Figure 17.15. KMS recovery and creation of user security token.

Revoke Advanced Security

Choose the Revoke Advanced Security button from the Security tab of the Properties dialog box if you want to revoke a user's rights to advanced security. The user's token becomes invalid, and he or she cannot use encryption or digital signatures.

Forget Remembered Password

Earlier in the KMS administration process, you are prompted whether you want the system to remember the KMS password for five minutes. This feature enables you to perform advanced security administration for multiple users without being prompted every time. If you are finished with administration, however, you might want to choose the Forget Remembered Password button from the Security tab of the Properties dialog box. Choosing this button forces the system to forget the password and prompts you or whoever is on the system next for the correct password.

Valid From/To

The Valid from and Valid to fields on the Security tab of the Properties dialog box display how long the user's token is valid. The default period is one year. A new certificate is automatically generated after the original token expires.

Back Up and Restore


As Exchange administrator, you should back up the KMS database and security files. Use the NT Backup tool (in the Administrative Tools Program Group) to back up the installation path for the security files. The key directory to back up is the mgrent directory. The default installation stores it on c:\Security\mgrent. Although you can back up the files online (while the KMS service is running), you might want to back up these files regularly when the Exchange server is down. The Restore process is similar. Restore c:\Security\mgrent to the KMS Exchange server via the NT Backup tool.

Furthermore, if you decide to move the KMS server from one Exchange server to another, check the documentation or the Microsoft TechNet CD for the latest details. Although moving servers is supported, I recommend that you execute this moving process on two test systems first to perfect the transition.

Installing on Secondary Servers per Site


After you install KMS on your primary KMS Exchange server, you need to install KMS on at least one Exchange server per separate site in your Exchange organization. So, each site in the Exchange organization could host a KMS secondary server, unless the primary server is already in the site. The secondary servers do not perform security authentication, nor do they store or manage the security database. They forward and manage security requests to the Primary KMS server. This capability enables users in all the Exchange sites to use advanced security between the organization's Exchange users. Remember, this functionality is only for Exchange mailboxes, not for custom recipients nor distribution lists. Also, only one Primary KMS server exists in the Exchange organization.

The installation procedure for secondary servers is similar to that of primary servers, except that you are not prompted for a floppy disk for the KMS token. (You should make sure that you are connected to the primary server during the KMS installation. Otherwise, KMS acts as though it is installing the primary, and you are prompted for a floppy disk.) On a secondary KMS server, you are prompted to contact the KMS administrator at your primary site for the password. A message like the one shown in Figure 17.16 should appear during the KMS installation.

Figure 17.16. Install message at secondary server.

Using the KMS Security Subsystem


The following sections describe the use of the KMS features in the client. Microsoft Exchange clients that support advanced security are Windows NT, Windows 95, Windows 3.x, and the Macintosh client. The UNIX and MS-DOS clients do not support advanced security.

Client Security Setup


After you log on to Exchange as a client, choose Tools | Options, and then select the Security tab of the Options dialog box, as shown in Figure 17.17.

Figure 17.17. The Security tab in Exchange Client.

Next, choose the Set Up Advanced Security button. The Setup Advanced Security dialog box then appears, as shown in Figure 17.18.

Figure 17.18. The Setup Advanced Security dialog box.

In this dialog box, you should type in the unique token that the KMS administrator gave you (here it is HDRMDHTW) and create a security file filename.epf. (This file is not used by you, the client, but by the KMS subsystem. It will contain your digital signature, your private keys, and many other KMS objects. You can view this file in Notepad, but most of it is encrypted.) Next, select your own password (choosing your own password normally makes it a bit easier to remember).

After you click OK, you should see a message like the one shown in Figure 17.19.

Figure 17.19. The security request message window.

In a few minutes, the client receives e-mail from the system attendant, with the Subject Line: Reply from Security Authority. When you attempt to read this message, you get a window prompt like the one shown in Figure 17.20.

Figure 17.20. Security acknowledgment e-mail.

You are then informed that you are successfully security-enabled, and you can digitally sign and encrypt messages. Enter your security password to complete the process. The message is then deleted from your inbox.

Composing a Message for Encryption and Digital Signatures


Now that you are enabled for security, you can use a few different methods to add security to your messages. Choose Options | Tools, and then select Security. In the Security dialog box, you can choose to always encrypt your messages or add a digital signature.

You can, however, choose security when you create the message as well. When you create a message in the Exchange client, you will find yourself placed in a Compose Message form. When you are in the Compose Message form, you can add shortcut icons by choosing Tools | Customize Toolbar and then adding the two icons Seal Message with Encryption and Digitally Sign Message.

After you select Encryption or the Digital Signature via the icons in your toolbar, and after you choose to send the message, you are prompted for your security password (not the initial token the administrator gave you), as shown in Figure 17.21.

Figure 17.21. The security password prompt.

If the Primary KMS server does not validate your request to place security on this message, it may be because your security certificate has not been processed back at the Primary KMS server yet. You might get a warning like the one shown in Figure 17.22.

Figure 17.22. The invalid security certificate message.

Furthermore, if the message recipients cannot process encrypted messages, you might get a warning message requesting you to not encrypt the message, cancel sending the message, or choose Help, as shown in Figure 17.23.

Figure 17.23. Recipients are not able to process encrypted message.

Receiving the Message


If you receive an encrypted or digitally signed message from someone, you can view the message properties to ensure that encryption was successful and that the signature is authentic.

Digital Signature Verification

A message that has been digitally signed is displayed in the inbox with an icon that has a pen tip pointing to the envelope, as in signing the envelope. To verify the authenticity of a message, highlight the message in the inbox, choose File | Properties, and then select the Security tab, as shown in Figure 17.24.

Figure 17.24. The Security property sheet of a received signed message.

In this dialog box, choose Verify Digital Signature, and Microsoft Exchange then verifies the authenticity of the signature and gives additional information on verification results, as shown in Figure 17.25.

Figure 17.25. Results of digital signature verification.

Encryption Information

A message that has been encrypted is displayed in the inbox with a lock on the envelope. Again, to verify the encryption of a message, highlight the message in the inbox, choose File | Properties, and then select the Security tab. In Figure 17.26, you can see the message was encrypted successfully, and it was not digitally signed.

Figure 17.26. The Security property sheet of received encrypted message.

Note that these messages were encrypted or signed once on their delivery to their first destination. If these messages are replied to, forwarded, and so on, they will not be secure, and they can be altered. If you want security, you must request encryption or digital signatures when sending these messages again.

Summary


The Key Management Server feature will assist your organization in ensuring your e-mail messages are more secure. The capability to encrypt messages is not only important for basic inter-office e-mail, but most important when your messages travel across the Internet. The digital signature feature will play an increasingly important role in organizations that are trying to decrease the paper trail caused when signature approvals are required on forms and requests.

Previous Page Page Top TOC Next Page