Exchange 2007 域安全系列

ghosty

    域安全性指 Microsoft Exchange Server 2007 和 Microsoft Office Outlook 2007 中的功能集，它提供一种成本相对较低的备选安全解决方案，可代替 S/MIME 或其他邮件级安全解决方案。域安全性功能集的目的是为管理员提供一种管理Internet 上域之间的受保护邮件路径的方法。配置这些受保护的邮件路径后，成功从通过身份验证的发件人经由受保护的路径传递的邮件在 Outlook 和 Outlook Web Access 界面中对用户显示为"域安全"。
　　域安全性使用具有相互身份验证的传输层安全性 (TLS) 提供基于会话的身份验证和加密。具有相互身份验证的 TLS 与通常实现的 TLS 不同。通常，部署 TLS 只是用于以加密的形式提供机密性。在发件人和收件人之间没有发生认证。除了这种部署之外，有时，TLS 部署只对接收服务器进行身份验证。这种 TLS 部署是 TLS 的 HTTP 实现方式的典型部署。此实现方式是 SSL，只对接收服务器进行身份验证。
　　通过相互TLS认证，每个服务器通过验证其他服务器提供的证书来验证其他服务器的身份，在此方案中，在Exchange 2007环境中，通过验证的连接从外部域接收的邮件，Outlook 2007将显示“域安全”图标。
　　Exchange 2007 中的 TLS 功能以及相关术语
　　与早期版本的 Microsoft Exchange Server 相比，Exchange Server 2007 可以提供更多的管理功能和其他增强功能，可改善对传输层安全性 (TLS) 的总体管理。使用这项新功能时，应了解一些与 TLS 有关的新功能。某些术语和概念适用于多项与 TLS 有关的功能。在本主题中，简要介绍了每项功能，目的是帮助您了解与 TLS 和域安全性功能集有关的一些差异和常用术语。
　　1. 相互 TLS 正如前面描述的那样，相互TLS部署在这样的场景中，发送方和接收方在开始发送数据之前要互相认证。
　　2. 域安全性 域安全性是使相互 TLS 成为有用并且容易管理的技术的功能集，例如证书管理、连接器功能和 Outlook 客户端行为。
　　3. 机会型 TLS 在早期版本的 Exchange Server 中，必须手动配置 TLS。此外，必须在运行 Exchange Server 的服务器上安装适合 TLS 使用的有效证书。在 Exchange 2007 中，安装程序将创建自签名证书。默认情况下启用 TLS。这样，任何发送系统可以对 Microsoft Exchange 的入站简单邮件传输协议 (SMTP) 会话进行加密。默认情况下，Exchange 2007 还尝试对所有远程连接使用 TLS。
　　4. 直接信任 默认情况下，边缘传输服务器与集线器传输服务器之间的所有通信均进行身份验证并加密。身份验证和加密的基础机制仍是相互 TLS。Exchange 2007 使用直接信任(而不是使用 X.509 验证)来验证证书。直接信任意味着 Active Directory 目录服务或 Active Directory 应用程序模式 (ADAM) 目录服务中存在证书即证明证书有效。Active Directory 被视为受信任的存储机制。使用直接信任时，证书是自签名还是由证书颁发机构签名并不重要。将边缘传输服务器订阅到 Exchange 组织时，边缘订阅将在 Active Directory 中发布边缘传输服务器证书，以便集线器传输服务器进行验证。Microsoft Exchange EdgeSync 服务使用集线器传输服务器证书集更新 ADAM，以便边缘传输服务器进行验证。
　　操作的顺序
　　部署域全不需要很多配置，您只需要执行下面几个高级的步骤：
　　1. 决定您的证书计划
　　2. 在边缘传输服务器上安装证书
　　3. 在发送和接收连接器上设置适当的属性
　　然而，就像所有的软件部署一样，您必须注意本文中描述的一些细节和基本的计划任务。
　　前提条件
　　部署域安全的唯一绝对的前提条件是有一个面向Internet 的Exchange 2007传输服务器。具体来说，这意味着Exchange 2007传输服务器不能位于任何第三方邮件过滤服务器或任何防火墙或可能会以别的方式修改简单邮件传输协议(SMTP协商)的进程后。
　　尽管您能够为中心传输服务器配置域安全，我们建议您在边缘传输服务器上运行域安全功能。在这篇文章中，我们假设您使用边缘传输服务器作为面向Internet 的传输服务器。
    使用边缘传输服务器的另一个前提条件是通过边缘订阅过程订阅所有的边缘传输服务器到Exchange 组织。
　　在广泛部署证书到所有的边缘传输服务器之前，一些组织可能想和其他伙伴组织测试域安全的功能，在这种场景下，您可能考虑创建一个子域，像test.contoso.com，来测试域安全。如果您创建子域的话，您必须为该子域更新MX资源记录，以便伙伴组织能够找到该测试域。
　　启用边缘传输服务器上的PKI
　　因为，域安全依赖于相互传输层安全性 (TLS) 身份验证。成功的相互 TLS 身份验证依赖用于域安全的 TLS 证书的受信任的、经过验证的 X.509 证书链。
　　所以，必须先配置边缘传输服务器和 X.509 公钥基础结构 (PKI) 以容纳证书信任和证书验证，才能成功部署域安全。
　　配置根证书颁发机构
　　若要验证给定的 X.509 证书，必须信任颁发证书的根证书颁发机构 (CA)。根 CA 是最受信任的 CA，位于 CA 的顶部。根 CA 具有自签名证书。运行依赖于证书颁发机构的应用程序时，每个证书必须具有结束于本地计算机的受信任根容器中的证书的证书链。受信任根容器包含来自根证书颁发机构的证书。
　　若要成功发送域安全的电子邮件，必须能够验证接收服务器的 X.509 证书。类似地，当某个用户向您的组织发送域安全的电子邮件时，发送服务器必须能够验证您的证书。
　　有两种类型的受信任的根 CA，用于实施域安全：内置的第三方根 CA 和私有根 CA。
　　第三方根证书颁发机构
　　Microsoft Windows 包括一组内置的第三方根 CA。如果信任由这些第三方根 CA 颁发的证书，则表示可以验证由这些 CA 颁发的证书。如果您的组织和伙伴组织使用的是默认 Windows 安装，且信任内置的第三方根 CA，则信任是自动的。在此方案中，不需要其他信任配置。
　　私有受信任的根证书颁发机构
　　私有受信任的根 CA 是已经由私有 PKI 或内部 PKI 部署的根 CA。例如，当您的组织或与之交换域安全的电子邮件的组织已使用自己的根证书部署内部 PKI 时，必须进行其他信任配置。
　　使用私有根 CA 时，必须更新存储在边缘传输服务器上的 Windows 受信任的根证书，以确保域安全功能正常工作。
　　可以使用两种方法配置信任：直接根信任和交叉证书。必须了解传输服务无论何时拾取证书，都会在使用该证书之前对其进行验证。因此，如果使用私有根 CA 颁发证书，则必须将该私有根 CA 包括在位于发送或接收域安全的电子邮件的每个边缘传输服务器上的受信任的根证书存储中。
　　直接根信任
　　如果需要信任某个已由私有根 CA 颁发的证书，可以手动将此根证书添加到边缘传输服务器计算机上的受信任的根证书存储。
　　交叉证书
　　当一个 CA 签署由另一个 CA 生成的证书时，出现交叉证书。交叉证书使用一个 PKI 构建对另一个 PKI 的信任。在域安全的上下文中，如果您拥有自己的 PKI，则您可能为在您的根颁发机构下的伙伴 CA 创建交叉证书，而不是对带有内部 PKI 的伙伴的根颁发机构使用直接手动信任。在这种情况下，会由于交叉证书最终链回到受信任根而建立信任。
　　必须了解如果拥有内部 PKI 且正在使用交叉证书，则必须在每个接收域安全的电子邮件的边缘传输服务器上手动更新根证书存储，以便每个边缘传输服务器在从通过交叉证书获得信任的伙伴处接收电子邮件时，可以对证书进行验证。
    配置对证书吊销列表的访问
　　无论传输服务何时检索证书，都会验证证书链并验证证书。证书验证是一个确认证书的许多属性的过程。这些属性中的大部分可以在本地计算机上由请求该证书的应用程序确认。例如，该证书的预期用法、该证书的过期日期以及类似的属性在 PKI 上下文以外是可验证的。但是，对尚未吊销的证书的验证必须使用颁发该证书的 CA 进行验证。因此，大部分 CA 制作了公开的证书吊销列表 (CRL)，用来验证吊销状态。
　　若要成功使用域安全，则您或您的伙伴使用的 CA 的 CRL 必须对发送和接收域安全的电子邮件的边缘传输服务器可用。如果吊销检查失败，则接收 Exchange 服务器发放临时协议拒绝邮件。可能发生暂时性吊销失败。例如，用于发布 CRL 的 Web 服务器可能失败。或者边缘传输服务器和 CRL 通讯点之间的常规网络连接问题可能无法完成吊销检查。因此，暂时性吊销失败只会导致邮件传递的暂时延迟，因为发送服务器稍后将重试。但是，成功传输域安全的电子邮件需要 CRL 验证。
　　必须启用下列方案：
　　1. 边缘传输服务器必须能够访问外部 CA 的 CRL 您与之交换域安全的电子邮件的每个伙伴必须具有您的组织的边缘传输服务器可联系的公开 CRL。在某些情况下，CRL 仅在轻型目录访问协议下 (LDAP) 下可用。某些情况下它们可能启用 HTTP。确保配置的出站端口合适，以允许边缘传输服务器与 CRL 联系。
　　2. 必须使颁发证书的 CA 的 CRL 公开可用 您必须要了解，即使边缘传输服务器从您自己的组织中检索证书时，它也要验证证书链以验证证书。因此，您的 CA 的 CRL 必须对您自己的边缘服务器可用。另外，您与之交换域安全的电子邮件的所有伙伴必须能够访问为您颁发证书的 CA 的 CRL。

ghosty

　　配置 WinHTTP 的代理设置
　　Exchange 2007 传输服务器依靠基本的 Microsoft Windows HTTP Services (WinHTTP) 管理所有 HTTP 和 HTTPS 通信。集线器传输服务器和边缘传输服务器都可以使用 HTTP 访问 Microsoft Exchange 2007 标准反垃圾邮件筛选器更新和 Microsoft Forefront Security for Exchange Server 反垃圾邮件更新服务的更新，以及 CRL 验证的更新。
　　在大多数组织中，代理服务器用于与 Internet 上的目标进行 HTTP 和 HTTPS 通信。如果组织使用代理服务器，而 Exchange 传输服务器并未配置为对 HTTP 和 HTTPS 使用代理服务器，则必须配置传输服务器，这样启用了 HTTP 的 CRL 验证才能正常工作。
　　配置 WinHTTP 最简单的方法就是使用 ProxyCfg.exe。ProxyCfg.exe 是一个命令行工具，位于所有 Windows Server 2003 计算机的 %System32% 目录下。您可以用它来设置和查看 WinHTTP 配置。
　　在大多数情况下，您只需要运行下面的命令来指定您的组织中的代理服务器，并指定所有本地通信都要绕过该代理服务器。
　　proxycfg -p proxy_server ""
　　此命令指定 HTTP 服务器和 HTTPS 服务器都要通过名为"proxy_server"的代理服务器进行访问，但主机名包含由 参数指定的句点的代理服务器除外。
　　即使您未运行代理服务器，我们也建议您使用 ProxyCfg.exe 检查是否以前设置过一个代理。您可以在不带任何参数的情形下运行该工具来查看当前配置，如下所示：
　　Proxycfg
　　要为 WinHTTP 配置直接的 Internet 连接或删除现有的代理配置，请运行以下命令：
　　Proxycfg –d
　　重要信息：更改 WinHTTP 的配置后，必须重新启动 Microsoft Exchange 传输服务和 Microsoft Exchange 反垃圾邮件更新服务。
　　如何测试 PKI 和代理配置
　　若要验证特定边缘传输服务器的公钥基础结构 (PKI) 和代理配置，请使用 Certutil.exe 验证边缘传输服务器证书的证书链。Certutil.exe 是作为 Microsoft Windows Server 2003 操作系统的证书服务的一部分安装的命令行工具。
    若要通过运行 Certutil 来验证给定证书的证书链，该证书必须采用文件 (.cer) 格式。因此，必须先将证书(但不包括私钥)导出为 DER (.cer) 文件格式。
　　第一步说明如何将“证书管理器”管理单元添加到 Microsoft 管理控制台 (MMC) 中。第二步说明如何使用证书管理器导出证书。第三步说明如何运行 Certutil 命令来验证证书链。
　　若要执行这些步骤，必须为您使用的帐户委派以下角色：
　　本地 Administrators 组中的成员
　　将证书管理器添加到 Microsoft 管理控制台中
　　1. 单击“开始”，再单击“运行”，键入 mmc，然后单击“确定”。
　　2. 在“文件”菜单中，单击“添加/删除管理单元”。
　　3. 在“添加/删除管理单元”框中，单击“添加”。
　　4. 在“可用的独立管理单元”列表中，单击“证书”，然后单击“添加”。
　　5. 单击“计算机帐户”，再单击“下一步”。
　　6. 单击“本地计算机(运行此控制台的计算机)”选项，然后单击“完成”。
　　7. 单击“关闭”，再单击“确定”。
　　导出证书
　　1. 打开在第一步中创建的证书管理器。
　　2. 依次打开“证书 (本地计算机)”文件夹、“个人”文件夹和“证书”文件夹。
　　3. 在详细信息窗格中，右键单击将用于域安全性的证书，单击“所有任务”，然后选择“导出”。此时将打开证书导出向导。
　　4. 在“欢迎”页上，单击“下一步”。
　　5. 在“导出私钥”页上，选择“否，不导出私钥”，然后单击“下一步”。
　　6. 在“导出文件格式”页上，选择“DER 编码二进制 X.509 (.CER)”，然后单击“下一步”。
　　7. 在“要导出的文件”页上，输入要将导出的证书保存到的路径和文件名，然后单击“下一步”。
　　8. 在“完成”页上验证设置，然后单击“完成”。
　　验证证书的证书链
　　在边缘传输服务器上，打开命令提示符窗口。键入以下命令：
　　Certutil -verify c:\CertificateName.cer
　　其中 CertificateName 是在上一步中导出的边缘传输服务器证书。
    为域安全配置相互TLS
　　本主题将介绍如何使用 Exchange 命令行管理程序来为域安全性配置相互传输层安全性 (TLS)，TLS 是 Microsoft Exchange Server 2007 和 Microsoft Office Outlook 2007 中可提供比 S/MIME 开销相对低的替代方案和其他邮件级安全解决方案的功能集。
　　出于演示目的，本主题将介绍了虚拟公司 Contoso 的 Exchange 管理员如何配置其 Exchange 2007 环境，以便与其合作伙伴 Woodgrove Bank 交换域安全电子邮件。在此示例中，Contoso 希望使用相互 TLS 来确保与 Woodgrove Bank 往来的所有电子邮件都得到保护。此外，Contoso 希望配置域安全性功能，以便在无法使用相互 TLS 时拒绝与 Woodgrove Bank 往来的所有邮件。
　　Contoso 有一个用于生成证书的内部公钥基础结构 (PKI)。PKI 的根证书已被一个主要的第三方证书颁发机构 (CA) 签名。Woodgrove Bank 使用相同的第三方 CA 来生成其证书。因此，Contoso 和 Woodgrove Bank 都信任对方的根 CA。
　　为了设置相互 TLS，Contoso 的 Exchange 管理员执行以下步骤：
　　1. 生成 TLS 证书的证书请求。
　　2. 将证书导入到边缘传输服务器。
　　3. 配置出站域安全性。
　　4. 配置入站域安全性。
　　5. 测试邮件流。
　　相互 TLS 的配置有以下要求：
　　1. 使用 Set-TransportConfig cmdlet 和使用 New-SendConnector cmdlet(如果尚未配置发送连接器)访问内部 Exchange 2007 服务器。
　　2. 访问运行 ExchangeCertificate cmdlet 的边缘传输服务器计算机。
　　通常，不使用 ExchangeCertificate cmdlet 对域安全功能进行的配置更改应当在组织内进行，并使用 Microsoft Exchange EdgeSync 服务将这些更改同步到边缘传输服务器。
　　使用 ExchangeCertificate cmdlet 导入和配置 TLS 证书时，必须在正在配置的边缘传输服务器上运行这些 cmdlet。若要在安装了边缘传输服务器角色的计算机上运行 ExchangeCertificate cmdlet，必须使用作为该计算机的本地管理员组成员的帐户进行登录。
　　要运行 Set-TransportConfig cmdlet，必须为您使用的帐户委派 Exchange 组织管理员角色。
　　要运行 New-SendConnector cmdlet，必须为您使用的帐户委派该计算机的 Exchange Server 管理员角色和本地管理员组。
　　为了实现域安全性，必须完全部署 Microsoft Exchange EdgeSync 服务。
　　生成 TLS 证书的证书请求
　　如本主题上文中所述，Contoso 有一个从属于第三方 CA 的内部 PKI。在此示例中，从属是指 Contoso 在其公司基础结构中部署的 CA 包含已由公开的第三方 CA 签名的根证书。默认情况下，公开的第三方 CA 是 Microsoft Windows 证书存储中的受信任根证书之一。因此，在信任的根存储中包括相同的第三方 CA的任何客户端，当它们连接到Contoso ，就能够对Contoso 提供的证书进行身份验证。
    Contoso 有两个需要 TLS 证书的边缘传输服务器：mail1.contoso.com 和 mail2.mail.contoso.com。因此，Contoso 电子邮件管理员必须生成两个证书请求，每个服务器对应一个证书请求。
　　以下步骤显示管理员用于生成以 base64 编码的 PKCS#10 证书请求的命令。Contoso 管理员必须运行两次此命令：一次对 CN=mail1.contoso.com 运行，另一次对 CN=mail2.mail.contoso.com 运行。
　　注意：
　　结果证书的主题名称中的公用名 (CN) 分别是 mail1.contoso.com 和 mail2.mail.contoso.com。主题备用名称包含"mail.contoso.com"，这是为 Contoso 配置的一个接受域的完全限定的域名 (FQDN)。
　　创建 TLS 证书请求
　　运行以下命令：
　　New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate" -Path c:\certificates\request.p7c -SubjectName "DC=com,DC=Contoso,CN=mail1.contoso.com" -DomainName mail.contoso.com
　　重要信息：您创建的证书或证书请求的特定详细信息取决于许多变量。如果您正在生成请求，请确保与将颁发证书的 CA 或 PKI 管理员密切配合。
　　传输证书和相关密钥
　　当您从 PKI 或 CA 提供者那里收到证书后，请将所颁发的证书转换为 PFX (PKCS#12) 文件，以便将其作为灾难意外事故的一部分进行备份。PFX 文件包含证书和相关密钥。在某些情况下，您可能需要传输证书和密钥以将其移动到其他计算机。例如，如果您有多个边缘传输服务器，并希望在这些服务器中发送和接收"域安全"电子邮件，则您可以创建一个用于所有服务器的证书。在这种情况下，您必须在每个边缘传输服务器上为 TLS 导入并启用该证书。
　　只要将 PFX 文件的副本安全存档，就始终可以导入和启用该证书。PFX 文件包含私钥，因此通过将该文件保存在安全位置的存储媒体中进行物理保护非常重要。
　　了解 Import-ExchangeCertificate cmdlet 总是将从 PFX 导入的私钥标记为不可导出很重要。该功能是特意设计的。
　　在使用 Microsoft 管理控制台 (MMC) 中的证书管理器管理单元来导入 PFX 文件时，可以指定私钥的可导出性和强密钥保护。
　　重要信息：
　　不要对用于 TLS 的证书启用强密钥保护。用户每次访问私钥，强密钥保护都会提示用户。对于域安全，此处的"用户"是指边缘传输服务器上的 SMTP 服务。
　　将证书导入边缘传输服务器
　　管理员生成证书请求之后，使用该请求为服务器生成证书。结果证书必须作为单个证书或证书链进行颁发，并复制到合适的边缘传输服务器。
　　重要信息：
　　要导入证书，则必须使用 Import-ExchangeCertificate cmdlet。
　　重要信息：
　　不要在 Exchange 服务器上使用 MMC 中的证书管理器管理单元为 TLS 导入证书。如果在 Exchange 服务器上使用证书管理器管理单元导入证书，则不能将在此步骤中创建的请求绑定到所颁发的证书。因此 TLS 可能会失败。您可以使用证书管理器管理单元将存储为 PFX 文件的证书和密钥导入本地计算机存储。导入证书后，您可以通过运行 Enable-ExchangeCertificate cmdlet 为 TLS 启用证书。
　　将证书导入边缘传输服务器时，还必须为简单邮件传输协议 (SMTP) 服务启用证书。Contoso 管理员在每个边缘传输服务器上运行以下命令，对每个证书分别运行一次。
    在边缘传输服务器上导入和启用域安全性的 TLS 证书
　　运行以下命令：
　　Import-ExchangeCertificate -Path c:\certificates\import.pfx | Enable-ExchangeCertificate -Services SMTP
　　该命令通过管道传输 Enable-ExchangeCertificate cmdlet 来导入和启用 TLS 证书。
　　还可以在导入证书后将其启用。若要导入证书，请运行以下命令：
　　Import-ExchangeCertificate -Path c:\certificates\import.pfx
　　然后，将指纹复制到 Windows 剪贴板。若要显示您刚刚导入的证书的指纹，请运行以下命令：
　　Get-ExchangeCertificate |FL
　　将数据从"指纹"字段复制到 Windows 剪贴板。
　　最后，请运行以下命令启用证书：
　　Enable-ExchangeCertificate -Thumbprint AB493A0C9A6C0327162FE04EF74609CB8FB7FE24 -Services SMTP
　　配置出站域安全性
　　为了配置出站域安全性，必须执行三个步骤：
　　1. 运行 Set-TransportConfig cmdlet 以指定要用来发送域安全电子邮件的域。
　　2. 运行 Set-SendConnector cmdlet 以便在相应的连接器(该连接器将向您要用于发送域安全电子邮件的域发送邮件)上设置 DomainSecureEnabled 属性。
　　3. 运行 Set-SendConnector cmdlet 以验证以下事项：
　　1. 发送连接器使用域名系统 (DNS) 路由邮件，该发送连接器将把电子邮件发送到要用于发送域安全电子邮件的域。
　　2. FQDN 与正用于域安全性的证书的主题名称匹配或主题备用名称匹配。
　　因为以上三个步骤中所做的更改是全局性的，所以必须在内部 Exchange 服务器上进行更改。所做的配置更改将通过 Microsoft Exchange EdgeSync 服务复制到边缘传输服务器。

ghosty

　　在传输配置中指定发件人域
　　指定要用于发送域安全电子邮件的域是相对简单的事情。Contoso 管理员可以在内部 Exchange 2007 服务器上运行以下命令：
　　Set-TransportConfig -TLSSendDomainSecureList woodgrovebank.com
　　注意：
　　TLSSendDomainSecureList 参数接受多值的域名列表。Set-TransportConfig 命令会将 TLSSendDomainSecureList 的整个值替换为在 cmdlet 中提供的新值。因此，如果要添加新的域，则您提供的值必须包括现有列表和新域。
    配置发送连接器
　　Contoso 将使用其默认 DNS 路由发送连接器向其伙伴发送域安全电子邮件。由于其默认 DNS 路由发送连接器是默认 Internet 发送连接器，因此它使用 DNS 来路由邮件，而不使用智能主机。FQDN 已设置为 mail.contoso.com。由于 Contoso 管理员创建的证书会将 New-ExchangeCertificate 的 DomainName 参数设置为 mail.contoso.com，发送连接器可以在不必提供其他配置的情况下使用这些证书。
　　如果您配置了用于测试的子域，则可能必须更新发送连接器的 FQDN 以便与创建的证书匹配(例如，subdomain.mail.contoso.com)。另一方面，如果您创建的证书在"主题"或"主题备用名称"字段中包含子域，则不必更新发送连接器的 FQDN。
　　因此，Contoso 管理员必须对发送连接器进行的唯一配置是设置 DomainSecureEnabled 参数。为此，Contoso 管理员需要在内部 Exchange 2007 服务器上对"Internet"发送连接器运行以下命令：
　　Set-SendConnector Internet -DomainSecureEnabledTrue
　　还可以使用 Exchange 管理控制台在发送连接器上启用域安全电子邮件。
　　使用 Exchange 管理控制台为域安全性配置发送连接器
　　1. 在集线器传输服务器上，打开 Exchange 管理控制台，单击"组织配置"，单击"集线器传输"，然后在结果窗格中，单击"发送连接器"选项卡。
　　2. 选择向相应域(要从该域发送域安全电子邮件)发送邮件的发送连接器，然后在操作窗格中，单击"属性"。
　　3. 在"网络"选项卡上，选择"启用域安全性(相互验证 TLS)"，单击"应用"，然后单击"确定"。
　　配置入站域安全性
　　若要启用入站域安全性，必须执行两个步骤：
　　1. 运行 Set-TransportConfig cmdlet 以指定要从中接收域安全电子邮件的域。
　　2. 在边缘传输服务器上，使用 Exchange 命令行管理程序或 Exchange 管理控制台对要从中接收域安全电子邮件的接收连接器启用域安全性。由于域安全性要求相互 TLS 身份验证，因此还必须对接收连接器启用 TLS。
　　在传输配置中指定收件人域
　　指定要用于接收域安全电子邮件的域是相对简单的事情。若要指定该域，Contoso 管理员可以在内部 Exchange 2007 服务器上运行以下命令：
　　Set-TransportConfig -TLSReceiveDomainSecureList woodgrovebank.com
　　注意：
　　TLSReceiveDomainSecureList 参数接受多值的域名列表。Set-TransportConfig 命令会将 TLSReceiveDomainSecureList 参数的整个值替换为 Set-TransportConfig cmdlet 提供的新值。因此，如果要添加新的域，则您提供的值必须包括现有列表和新域。
　　配置接收连接器
　　要接受来自您希望接收域安全电子邮件的域的邮件，必须在每个边缘传输服务器上配置接收连接器。Contoso 环境的配置为在两个边缘传输服务器上有单个 Internet 接收连接器(其标识为 Inet)。因此，若要在与 Woodgrove Bank 发送或接收邮件的同时启用 TLS，则 Contoso 管理员必须确保在两个边缘传输服务器的默认 Internet 接收连接器上都启用了 TLS。
    使用 Exchange 命令行管理程序配置域安全性的接收连接器
　　· 在边缘传输服务器上，运行以下命令：
　　Set-ReceiveConnector Inet -DomainSecureEnabledTrue -AuthMechanism TLS
　　使用 Exchange 管理控制台配置域安全性的接收连接器
　　1. 在边缘传输服务器上，打开 Exchange 管理控制台，单击"边缘传输"，然后在结果窗格中，单击"接收连接器"选项卡。
　　2. 选择从您要从其接收域安全电子邮件的域接受邮件的接收连接器，然后在操作窗格中，单击"属性"。
　　3. 在"身份验证"选项卡上，选择"传输层安全性 (TLS)"和"启用域安全性(相互验证 TLS)"，然后单击"确定"。
　　应当知道，指定身份验证机制为 TLS 并不能对所有入站连接强制应用 TLS。
　　由于以下原因，TLS 将强制应用于来自 Woodgrove Bank 的连接：
　　1. 用 Set-TransportConfig cmdlet 中的 TLSReceiveDomainSecureList 参数指定 Woodgrove Bank。
　　2. 在接收连接器上将 DomainSecureEnabled 参数设置为 $True。
　　如果发送系统支持 TLS，则未在 Set-TransportConfig cmdlet 的 TLSReceiveDomainSecureList 参数上列出的其他发件人将只能使用 TLS。
　　注意：
　　对接收连接器启用域安全性的副作用是：系统将在 TLS 协商期间请求客户端证书。如果发送邮件的客户端所在的域不在安全域列表中，则不要求该客户端提交证书。
　　测试域安全邮件流
　　配置域安全电子邮件之后，可通过查看性能日志和协议日志来测试连接。已成功在域安全邮件流路径上通过身份验证的邮件将作为"域安全"邮件显示在 Outlook 2007 中。
　　性能计数器
　　域安全性功能包括"MSExchange 安全邮件传输"下面的以下性能计数器：
　　1. Domain-Secured Messages Received(已接收到的域安全邮件)
　　2. Domain-Secured Messages Sent(已发送的域安全邮件)
　　3. Domain-Secured Outbound Session Failures(域安全出站会话失败)
　　可以用这些性能计数器为域安全邮件流新建计数器日志文件，以监视发送和接收的邮件数，还可以监视失败的相互 TLS 会话。
　　协议日志
　　可以查看发送和接收协议日志，以确定 TLS 协商是否已成功。成功的 TLS 协商将生成类似下例的日志。
　　要查看详细的协议日志，您必须在组织用于收发域安全电子邮件的连接器上将协议日志记录级别设置为 Verbose。
　　使用 Exchange 命令行管理程序针对 verbose 协议日志记录配置接收连接器
    在边缘传输服务器上，运行以下命令：
　　Set-ReceiveConnector Inet -ProtocolLoggingLevel Verbose
　　其中 Inet 是启用了域安全电子邮件的接收连接器的名称。
　　使用 Exchange 命令行管理程序针对 verbose 协议日志记录配置发送连接器
　　在边缘传输服务器上，运行以下命令：
　　Set-SendConnector Internet -ProtocolLoggingLevel Verbose
　　其中 Internet 是启用了域安全电子邮件的发送连接器的名称。
　　发送日志示例
　　<220 edgedns3 ESMTP Microsoft ESMTP MAIL Service, Version: 8.0.647.0; Tue, 29 Aug 2006 04:22:00 -0700 (PDT)
　　>EHLO edgea36.dns.contoso.com
　　<250-edgedns3 Hello woodgrove.com [192.168.0.2], pleased to meet you
　　<250-ENHANCEDSTATUSCODES
　　<250-PIPELINING
　　<250-EXPN
　　<250-VERB
　　<250-8BITMIME
　　<250-SIZE
　　<250-DSN
　　<250-ETRN
　　<250-STARTTLS
　　<250-DELIVERBY
　　<250 HELP
　　>STARTTLS
　　<220 2.0.0 Ready to start TLS
　　*Sending certificate
　　*CN=edgea36, Certificate subject
　　*CN=edgea36, Certificate issuer name
　　*CA2EDF2487C6F09B4E413FD3812A7F89, Certificate serial number
　　*E8DA062786FD097DD8D79FF10C583CC23AD64F6C, Certificate thumbprint
　　*edgea36;edgea36.dns.contoso.com, Certificate alternate names
　　*Received certificate
　　*CN=smi.extest.contoso.com, OU=Contoso, O=Corp, L=Spokane, S=WA, C=US, Certificate subject
　　*CN=ExCertDom EntSub Issuing CA v1.0, DC=ExCertDom, DC=ExTest, DC=Contoso, DC=Com, Certificate issuer name
　　*446DD186000A00002819, Certificate serial number
    *DC27B5F8657F84B15B5004BE63CE482721871582, Certificate thumbprint
　　*smi.extest.contoso.com, Certificate alternate names
　　>EHLO edgea36.dns.contoso.com
　　<250-edgedns3 Hello woodgrove.com [192.168.0.2], pleased to meet you

ghosty

　　<250-ENHANCEDSTATUSCODES
　　<250-PIPELINING
　　<250-EXPN
　　<250-VERB
　　<250-8BITMIME
　　<250-SIZE
　　<250-DSN
　　<250-ETRN
　　<250-DELIVERBY
　　<250 HELP
　　*08C895F533E837EC;2006-08-28T22:37:53.323Z;1, sending message
　　>MAIL FROM: SIZE=614
　　>RCPT TO:
　　<250 2.1.0 ... Sender ok
　　<250 2.1.5 ... Recipient ok
　　>DATA
　　<354 Enter mail, end with "." on a line by itself
　　<250 2.0.0 k7TBM0BZ000043 Message accepted for delivery
　　>QUIT
　　<221 2.0.0 edgedns3 closing connection
　　接收日志示例
　　>220 edgea36 Microsoft ESMTP MAIL Service, Version: 8.0.647.0 ready at Mon, 28 Aug 2006 15:37:53 -0700
　　>250-edgea36.dns.contoso.com Hello [192.168.0.1]
　　>250-SIZE 15728640
　　>250-PIPELINING
　　>250-DSN
    >250-ENHANCEDSTATUSCODES
　　>250-STARTTLS
　　>250-AUTH
　　>250-8BITMIME
　　>250-BINARYMIME
　　>250 CHUNKING
　　
　　>220 2.0.0 SMTP server ready
　　*Sending certificate
　　*CN=edgea36, Certificate subject
　　*CN=edgea36, Certificate issuer name
　　*CA2EDF2487C6F09B4E413FD3812A7F89, Certificate serial number
　　*E8DA062786FD097DD8D79FF10C583CC23AD64F6C, Certificate thumbprint
　　*edgea36;edgea36.dns.contoso.com, Certificate alternate names
　　*Received certificate
　　*CN=smi.extest.contoso.com, OU=Contoso, O=Corp, L=Spokane, S=WA, C=US, Certificate subject
　　*CN=ExCertDom EntSub Issuing CA v1.0, DC=ExCertDom, DC=ExTest, DC=Contoso, DC=Com, Certificate issuer name
　　*446DD186000A00002819, Certificate serial number
　　*DC27B5F8657F84B15B5004BE63CE482721871582, Certificate thumbprint
　　*smi.extest.contoso.com, Certificate alternate names
　　
　　>250-edgea36.dns.contoso.com Hello [192.168.0.1]
　　>250-SIZE 15728640
　　>250-PIPELINING
　　>250-DSN
　　>250-ENHANCEDSTATUSCODES
　　>250-AUTH
　　>250-8BITMIME
　　>250-BINARYMIME
　　>250 CHUNKING
    SIZE=16
　　*08C895F533E837EC;2006-08-28T22:37:53.323Z;1, receiving message
　　>250 2.1.0 user@smi.extest.contoso.com Sender OK
　　
　　>250 2.1.5 user@woodgrove.com Recipient OK
　　<DATA< p>
　　>354 Start mail input; end with .
　　>250 2.6.0 <[email=200608281121.k7SBHYi0004586@edgedns3]200608281121.k7SBHYi0004586@edgedns3[/email]> Queued mail for delivery
　　
　　>221 2.0.0 Service closing transmission channel
　　结论
　　通过使用Exchange 2007中的域安全功能，您能够在Internet 上的域之间管理受保护的邮件路径。