Lesson 2: Advanced Security Features

KMS creates and manages the PKI of your Exchange 2000 organization. It integrates with Windows 2000 Certificate Services, which in turn may be part of a larger PKI that extends beyond the Active Directory forest of your organization. You can install the KMS on one server per administrative group, which turns this machine into a Key Management Server (KM Server). A KM Server is able to service multiple administrative groups or the entire Exchange 2000 organization.

This lesson describes the architecture of the KM Server along with its components, important files, and database. It also explains the role of the KM administrator, covers KMS installation, and details the process of enabling and using advanced security.


At the end of this lesson, you will be able to:

  • Install KMS.
  • Describe the purpose of KM Server-specific keys and security passwords.
  • Enable and maintain advanced security for your users.
  • Sign and seal messages.

Estimated time to complete this lesson: 90 minutes


KM Server Architecture

Two main components form a functioning KM Server: Microsoft Exchange KMS and a storage database. Several other components, including the Exchange Advanced Security snap-in (KMSSNAPIN.DLL) and a cryptographic service provider (CSP) for the Microsoft Cryptographic Application Programming Interface (CryptoAPI), are also required to manage and use advanced security features (see Figure 19.7).

Microsoft Exchange Key Management Service

KMS, which runs on the KM Server, is the active component that processes all advanced security requests. The Exchange Advanced Security snap-in, integrated into Exchange System Manager, and the Information Store service are its direct communication partners. This service also forwards certificate requests in Public Key Cryptography Standard (PKCS) #10 format to Certificate Services on behalf of users (see Figure 19.7).

NOTE


The Exchange Advanced Security tool is available as a stand-alone and an extension snap-in. You may find it useful to combine this tool with the Certification Authority and the Certificates snap-ins to create a customized Microsoft Management Console (MMC) utility for advanced security administration.

click to view at full size

Figure 19.7 Key Management Service architecture

KM Database

The KMS maintains a database, which stores advanced security information for Exchange 2000 users. This database can be found on the KM Server under \Program Files\Exchsrvr\KMSData. Only one KM database can exist in an administrative group. The users' public and private sealing keys are temporarily placed in this database during the process of enabling advanced security. The KM database also permanently contains the private sealing keys for all users that belong to this KM Server. A KM Server must maintain these keys to keep a security key history for all users that have been enabled with advanced security. This history is required for key recovery, key revocation, and other key management tasks.

IMPORTANT


You must make sure that the KM database is not exposed to unauthorized persons. It is also important to include the KM database in regular server backups to save the security key history of all users who have been enabled with advanced security.

Information Store

During the process of enabling advanced security, the KMS communicates with the Information Store service to handle e-mail communication. The Information Store maintains the System Attendant mailbox through which the KM Server receives request messages from users. This mailbox is also used to send users an enrollment notification and their private and public sealing keys in encrypted messages. The process of enabling advanced security is explained later in this lesson.

Administrator Components

Two configuration objects are important for managing advanced security when using Exchange System Manager: the Encryption Configuration object and the Key Manager object, both of which are located under the Advanced Security container, which is displayed in the corresponding administrative group.

In addition, you can manage security keys and certificates on a per-user basis in Active Directory Users and Computers. Published certificates are displayed in each user account's Published Certificates tab (activate Advanced Features to display this tab), and the Exchange Features tab provides access to the E-Mail Security feature. Selecting E-Mail Security and clicking Properties launches the E-Mail Security dialog box after you enter your KM administrator password. There you can enroll, recover, and revoke advanced security features.

NOTE


To manage advanced security, make sure RPC communication to the KM Server works.

KM Administrator

A KM administrator is a privileged Exchange 2000 administrator who can enable, revoke, and recover advanced security features. By default, only the person who installed the KM Server is a KM administrator. You can designate additional KM administrators using the Administrators tab of the Key Manager object. Click Add to add additional accounts. You can also revoke KM administrators by clicking Remove. You should use the Administrators tab immediately after KMS installation to change your KM administrator password. The default password is password.

NOTE


The KM administrator password is case sensitive and must contain at least six characters.

Multiple KM Administrator Passwords

By default, every KM administrator is able to perform administrative tasks right away. You can use the Passwords tab of the Key Manager object to enforce a policy that requires two or more administrators to specify their passwords before advanced security administration is allowed. This can help to achieve a higher level of security. When you examine the Key Management Service Login dialog box that repeatedly asks you for your KM administrator password when managing advanced security, you will find information about the total number of administrators required and the total number of administrators that have entered their passwords.

TIP


The most important password policy options, Add/Delete Administrators and Edit Multiple Password Policies, should always require more passwords than the remaining options, Recover A User's Keys, Revoke A User's Keys, Change Certificate Versions, and Import/Export User Records.

Exercise 3: Installing KMS

In this exercise you will install the KMS of Exchange 2000 Server. You will install this service on BLUESKY-SRV2, which turns this server into a KM Server.

To view a multimedia demonstration that displays how to perform this procedure, run the EX3CH19*.AVI files from the \Exercise_Information\Chapter19 folder on the Supplemental Course Materials CD.

Prerequisites

  • Completed Exercise 2, earlier in this chapter.
  • Make sure BLUESKY-SRV1 and BLUESKY-SRV2 are operational, and log on to both machines as Administrator.
  • Insert the Exchange 2000 Server installation CD into the CD-ROM drive of BLUESKY-SRV2.

To install the Key Management Service of Exchange 2000 Server

  1. On BLUESKY-SRV2, click Start, point to Settings, and click Control Panel.
  2. In the Control Panel, launch Add/Remove Programs, and, in the Add/Remove Programs window, select Microsoft Exchange 2000, and click Change/Remove.
  3. On the welcome screen of the Microsoft Exchange 2000 Installation Wizard, click Next.
  4. On the Component Selection wizard screen, under Action, for both the Microsoft Exchange 2000 and the Microsoft Exchange Messaging And Collaboration Services category, select Change.
  5. Under Action for Microsoft Exchange Key Management Service, select Install, and then click Next.
  6. On the Key Management Service Information wizard screen, select the Read Password From Disk option, and then click Next (see Figure 19.8).
  7. On the second Key Management Service Information wizard screen, under Master Copy Of Startup Password, type c:\. Under Backup Copy Of Startup Password, type c:\winnt, and then click Next.
  8. On the Component Summary wizard screen, click Next to begin the installation.
  9. On the final wizard screen, click Finish. Close the Add/Remove Programs window and the Control Panel.

    click to view at full size

    Figure 19.8 Installing the Key Management Service of Exchange 2000 Server

  10. On BLUESKY-SRV1, launch the Certification Authority snap-in from the Administrative Tools program group.
  11. In the console tree, right-click Blue Sky Airlines Root CA, and then select Properties.
  12. Click on the Security tab, click Add, and, in the Select Users, Computers, Or Groups dialog box, select the computer account BLUESKY-SRV2, which is the KMS in the organization of Blue Sky Airlines. Click Add, and then click OK.
  13. In the Security tab, make sure BLUESKY-SRV2 is selected, and then select the Allow check box for the Manage permission to grant the server all rights for the CA (see Figure 19.9).
  14. Click OK, and close the Certification Authority snap-in.
  15. On BLUESKY-SRV2, launch the Services snap-in from the Administrative Tools program group.
  16. In the list of services, right-click Microsoft Exchange Key Management Service, then click Start.
  17. Verify that the Key Management Service was started successfully, and then close the Services snap-in.

    click to view at full size

    Figure 19.9 Granting Key Management Service Manage permissions

Exercise Summary

KMS can be installed using Exchange 2000 Setup in maintenance mode. A reference to an Enterprise CA must exist in the Active Directory forest. You also need to add the KM Server account to the server running Certificate Services. The KM Server requires Manage permissions to be able to revoke certificates. It must be added to all Certificate Services CAs used to issue certificates for Exchange 2000 Server. During the installation, you need to specify how to maintain the KM Server password. It is ideal not to store this password electronically, but you have the option to do so if this is appropriate. Storing the password in a file allows you to start KMS more conveniently. For convenience, not for maximal security, this exercise suggested storing the KMS password on the server's hard disk. For more reliable security, store the password on floppy disks, and keep these disks in a secure place.

Server Keys and Passwords

Cryptographic keys, stored in the KM database, must be protected from unauthorized access; otherwise, advanced security would be useless. Several security keys and passwords are required for this purpose.

KM Database Master Encryption Key

The KM Database Master Encryption key is used to encrypt and decrypt the KM database. The KMS and every designated KM administrator maintaining advanced security must have access to this key. However, the KM Database Master Encryption key itself is also encrypted to prevent unauthorized access. The number of designated KM administrators determines the number of times (+1 for the KMS itself) that the KM Database Master Encryption key is encrypted. The system uses each of the KM administrator passwords plus the KM Server password for this purpose, creating a lockbox for each password. KM administrators and the KMS use their password to open their corresponding lockbox to retrieve the KM Database Master Encryption key. The KM Database Master Encryption key is accessed when the KMS starts and opens the KM database and when KM administrators need to manage advanced security.

KM Server Password

As illustrated, the KM Server password is generated and possibly written to a text file named KMSERVER.PWD on a floppy or the hard disk during the KM Server installation. You must provide this password each time you start KMS, either through the password file or by typing it in the Startup Parameters box in the service's startup properties (and then click Start in the General tab of the Services tool). Without a valid KM Server password, KMS will not be able to start.

At times you might receive an error message that says Could Not Start The Microsoft Exchange Key Management Service. To get more detailed information, check the application event log. If the application event log contains an event with the Event ID 5057: The Supplied Password Is Not Valid, you should check to see if the KMSERVER.PWD file contains the correct password. If this file is corrupted, you must use the backup copy or specify the password manually using the service's startup parameters. It is important to keep the KMSERVER.PWD file in a secured place.

If you have chosen to save the KM Server password on a floppy or hard disk during installation, two REG_SZ values called MasterPasswordPath and BackupPasswordPath, pointing to the location of their corresponding KMSERVER.PWD files, are written to the Registry under the following location:

 HKEY_LOCAL_MACHINE    \Software       \Microsoft           \Exchange              \KMServer 

If MasterPasswordPath points to a floppy drive (that is, the A drive), you need to insert the disk that contains KMSERVER.PWD into the server's floppy drive during the service startup. This is also the reason KMS is set to manual startup by default. You can also start and stop KMS from a remote computer using Exchange System Manager or the stand-alone Exchange Advanced Security snap-in. Right-click Key Manager, point to All Tasks, and then select Start Service or Stop Service. If the KM Server password was provided in a KMSERVER.PWD file and is available to the KMS locally, the service will start. You can also start the KMS remotely without KMSERVER.PWD. In this case, set the value of MasterPasswordPath to an empty string (""). This will cause Exchange System Manager to display the Service Start Up Password dialog box, where you must type the KM Server password manually.

NOTE


When using Exchange System Manager locally on the KM Server, it is possible to conveniently change the startup password as well as the password file location. Right-click Key Manager, point to All Tasks, and select Change Startup Password. You will reach the Change Startup Password dialog box, where you can specify settings as during the KMS installation.

Stage 1: Enabling Advanced Security—The Administrator's Side

Installation of a KM Server in an organization does not mean that every user has been enabled with advanced security. In fact, no user can sign or seal messages by default. The KM administrator must first enable advanced security for the users, and each end user must complete this process using Outlook 2000, as explained in the next section.

Steps in the KM Administrator's Process

Although you can use both Active Directory Users and Computers (E-mail Security in the Exchange Features tab) as well as the Exchange Advanced Security snap-in to enable advanced security for individual users, only the Exchange Advanced Security snap-in (stand-alone or in Exchange System Manager) can be used to enroll all users in an administrative group or a subset of users at once. Right-click Key Manager, point to All Tasks, and select Enroll Users. You will be asked for your KM administrator password, and, after that, an Enroll Users Selection dialog box will be displayed, where you can choose between two options. You can either accept the default Display An Alphabetic List Of User Names From The Global Address Book option or activate the Display Mailbox Stores, Exchange Servers, And Administrative Groups Of Eligible Users option. The first option provides you with the ability to select one or more users directly from the global address book, and the latter option allows you to enable users based on mailbox stores and home servers. Only users that have not yet been enrolled can be selected.

Generated Security Information

The most important information generated during Stage 1 is a 12-character security key—a temporary user-specific password. The sealing key pair is also created. The security token is written to a file called ENROLL.LOG in the \Program Files\Exchsrvr\KMSData directory when working with Exchange System Manager or displayed on the screen in a message box when using Active Directory Users and Computers. The sealing key pair is stored temporarily in the KM database until the user downloads this information during Stage 2. You must pass the 12-character security token to the user in a secure manner so he or she can complete the process of enabling advanced security.

Distributing Security Tokens in Enrollment Messages

You may distribute the security token to your users in e-mail messages, which is particularly interesting if you plan to enroll multiple users at once. In this case, in the Key Manager property sheet, click on the Enrollment tab and, under Token Distribution, select the Send Token In An E-Mail check box. However, keep in mind that the enrollment message cannot be encrypted. If an unauthorized person gains access to the security token, this person may decrypt the communication between the KM Server and the client during Stage 2, allowing the intruder to steal the public signing key and the private sealing key. The public signing key is less important, but the private sealing key allows the intruder to decrypt the user's sealed messages. If you want to use advanced security effectively, you must be careful when handling security information.

When you examine the Enrollment tab, you will notice that the Customize Message button is enabled as soon as you select the Send Token In An E-Mail check box, which allows you to customize the enrollment message. Most important in this message is the placeholder %TOKEN%, which will be replaced with the actual security token. You may remove this placeholder to avoid sending this sensitive information to your users in an unencrypted e-mail. However, the enrollment message may still inform the users about the process of enabling advanced security. Without the security token in the enrollment message, the users will have to contact you to get this information. Independent of the enrollment message, the security token is displayed in a message box or written to the ENROLL.LOG file.

Stage 2: Enabling Advanced Security—The Client's Side

In Stage 2, the user sends an e-mail request to the KM Server, which processes the request, forwards it to Certificate Services, and retrieves the approved certificates. If the certificate request is processed successfully, a response is sent back to the user. The user enables advanced security by opening the response, which means that he or she can sign and seal messages.

NOTE


KMS can forward certificate requests to any Enterprise CA in the forest. If all servers running Certificate Services are unavailable, user requests are queued for up to 24 hours, after which time the user will have to reissue the request.

Generated Security Information

To complete Stage 2 of enabling advanced security, users must use Outlook—ideally Outlook 2000—because only MAPI-based clients can generate the required information, such as the user's public and private signing keys and X.509 certificates. The user's public and private sealing keys were created and placed in the KM database during Stage 1. This information will be received from the KM Server at the end of Stage 2.

The following security information is generated:

  • Public and private signing keys
  • Signing and sealing X.509 certificate requests that identify the individual making the request uniquely.
  • User's security password, which is used to encrypt the private keys

Initial Steps on the Client Side

To begin the process of enabling advanced security on the client side in Outlook 2000, open the Tools menu, and click Options to display the Options dialog box. Click on the Security tab, and then click Get A Digital ID. Make sure that you select the Set Up Security For Me On The Exchange Server option because you are requesting certificates from the KMS and not a third-party certification authority. When you click OK, a Setup Advanced Security dialog box will appear, where you need to define a Digital ID Name and type your 12-character security token. After that, you are prompted to define a security password for your new digital ID.

Using Outlook 2000 on Microsoft Windows 2000 Professional, your private keys will be encrypted using the specified security password and stored under the following location in the Registry:

 HKEY_CURRENT_USER     \Software        \Microsoft          \Cryptography            \Microsoft Exchange Cryptographic Provider               \<Digital ID Name> 

The private signing key is stored in your digital ID right away, but the public signing key must first be sent as part of an X.509 certificate request in an e-mail message to the KM Server. This e-mail message will be encrypted using the 12-character security token, and it is addressed to the System Attendant mailbox. A message box will inform you that the message has been sent successfully.

NOTE


A single Windows 2000 user can have multiple digital IDs. Multiple digital IDs may be required if you work with different MAPI profiles to access different mailboxes on the same workstation.

Receiving the KM Server Response

The KM Server will retrieve the request message from the System Attendant mailbox, will request the approval of the certificates from an Enterprise CA, and will return the approved certificates together with the public and private sealing keys in another encrypted message to the client. The response message will make its way through the messaging network and will appear in your Inbox like any other e-mail message. The icon will show an envelope locked by a padlock. The originator is the System Attendant, and the subject is Reply From Security Authority. When you double-click this message, you will be asked for your security password. The security information will be retrieved from the message and placed in your security store. Outlook 2000 will also publish your public sealing certificate, which includes your public sealing key, in Active Directory (userCertificate and userSMIMECertificate attributes of your user account). You have to work online to successfully enable advanced security. A message box informs you that you can now send and receive signed and sealed messages.

NOTE


If you have installed Certificate Services to form your own root CA, the self-issued root certificate will be added to the Trusted Root Certification Authorities store on the local computer during the process of enabling advanced security. Only certificates with a valid certification path up to a root certificate that is in the Trusted Root Certification Authorities store are trusted and can be used.

The following information is placed in the KM Server response message:

  • The certificate of the approving Enterprise CA
  • Private sealing key
  • Signing and sealing certificates

Exchanging Signed Messages

With message signing, a message checksum is built, encrypted, and attached to the message. The receiving user builds a checksum and compares it to the decrypted original. If the checksums are identical, the message has not been modified during transmission.

Signing a Message

The client uses a complex mathematical function to derive a unique 128-bit value from the message that you want to sign. This value is called a hash or message digest; the process of building this value is known as hashing. To protect the original digest from unauthorized access, it is encrypted using your private signing key. The encrypted message digest is the digital signature, and a message is considered signed if the digital signature has been attached to it. In addition to the actual digital signature, the client will add your signing certificate, which includes your public signing key, to the message before sending it.

Verifying a Signed Message

When a recipient of a signed message verifies the digital signature, the sender's public signing key is extracted from the certificate enclosed in the message, and then the digital signature is decrypted to retrieve the original message digest. The client then performs the hashing on the original message itself to retrieve the recipient's message digest. The sender and recipient's digests are compared, and if they match, the sender truly sent the message and it was not tampered with on its way to the recipient's mailbox (see Figure 19.10).

click to view at full size

Figure 19.10 Sending and verifying signed messages

Exchanging Sealed Messages

During the sealing process, the contents of a message and all attachments are encrypted. The sealing process is initiated by clicking the Send button if you have elected to encrypt the message.

Sending a Sealed Message

If you want to send a sealed message, you will compose the message as usual, but, in the Message Options dialog box, you need to select the Encrypt Message Contents And Attachments check box. When you click Send, you will be prompted for your security password so that Outlook can encrypt and send the message.

Outlook will contact Active Directory to obtain a copy of the sealing certificate for each recipient. The sealing certificate contains the public sealing key as well as information about the supported encryption method. The maximum common encryption method for all recipients is determined and is used to encrypt the message. Using the strongest common encryption method, the client generates a bulk encryption key for sealing (and later unsealing) the message. However, before the bulk encryption key can be attached to the message, it must be encrypted using each recipient's public sealing key. In other words, the client creates a bulk encryption lockbox for each recipient. Each lockbox is added to the encrypted message to provide the bulk encryption key (in its encrypted form) to all recipients (see Figure 19.11). The client may also add the sender's sealing certificate to the message so the originator can read the sealed message, as it is stored in the Sent Items folder.

click to view at full size

Figure 19.11 Sending a sealed message

Unsealing a Sealed Message

When you receive a sealed message and open it, the message must be unsealed. Consequently, you will be prompted for your security password to retrieve your private sealing key from the security store. The client uses this key to decrypt (open) your bulk encryption lockbox. This decryption returns the bulk encryption key, which can then be used to decrypt the message.

Exercise 4: Configuring and Using Advanced Security

In this exercise you will set up additional KM administrators and generate security tokens for all users using Exchange System Manager. You will then enable advanced security in Outlook 2000 and send signed and sealed messages.

To view a multimedia demonstration that displays how to perform this procedure, run the EX4CH19*.AVI files from the \Exercise_Information\Chapter19 folder on the Supplemental Course Materials CD.

Prerequisites

  • Complete Exercise 3, earlier in this lesson.
  • Start KMS on BLUESKY-SRV2.
  • Log on as Administrator to BLUESKY-SRV1, BLUESKY-SRV2, and BLUESKY-WKSTA.

To configure, enable, and use advanced security

  1. On BLUESKY-SRV1, launch Exchange System Manager from the Microsoft Exchange program group.
  2. In the console tree, right-click the organization object Blue Sky Airlines (Exchange), and then select Delegate Control.
  3. On the welcome wizard screen, click Next.
  4. On the Users Or Groups wizard screen, click Add, and, in the Delegate Control dialog box, click Browse to display the Select Users, Computers, Or Groups dialog box, where you need to double-click the user account of Carl Titmouse.
  5. In the Delegate Control dialog box, under Role, select Exchange Full Administrator, then click OK.
  6. On the Users Or Groups wizard screen, click Next. On the final wizard screen, click Finish.
  7. In the console tree, expand Administrative Groups and First Administrative Group, and then select Advanced Security.
  8. In the details pane, right-click Key Manager, and select Properties.
  9. In the Key Management Service Login dialog box, type password, and click OK.

    NOTE


    The default administrator password is password.

  10. In the Key Management Properties dialog box, click on the Administrators tab, type password again, and then click OK.
  11. Click Add, and, in the list of accounts, double-click the account of Carl Titmouse.
  12. In the Set Administrator Password dialog box, under New Password and Verify Password, type password, and then click OK. This is the initial KMS administrator password for Carl Titmouse (see Figure 19.12).

    click to view at full size

    Figure 19.12 Defining additional KMS administrators

  13. Click on the Enrollment tab, type password again, and click OK. In the Enrollment tab, select the Send Token In An E-Mail check box.
  14. Click Customize Message, and delete the last paragraph explaining how to enable Advanced Security using earlier versions of Outlook. Click OK twice, type password again, and click OK.
  15. Right-click Key Manager, point to All Tasks, and then select Enroll Users.
  16. In the Key Management Service Login dialog box, type password, and then click OK.
  17. In the Enroll Users Selection dialog box, select Display Mailbox Stores, Exchange Servers, And Administrative Groups Of Eligible Users, and then click OK.
  18. In the Enroll Users dialog box, expand all containers, select First Administrative Group, and notice that all subcontainers are selected automatically (see Figure 19.13).
  19. Click Enroll, and, in the Enroll Users dialog box informing you that the selected users were successfully enrolled, click OK.
  20. In the Enroll Users dialog box, click Close.

    click to view at full size

    Figure 19.13 Enrolling all users in an administrative group in bulk

  21. On BLUESKY-SRV2, launch Windows Explorer and open the \Program Files\Exchsrvr\KMSData directory.
  22. Double-click on the ENROLL.LOG file to display its contents in Notepad. Check for the security token of CarlT and Administrator (you may note down these security tokens to provide them manually during the stage of enabling advanced security in Outlook 2000). Close Notepad and Windows Explorer.
  23. To practice key recovery and send an enrollment message, launch Active Directory Users and Computers, select the Users container, and then double-click on the Administrator (or Carl Titmouse) account.
  24. Click on the Exchange Features tab, select E-mail Security, and then click Properties. Provide your KMS password and click OK.
  25. In the E-mail Security dialog box, click Recover. In the Microsoft Exchange Administrator dialog box, click Send Enrollment Message.
  26. In the Microsoft Exchange Administrator dialog box displaying the security token, click OK.
  27. Click OK twice to close all dialog boxes. After that, repeat the steps to recover the keys for Carl Titmouse, and then close Active Directory Users and Computers.
  28. On BLUESKY-WKSTA, launch Outlook 2000, and make sure you are connected to the mailbox of the Administrator (or CarlT later on).
  29. Open the message from the System Attendant with the subject Advanced Security, copy your temporary advanced security key into the clipboard, and then close the message again.
  30. On the Tools menu, click Options to display the Options dialog box.
  31. Click on the Security tab, click Get A Digital ID, select the Set Up Security For Me On The Exchange Server option, and then click OK (see Figure 19.14).

    click to view at full size

    Figure 19.14 Enabling advanced security in Outlook 2000

  32. In the Setup Advanced Security dialog box, under Digital ID Name, type AdminID (or CarlID later on), and, under Token, paste your temporary advanced security key from the clipboard by right-clicking the Token text box and selecting Paste (or type the security key manually), and then click OK.
  33. A Microsoft Outlook Security Password dialog box appears, asking you to define a security password for your new digital ID. In the Password and Confirm boxes, type password, and then click OK.
  34. A Microsoft Outlook dialog box appears, stating that the KM server will notify you when your request has been processed. This is accomplished using an e-mail message. Click OK.
  35. The Options dialog box reappears. Click OK, and then wait for an e-mail message with the subject Reply From Security Authority, informing you that you have been enabled for Advanced Security. If it takes more than a minute to get this message, double-check whether the Microsoft Exchange KMS is started on BLUESKY-SRV2. If it is, but the response is still outstanding, reboot BLUESKY-SRV1 and BLUESKY-SRV2.
  36. When the message appears in your Inbox, double-click the message. This displays a Microsoft Outlook dialog box requesting your security password. In the Password box, type password. Select the Remember Password For 30 Minutes check box, and then click OK.
  37. A Root Certificate Store dialog box will appear, asking you whether to add the self-issued certificate of the CA to the root store. Click Yes.
  38. The Reply From Security Authority message is opened, indicating that you have been successfully security enabled. Delete this message as well as the message from the System Attendant with the subject Advanced Security.
  39. Log off as Administrator, and log on as Carl Titmouse, and then repeat Steps 21 through 32 as Carl Titmouse.
  40. Log off as Carl Titmouse and log on as Administrator, launch Outlook 2000, and compose a new message.
  41. In the Untitled - Message (Rich Text) window, displaying a blank message form, click To to display the Select Names dialog box. Double-click Carl Titmouse and then click OK.
  42. In the Subject box, type Signed and Sealed Message.
  43. In the message body, type This signed message allows you to verify it's originator and whether it was tampered with on its way to your inbox.Besides, this message was sealed. Therefore, you are the only one who is able to read it.
  44. On the toolbar, click Options. In the Message Options dialog box, enable the Encrypt Message Contents And Attachments and Add Digital Signature To Outgoing Message check boxes (see Figure 19.15). Click Close.

    click to view at full size

    Figure 19.15 Sending signed and sealed messages using Outlook 2000

  45. On the toolbar, click Send.
  46. The Microsoft Outlook Security Logon dialog box appears. In the Security Password box, type password, and then click OK. (If a Non-Secure Recipients dialog box appears, asking you to send the message unencrypted, click Cancel, and wait for the modified directory information of the mailbox Carl Titmouse to be replicated to BLUESKY-SRV2.) You might need to wait for a few minutes.
  47. Log off as Administrator and log on as Carl Titmouse, launch Outlook 2000, and check for the Signed And Sealed Message from Administrator. Notice the icon associated with this encrypted message, and then double-click the message.
  48. The Microsoft Outlook Security Logon dialog box appears. In the Security Password box, type password, and then click OK. If a dialog box appears, informing you that a valid certificate revocation list could not be obtained, click OK.
  49. The Signed And Sealed Message - Message (HTML) window is displayed, showing Security information in the header area underneath the Subject. Notice that the S/MIME message was received in HTML format. The Microsoft Outlook Rich Text format is automatically converted into HTML to ensure maximal compatibility with other e-mail clients.
  50. Verify that there are two small buttons displayed to the right of the Security information: Verify Encryption Certificate and Verify Digital Signature. Click the Verify Digital Signature button.
  51. In the Digital Signature: Valid dialog box displaying the verification results, notice that the signature is valid and that the message was signed by CN=administrator; CN=recipients; OU=first administrative group; O=blue sky airlines.
  52. Click View Certificate, and, in the View Certificate dialog box, click on the Certificate Path tab. Notice that the certificate was issued by the Blue Sky Airlines Root CA.
  53. Click OK twice, close the message, open Outlook's File menu, and then click Exit And Log Off.

Exercise Summary

At a minimum, administrator rights are required for the administrative group in which the KMS is located to manage the KM Server. The primary task of the KM administrator is to enable users with advanced security. You can enroll mailboxes individually or multiple mailboxes in bulk for entire administrative groups, servers, or individual mailbox stores. In all cases, a 12-character security token is generated for each user. It is convenient to use e-mail messages for the purpose of distributing the security token to the users, but it is more secure to provide these temporary security keys manually. Using the security token, users can complete the process of enabling advanced security in Outlook 2000.

KMS for Multiple Administrative Groups

In environments with multiple administrative groups, you may install a separate KMS in each and grant these servers Manage permissions on the Enterprise CA. In this way, you can distribute advanced security administration. If you want to centralize the management of advanced security, on the other hand, you should only install one KM Server. In this case, you need to create a reference to the central KMS in remote administrative groups. Open the property sheet of the Encryption Configuration object under Advanced Security in each group. In the General tab, click Change to select the location of the KM Server. This option is not available if a local KMS exists in the administrative group.

Country-to-Country Encryption Algorithms

When you examine the properties of the Encryption Configuration object, you will notice the Algorithms tab, which allows you to specify the desired encryption algorithms for your clients. If your users are running Microsoft Outlook 98, Outlook 2000, or Internet mail clients, you should accept the default S/MIME setting under Security Message Format. This guarantees the most flexible interoperability. If you need to support legacy MAPI-based clients, such as Outlook 97, on the other hand, you should activate the Exchange 4.0/5.0 option.

NOTE


If you enable both version 1 and version 3 certificates for backward compatibility with Outlook 97 and earlier MAPI-based clients (in the Enrollment tab of the Key Manager configuration object), two signing and two sealing key pairs will be issued for each user instead of one. Outlook 98 and Outlook 2000 can use X.509 version 1-based key pairs for compatibility with earlier MAPI-based clients. Internet mail clients support S/MIME encryption only.

Different Versions in One Organization

As a result of export and import restrictions, three different versions of advanced security exist, but all can be used in a single organization. Hence, an organization can use the very safe North American (3DES) version in the United States and Canada, the Other version (RC2-40) in Japan, and a third version called No Advanced Security in France. Of course, it is not desirable to send an encrypted message to a user who cannot decrypt it—for example, a French user. Consequently, your messaging client must check the common security level supported by all recipients of a message to find the best encryption method to use. Messages cannot be encrypted for each recipient separately.

The X.509 sealing certificate, obtained from Active Directory, provides information about the supported encryption methods. Outlook 2000 will contact Active Directory to retrieve the sealing certificates of all recipients. The client uses the highest security level common to the recipients to encrypt the message. For example, if you address a message to recipients in New York (3DES), Tokyo (RC2-40), and Paris (None), you cannot encrypt the message because the maximum common advanced security level is None. In this case, the client displays a warning message asking you whether you want to cancel the send process to remove those recipients that cannot handle encryption from your message or send the message to all recipients unsealed.

Key and Certificate Management

The general tasks of a KM administrator are easy to discover by right-clicking Key Manager and pointing to All Tasks. You'll see three important options: Enroll Users, Revoke Certificates, and Recover Keys.

Key and Certificate Recovery

The recovery of security information is necessary if a user's cryptographic keys are corrupted or accidentally deleted or if the user has forgotten his or her security password. As mentioned, keys and certificates are maintained in security stores, which are part of the user profile in Windows 2000 Professional. This has great advantages. By configuring a server-based (roaming) profile, you can access your cryptographic keys on any workstation in the network. However, if you do not work with roaming profiles and change the computer hardware, your keys are lost if you did not export them in Outlook 2000 beforehand (this can be done via the Options dialog box by clicking on the Security tab and clicking the Import/Export Digital ID button). You will also lose your security keys if another administrator opens the System program from Control Panel on your workstation, clicks the User Profiles tab, and deletes your local user profile. In all these cases, new security information must be created.

From the user's perspective, the process of recovering advanced security is the same as the process of enabling it. You have to send a new request to the KM Server to recreate a valid digital ID for your private keys and place certificates in your security store. Again, a 12-character security token, obtained from the KM administrator, is required to create and encrypt the request message.

The steps the KM administrator has to take to recover security information for a user differ slightly from the steps for enabling it. Either you use the Recover Keys command, as mentioned earlier, or you work directly with the E-Mail Security option in the Exchange Features tab of the troubled user's account object in Active Directory Users and Computers. Click the Recover Key button to launch the recovery routines. During recovery, the KM Server does not create a new sealing key pair. Instead, it restores the original key pair from the KM database. Again, a 12-character security token is returned; you must supply this to the user, as usual.

The public sealing key certificate is still available in Active Directory and doesn't need to be requested again from the Enterprise CA. However, the private signing key is only stored on the user's local machine and was irretrievably lost. Hence, Outlook 2000 must create a new signing key pair as well as a signing certificate request, which is sent to the KM Server in the recovery message. KM Server forwards the request to the Enterprise CA, where a new certificate is issued, and then this certificate, together with the sealing key pair, is returned to the user, who completes the process of recovering advanced security.

Key and Certificate Revocation

Just as you can enable advanced security for a user, you can also disable it via the Revoke Certificates option. This will add the user's private sealing key to an internal revocation list in the KM database. The user's sealing certificate in the Enterprise CA and Active Directory are also invalidated. To do this, the Enterprise CA adds the unique serial number of the user's sealing certificate to its certificate revocation lists (CRLs). Every X.509 version 3 certificate has a CRL Distribution Points attribute that points to the location of the CRL. Clients need to check the CRL to determine whether a recipient's sealing certificate is valid or revoked. CRLs are cached on the local computer for performance improvement.

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 accessible across the network via HTTP through a URL in the following format: http://<server name>/CertEnroll/<CRL Name>.crl (for example, http://Bluesky-srv1/CertEnroll/Blue Sky Airlines Root CA.crl). You can define additional locations in the properties of your Enterprise CA using the Certification Authority snap-in. Click on the Policy Module tab, then click the Configure button. In the X509 Extensions tab, click the Add CDP button. It is advisable to manually update published CRLs after revoking certificates. In the Certification 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.

Revoked Security Keys

The KM Server does not delete revoked security keys. They are stored in the KM database and also in the user's security store because they are needed to decrypt old (and still encrypted) messages. You can re-enable advanced security for a revoked user with a new certificate. In this case, the user will receive the old security keys along with the new security information. The user's old certificate will remain on the CRL until its expiration date is reached.

Key and Certificate Update

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 to update the certificates for an additional period, and the user receives new signing and sealing key pairs. The old private sealing key is not deleted.

Advanced Security Maintenance

The primary task in maintaining advanced security is backing up the KM database, called KMSMDB.EDB (\Program Files\Exchsrvr\KMSData directory), on a regular basis. If this database were somehow corrupted or destroyed, the history of private sealing keys would be lost, and you would not be able to recover security keys. Encrypted messages sent to a user would not be able to be decrypted and would become unreadable at the moment the user loses his or her private sealing key. Using the Windows 2000 Backup utility (NTBACKUP.EXE), it is possible to include the KM database into online backups of Exchange 2000 Server, as explained in Chapter 20, "Microsoft Exchange 2000 Server Maintenance and Troubleshooting."

Moving the KM Server

You can move a KM Server from one server to another server in the administrative group, which may be desirable if you plan to remove the first server completely or dedicate the hardware to other tasks. The relocation of a KM Server to another computer in the same administrative group is basically a backup and restore operation (see Figure 19.16). However, you cannot move a KM Server between administrative groups, but you can move the users, as explained in the following sections.

click to view at full size

Figure 19.16 Moving a KM Server

Moving Key Histories Between KM Servers

At times it might be necessary to move users between administrative groups. As outlined in Chapter 13, "Creating and Managing Recipients," this requires you to delete the old mailbox and recreate it on the new Exchange 2000 server using the original e-mail addresses. The user may download existing messages into a local personal folder store prior to the mailbox deletion and upload the messages again after the mailbox creation on the new server. The user's key history, however, will remain on the KM Server in the original administrative group. If the new administrative group uses a different KM Server, the user's private sealing key history must be moved.

Exporting the KM Server Computer Certificate

Before deleting the old mailbox, you need to export the user's key history. After creating the new mailbox, import the history into the new KM Server. Keep in mind that you are working with very sensitive data—the user's private sealing key. Of course, this key must not be exported in unencrypted form. It must be encrypted using the new KM Server's public sealing key, which is available in this KM Server's computer certificate.

Using Exchange System Manager, you can obtain the target KM Server's certificate by right-clicking the Key Manager object under Advanced Security in the target administrative group. Point to All Tasks, and select Save KMS Certificate. Don't forget to write down the first eight characters that are displayed in the Thumbprint box (it is possible to copy this information into the clipboard). Then, specify a path where the certificate will be saved with a .crt extension.

Exporting Cryptographic Key Histories

As soon as the target KM Server's certificate has been obtained, you can export the user from the old KM Server. In the original administrative group, under Advanced Security, right-click Key Manager, point to All Tasks, and then select Export Users. You need to enter your KM administrator password to launch the Exchange KMS Key Export Wizard. Click Next to reach the Encryption Certificate wizard screen, where you have to specify the exported KM Server certificate. Click Next, and type the first eight characters of the thumbprint in the Thumbprint box (or paste them from the clipboard). Click Next, and specify an export file name (such as SEALKEYHIST.SEC). It is not possible to define a file path. The file will be saved in the \Program Files\Exchsrvr\KMSData directory. Click Next to reach the User View Selection wizard screen, where you can make your choice, similar to enrolling users with advanced security. If you are exporting only one user, it is convenient to pick the corresponding account from the global address book. However, it is also possible to bulk export key histories for multiple users per administrative group, mailbox store, or server. The Exchange KMS Key Export Wizard displays a summary on completion of the export process.

Importing Cryptographic Key Histories

At this point, you can safely delete the old mailbox—provided that the user has downloaded his or her messages—and recreate it on the target server. After that, you can import the user's key history. Copy the export file (for example, SEALKEYHIST.SEC) into the target server's \Program Files\Exchsrvr\KMSData directory. After that, right-click the target Key Manager object, point to All Tasks, and select Import Users. Again, you need to enter your KM administrator password to launch the Exchange KMS Key Import Wizard. Click Next, specify the import file (SEALKEYHIST.SEC), and click Next again. You will reach the Unknown Users wizard screen, which lists the user's old account taken from the import file. The wizard is unable to find the corresponding mailbox in the organization because it was deleted. It is not possible to establish an association with the new mailbox automatically. KMS uses the globally unique identifier (GUID) of the mailbox to identify the user in Active Directory. However, the user's new mailbox has a different GUID than the original mailbox. Click the Resolve User button, and select the user's newly mailbox-enabled account from the Select Users dialog box to match the unknown account with the new mailbox. Continue by clicking Next and complete the import.

Re-Enabling Security Keys

At this point, the key history is available in the KM database. However, the new mailbox has not been enabled with advanced security yet, and even if you have not deleted the old mailbox but moved it between KM Servers (KMS installed in remote administrative groups), the user will not be able to use the old certificates any longer. The export of private sealing keys compromises advanced security, and, consequently, affected user certificates are revoked during this process. In any case, you will have to re-enable advanced security for the user to issue a new set of signing and sealing key pairs. The process of enabling advanced security was explained earlier in this lesson.

NOTE


To avoid problems with advanced security, do not revoke certificates or recover keys of affected users during the export and import cycle. Microsoft recommends completing the key recovery within 24 hours of the key history move.

Advanced Security with Other Organizations

S/MIME is an industry standard widely accepted across the Internet. Therefore, you are able to exchange signed and sealed messages with any other e-mail client that supports S/MIME, such as Outlook Express.

S/MIME Interoperability Issues

Both Outlook 2000 and Outlook Express can use the same certificates. You need to use Outlook 2000 to complete the process of enabling advanced security, but as soon as you have received your certificates, you can use them in Outlook Express as well. In Outlook Express, open the Tools menu, select Accounts, click on the Mail tab, and double-click the desired account, such as an account to access your mailbox via IMAP4. Click on the Security tab, and then, under Signing Certificate and Encryption Preferences, click Select to specify the Exchange signing and sealing certificates. Click View Certificate to verify which certificate to use for message signing. In the Details tab, check the attribute called Key Usage. The signing certificate will have the Key Usage attribute set to Digital Signature, while the sealing certificate shows a Key Usage of Digital Signature, Key Encipherment.

Outlook Express supports S/MIME version 2 while Outlook 2000 Service Release 1 supports S/MIME version 3. You may experience problems in Outlook Express when working with sealed messages that were composed in Outlook 2000. Outlook Express does not recognize the content type tag application/octet-stream used by Outlook 2000 as an identifier for an S/MIME encrypted message and might display empty messages along with an attachment named SMIME.P7M. To decrypt affected messages, drag them from Outlook Express to the desktop, open them in Notepad, and replace the string octet-stream with pkcs7-mime. When you save the changes and double-click the item, Outlook Express will be able to recognize and decrypt the SMIME.P7M attachment.

NOTE


OWA does not support S/MIME and cannot display digital signatures or sealed messages.

Person-to-Person Key Exchange

When you want to send encrypted messages to a particular user, you must use that person's public sealing key. As explained earlier in this lesson, this key is stored in the user's sealing certificate maintained in Active Directory. Active Directory guarantees that sealing certificates are available to all users in the organization.

It might seem impossible to send encrypted messages to users in another organization because the directories of other organizations are typically not accessible. To address this problem, you need to exchange certificates with those users manually. This sounds more complicated than it actually is. By default, the Send These Certificates With Signed Messages option (accessed via the Options dialog box in the Security tab, the Setup Secure E-Mail button) is selected, which causes Outlook to include a copy of your sealing certificate into signed messages. Hence, you should have the person to whom you want to send encrypted messages send you a signed message first. Likewise, you may send the user a signed message yourself. As soon as you have received the 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 to update the information.

The sealing certificate will be stored in the contact object. You can double-check its existence on the contact's Certificates property sheet. To send this person sealed messages, you must address them by selecting the contact from the Outlook Address Book. It is important to note that it is not possible to simply reply to the digitally signed message and encrypt the content. You would receive an error message that the message cannot be encrypted because the client is not using the contact object containing the certificate. Delete the recipient from the To line, click To, and select the contact object from the address book to solve this problem.

NOTE


To send a user in another organization sealed messages, your client must trust the recipient's CA that issued the user's certificate. If necessary, import the root certificates of outside organizations into your security store (Trusted Root Certification Authorities), or publish them in your organization's internal CTL using the Certificates snap-in on a domain controller. With the latter approach, all of your users automatically trust the external certificate. This is known as cross-certification. For more information about cross-certification, consult the Windows 2000 documentation on Certificate Services.



MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration
MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net