Understanding Domain Security
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Domain Security refers to the set of functionality in Microsoft Exchange Server 2010 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 Microsoft Office Outlook Web App interface.
Domain Security uses mutual Transport Layer Security (TLS) authentication to provide session-based authentication and encryption. Mutual TLS authentication differs from TLS as it's 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's provided by that other server. In this scenario, where messages are received from external domains over verified connections in an Exchange 2010 environment, Outlook 2007 displays a Domain Secured icon.
Important
It's 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.
Looking for management tasks related to managing transport servers? See Managing Transport Servers.
Validation of TLS Certificates
To understand the overall security and resulting trustworthiness of any mutual TLS transmission, you must understand how the underlying TLS certificate is validated.
Exchange 2010 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's signed by its own creator. In Exchange 2010, the self-signed certificate is created by the computer running Microsoft Exchange by using the underlying Microsoft Windows Cryptography 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's 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 Using PKI on the Edge Transport Server for Domain Security.
You can use the Exchange 2010 certificate cmdlets to generate certificate requests for your own PKI or for third-party CAs. For more information, see Understanding TLS Certificates.
For more information about how to configure Domain Security, see the following:
Using Exchange Hosted Services
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-premises 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.
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
© 2010 Microsoft Corporation. All rights reserved.