Export (0) Print
Expand All

Implementing Outlook Web Access with the S/MIME Control

 

Topic Last Modified: 2006-02-20

Support for Outlook Web Access with the S/MIME control is provided automatically as part of the support Exchange 2003 provides for Outlook Web Access. There are no separate components that the Exchange Server administrator needs to install to enable support for Outlook Web Access with the S/MIME control. However, there are some configuration changes required on both the user's client system and the user's Exchange server before Outlook Web Access with the S/MIME control can be used.

Outlook Web Access with the S/MIME control functions similarly to Outlook Web Access in that the Web browser running the user's client system and the user's Exchange server work together to provide the e-mail client functionality. As discussed in Implementing and Maintaining Exchange 2003 to Support Message Security, in an Exchange 2003-based message security system, it is the e-mail client and PKI that interact to provide the services associated with S/MIME. In implementing Outlook Web Access with the S/MIME control, the e-mail administrator enables support for Outlook Web Access with the S/MIME control, and then integrates Outlook Web Access with the S/MIME control with the organization's PKI.

Configuring a user's client system to support Outlook Web Access with the S/MIME control requires you to perform two steps:

  • Deploy Outlook Web Access with the S/MIME control to the client system.

  • Make the appropriate digital certificates available on the client system.

To use Outlook Web Access with the S/MIME control, the client system on which the user is running Internet Explorer must have Outlook Web Access with the S/MIME control installed. S/MIME functionality in Outlook Web Access cannot be used on a system that does not have Outlook Web Access with the S/MIME control installed.

importantImportant:
Outlook Web Access with the S/MIME control requires that the client system use Microsoft Windows® 2000 or later and Internet Explorer6 or later. The S/MIME control cannot be installed on a system that does not meet these two requirements. In addition, to use the functionality of Outlook Web Access with the S/MIME control, the user must use Internet Explorer to open Outlook Web Access. You cannot use the S/MIME control with other browsers installed on the client system. You can only use Internet Explorer 6 for S/MIME functionality in Outlook Web Access.

The S/MIME control is available as a download from the Options page within Outlook Web Access. To deploy Outlook Web Access with the S/MIME control, instruct your users to download and install the control on their client systems. For detailed steps, see How to Install the Outlook Web Access S/MIME Control.

The S/MIME control is downloaded from the Exchange server to the local computer. After the control is successfully installed, it is available to any user of the system, including those without administrator privileges. For the S/MIME control to operate properly, the Internet Explorer zone to which the user is connecting for Outlook Web Access must have the following settings:

  • Download signed ActiveX controls set to Prompt or Enable.

  • Run ActiveX controls and plug-ins set to Enable (or Administrator approved with the S/MIME control as an approved control).

  • Script ActiveX controls marked as safe for scripting set to Enabled.

By default, these settings are enabled in the Internet and intranet zones.

Many companies use URLScan on the front-end HTTP servers for Outlook Web Access. URLScan monitors URLs and allows customers to block specific file types, such as .exe and .vbs files, from going over the wire to the Outlook Web Access client. If you use URLScan or similar software to protect the Outlook Web Access client, and you want to make the S/MIME control available from outside your corporate firewall, you will need to allow executable (.exe) file types to pass through URLScan and the firewall.

In many environments, users do not have administrator access to their client computers in accordance with the organization's security policy. Users cannot download and install the S/MIME control. The e-mail client administrator needs to work with administrators of the desktop systems to develop a means of deploying the S/MIME control to users' desktops that is in accordance with the organization's security policy.

The following two deployment strategies are recommended for evaluation:

  • Integrate the S/MIME control into a preconfigured desktop image.

  • Deploy the S/MIME control setup package using your organization's enterprise software management system.

After the S/MIME control is installed on a client system, it is available to all users, including those who do not have administrator rights. Integrating the S/MIME control into a standardized image is a solution for those organizations that are already using this strategy for managing desktop configurations.

Organizations that do not use a desktop image but want to deploy the S/MIME control to users without administrator privileges should deploy S/MIME control setup using their organization's enterprise software management system.

noteNote:
New in SP1   In Exchange Server 2003 SP1, the S/MIME control setup program is a Microsoft Installer (MSI) file contained in a self-extracting executable file; this solution allows customers to deploy the S/MIME control to the desktop with enterprise software management systems. The previous version of Exchange 2003 used a different S/MIME control setup mechanism that was not compatible with enterprise management and deployment tools. The setup package is named Setupmcl.exe and is located in the following directory when Exchange 2003 SP1 is installed (where version is the build number for SP1):
    drive:\program files\exchsrvr\exchweb\version\cabs\setupmcl.exe 

For information about how to use your enterprise software management system to build and deploy customized installations, see the documentation for your enterprise software management system.

Implementing and Maintaining PKI to Support Message Security in Exchange 2003, provides details about how Outlook Web Access with the S/MIME control performs certificate validation in support of PKI. As the e-mail client administrator, you should understand that the client system must have appropriate digital certificates available either by installing the certificates into the user's Personal certificate store or by using a smart card. Confer with the PKI administrator to find out how user's digital certificates will be made available to the client system.

In addition to configuring users' client systems, the users' Exchange servers must also be configured to support Outlook Web Access with the S/MIME control. The configuration enables handling and validation of digital certificates. Specifically, the user's Exchange server must have appropriate root certificates present in the local computer account's Personal certificate store, and must be able to access and retrieve information that PKIs make available for certificate validation, usually across the network using HTTP or LDAP.

noteNote:
In a front-end and back-end configuration, the digital certificates must be added to the Personal certificate store of the back-end server.

As with configuring users' client systems to ensure that you have appropriate digital certificates available, confer with the PKI administrator, who will determine what certificates, if any, need to be available on a user's Exchange server. If the PKI administrator determines that digital certificates need to be added to the Personal certificate store of the local computer account on the Exchange server, these certificates can be added manually or propagated using Group Policy. It is recommended that you use Group Policy whenever possible. For information about using Group Policy to propagate digital certificates, see the Windows Server™ 2003 documentation. For steps on manually adding digital certificates to users' Exchange server, see Troubleshooting S/MIME in Exchange Server 2003.

The user's client system handles digital certificates related to the user's private key, and the user's Exchange server handles digital certificates related to other users' public keys as well as validates digital certificates related to both public keys.

To access the information that PKIs make available for certificate validation, ensure that when users' Exchange servers are behind a firewall, these servers can connect through the firewall using the appropriate protocols (generally, HTTP or LDAP). Consult with the PKI administrator to determine what configuration is necessary to support certificate validation on the client system and consult with the firewall administrator to implement the appropriate changes.

noteNote:
When using Windows Server 2003, you can use the Proxycfg.exe utility to configure the built-in HTTP proxy client instead of installing a proxy client. However, this proxy does not support LDAP. If you need to access certificate validation information through LDAP, you will need to install firewall clients that support LDAP. For more information about using and configuring the Windows Server 2003 proxy client, see the online Help with Proxycfg.exe.

After you install the S/MIME control on the users' client systems and ensure that the client systems and the Exchange servers are configured to support the handling and validation of digital certificates, you can then work with the PKI administrator to integrate Outlook Web Access with the S/MIME control with the PKI.

Outlook Web Access with the S/MIME control is designed to use any digital certificate that conforms to the S/MIME version 3 standard. You can integrate Outlook Web Access with the S/MIME control with an existing PKI or implement a new PKI in support of S/MIME in Exchange 2003 if it supports S/MIME version 3.

When planning to integrate Outlook Web Access with the S/MIME control with PKI, the e-mail client administrator's primary concern is ensuring that the PKI administrator makes the appropriate digital certificates available in the Microsoft Active Directory® directory service and on the user's client system. This can be done by storing the certificates in the certificate store of the user's client system, by making them available through a smart card, or by making them available through the use of cryptographic service providers (CSPs) that support software roaming of certificates. When you plan your implementation of Outlook Web Access with the S/MIME control, the PKI administrator should read Implementing and Maintaining PKI to Support Message Security in Exchange 2003. This section augments the existing PKI documentation with specific information about integrating with an Exchange 2003-based system. This section includes information about supporting Outlook Web Access with the S/MIME control in your PKI.

If you do not want to implement PKI, you can use public PKI networks to provide the necessary PKI to enable S/MIME. For a list of public PKI providers for use with Outlook Web Access with the S/MIME control, see "Where to Get Your Digital ID" and "Digital ID."

After the installation and configuration are completed and users have been issued the appropriate digital certificates, Outlook Web Access with the S/MIME control can send digitally signed and encrypted e-mail messages.

Outlook Web Access with the S/MIME control provides S/MIME security services to the e-mail messages that users send and receive through Outlook Web Access. Users interact with e-mail messages as they would with Outlook Web Access, but can also send and receive digitally signed or encrypted e-mail messages.

Outlook Web Access with the S/MIME control provides three ways to use S/MIME functionality:

  • Individuals can use Outlook Web Access to digitally sign or encrypt individual e-mail messages.

  • Individuals can configure Outlook Web Access with the S/MIME control to digitally sign or encrypt all e-mail messages by default.

  • Administrators can configure Outlook Web Access with the S/MIME control to require digitally signing or encrypting of all e-mail messages for users on a specific Exchange server.

For more information about common problems in sending and receiving digitally signed and encrypted e-mail messages, see Troubleshooting S/MIME in Exchange Server 2003.

noteNote:
After the S/MIME control is installed, attachments opened directly from signed and encrypted e-mail messages will be deleted from the Internet Explorer cache when the message is closed. This behavior is only for signed and encrypted items. Attachments opened from messages that are unsigned and unencrypted are not deleted.

By default, Outlook Web Access with the S/MIME control is configured to not sign or encrypt e-mail messages. A user must select digital signatures or encryption on an individual e-mail message or change the default setting.

After the S/MIME control is installed, buttons are added to the toolbar that appears when composing an e-mail message. To digitally sign or encrypt an individual e-mail message, the user clicks the appropriate button for that message. When the message is sent with the appropriate button selected, Outlook Web Access with the S/MIME control adds the appropriate S/MIME service to the e-mail message. For detailed steps, see:

In addition to adding buttons to allow signing and encrypting individual e-mail messages, Outlook Web Access with the S/MIME control adds check boxes to the Options page under E-Mail Security to enable digitally signing and encrypting all e-mail messages by default. For detailed steps, see How to Configure the Default S/MIME Settings in Outlook Web Access.

You can require that e-mail messages always be digitally signed or encrypted, eliminating the option for the user to send unsigned or unencrypted messages. This requirement can be used with an organization's security policy regarding e-mail usage.

After you implement these settings, users cannot send e-mail messages that are unsigned or unencrypted. Implement these settings with caution because users cannot send e-mail messages if the appropriate digital certificates cannot be obtained. These settings do not affect the user's ability to send e-mail messages using other e-mail clients or Outlook Web Access without the S/MIME control. To make all e-mail usage conform to these requirements, this setting must be coupled with similar restrictions on other e-mail clients. In addition, those e-mail clients who cannot be controlled must be prevented from accessing the Exchange server.

This is controlled by registry settings on the user's Exchange server on the following keys:

  • AlwaysSign

  • AlwaysEncrypt

For more information about these registry keys and their settings, see Outlook Web Access S/MIME Control-Related Settings.

To view digitally signed or encrypted e-mail messages, the user provides a Personal Identification Number (PIN) or password only if their private key uses strong key protection. Outlook Web Access with the S/MIME control automatically processes these messages and prompts the user for any necessary input based on the digital certificate. For digitally signed messages, the user's client system verifies the message signature (decrypts signature hash with public key, and then calculates and compares the message hash), while the Exchange server verifies the validity of the signing certificate (expiry, trust, revocation). For encrypted messages, the user's client system automatically attempts to retrieve the appropriate private keys, prompts the user for information where necessary, and, if successful, displays the e-mail message. For detailed steps about viewing S/MIME mail in Outlook Web Access, see the following:

For more information about problems encountered in receiving digitally signed and encrypted e-mail messages, see Troubleshooting S/MIME in Exchange Server 2003.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft