Planning for Domain Security
Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2007-02-27
Domain Security refers to the set of functionality in Microsoft Exchange Server 2007 and Microsoft Office Outlook 2007 that provides a relatively low-cost alternative to S/MIME or other message-level security solutions. The purpose of the Domain Security feature set is to provide administrators a way to manage secured message paths over the Internet with business partners. After these secured message paths are configured, messages that have successfully traveled over the secured path from an authenticated sender are displayed to users as "Domain Secured" in the Outlook and Outlook Web Access interface.
Domain Security uses Transport Layer Security (TLS) with mutual authentication to provide session-based authentication and encryption. TLS with mutual authentication differs from TLS as it is usually implemented. Typically, when TLS is implemented, the client verifies that the connection securely connects to the intended server by validating the server’s certificate. This is received as part of TLS negotiation. In this scenario, the client authenticates the server before the client transmits data. However, the server doesn't authenticate the session with the client.
With mutual TLS authentication, each server verifies the connection with the other server by validating a certificate that is provided by that other server. In this scenario, where messages are received from external domains over verified connections in an Exchange 2007 environment, Outlook 2007 will display a "Domain Secured" icon.
|It is beyond the scope of this topic to provide a detailed explanation of cryptography and certificate technologies and concepts. Before you deploy any security solution that uses cryptography and digital certificates, we recommend that you understand the basic concepts of trust, authentication, encryption, and public and private key exchange as they relate to cryptography. For more information, see the references listed at the end of this topic.|
To understand the overall security and resulting trustworthiness of any mutual TLS transmission, you must understand how the underlying TLS certificate is validated.
Exchange 2007 includes a set of cmdlets to create, request, and manage TLS certificates. By default, these certificates are self-signed. A self-signed certificate is a certificate that is signed by its own creator. In Exchange 2007, the self-signed certificate is created by the computer that is running Microsoft Exchange by using the underlying Microsoft Windows Certificate API (CAPI). Because the certificates are self-signed, the resulting certificates are less trustworthy than certificates that are generated by public key infrastructure (PKI) or a third-party certification authority (CA). Therefore, we recommend that you use self-signed certificates for internal mail only. Alternatively, if the receiving organizations with which you exchange domain-secured e-mail manually add your self-signed certificate to the trusted root certificate store in each of their inbound Edge Transport servers, the self-signed certificates are trusted explicitly.
For connections that traverse the Internet, it is a best practice to generate TLS certificates with a PKI or third-party CA. Generating TLS keys with a trusted PKI or third-party CA reduces the overall management of Domain Security. For more information about the options regarding trusted certificates and Domain Security, see How to Enable PKI on the Edge Transport Server for Domain Security.
You can use the Exchange 2007 certificate cmdlets to generate certificate requests for your own PKI or for third-party CAs. For more information, see Creating a Certificate or Certificate Request for TLS.
For more information about how to configure Domain Security, see the following:
Message-level security is enhanced by or is also available as a service from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services:
Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware
Hosted Archive, which helps them satisfy retention requirements for compliance
Hosted Encryption, which helps them encrypt data to preserve confidentiality
Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations
These services integrate with any on-premise Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers. For more information about Exchange Hosted Services, see Microsoft Exchange Hosted Services.
For more information about cryptography and certificate technologies and concepts, see the following resources:
Housley, Russ and Tim Polk. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. New York: John Wiley & Son, Inc., 2001.
Adams, Carlisle and Steve Lloyd. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Edition. New York: John Wiley & Son, Inc., 1996.
Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure