在 Exchange 本地环境中配置强制 TLS 选项 |第 4 部分#12

在本文中，我们将回顾在 Exchange 本地环境中强制 TLS 的主题。

在基于 Exchange 本地的环境中，我们可以选择使用两个选项来实现强制 TLS选项。

1.域安全

此选项定义一组邮件连接器和配置设置，用于在双方使用 Exchange 本地邮件基础结构的情况下创建安全通信通道、数据加密和相互身份验证。

换句话说，如果“另一方”邮件基础设施不是基于 Exchange 服务器架构，我们就无法使用域安全选项。

域安全（相互 TLS）选项是通过激活名为 - DomainSecureEnabled 的选项来实现的

注意：域安全选项可以在 Exchange 2010 本地服务器和更高版本的 Exchange 服务器中使用。
TlsAuthLevel

2. TlsAuthLevel

为了能够使用非 Exchange 本地邮件基础结构配置强制 TLS 选项，我们需要配置一个名为 -TlsAuthLevel 的特定参数。

使用 TlsAuthLevel 选项使我们能够定义使用 TLS 的强制需求，并且还包括用于指定我们要用于识别邮件流中涉及的“另一方”的确切方法的选项。

本地 Exchange 与 Exchange Online

关于强制 TLS 主题，本地 Exchange 之间存在一些主要差异环境和基于 Exchange Online 的环境。

1. Exchange Online 不支持域安全未来选项。

尽管 Exchange Online 体系结构基于 Exchange 2013 体系结构，但 Exchange Online 邮件基础结构与 Exchange 本地体系结构不同。

如果我们需要在 Exchange 本地邮件基础结构和 Exchange Online 邮件基础结构之间实施强制 TLS 方案，我们将需要使用名为 - TlsAuthLevel 的“其他选项”。

2.管理界面

在基于 Exchange 本地的环境中，使用 TlsAuthLevel 参数配置强制 TLS 选项的唯一方法是使用 PowerShell 命令界面。

在基于 Exchange Online 的环境中，配置强制 TLS 的过程是通过使用 Exchange Online Web 管理图形界面来实现的。

强制 TLS 的设置是通过使用图形向导来实现的，我们使用该向导来配置强制 TLS 所需的所有必需参数。

Exchange Online 包含使用 PowerShell 命令界面设置强制 TLS 所有必需设置的选项，但大多数时候我们将使用 Exchange Online Web 管理图形界面。

在 Exchange 本地环境和混合邮件环境中配置 TLS 设置 |挑战

在我们开始描述在 Exchange 本地环境中配置强制 TLS 之前，有一点很重要我们会意识到一些很容易导致混乱和迷失方向的“障碍”。

• Exchange GUI 界面和 Exchange PowerShell 之间的区别 - Exchange 图形界面不包括使用 Exchange PowerShell 时存在的所有选项。一些与 TLS 设置相关的选项仅在使用 PowerShell 时才存在。
• Exchange 版本之间的差异、GUI 界面 - 在我们的文章中，我们将提供使用 Exchange 2010 本地服务器界面进行 TLS 配置的示例。 Exchange 2013 本地部署中实现的逻辑类似，但是两个 Exchange 版本的图形界面之间存在一些差异。
• Exchange 本地部署和 Exchange Online 之间的区别 - 从技术角度来说，与 Exchange 2013 服务器相比，Exchange Online 使用非常相似的体系结构和概念。关于邮件连接器和 TLS 设置的主题，与 Exchange 邮件连接器和 TLS 设置相关的 Exchange Online 管理选项和配置设置与“Exchange 本地”界面和选项有显着不同。
• 需要在 发送 + 接收连接器和发送之间的不同参数 + 接收连接器。
  技术上简单来说，TLS 的配置并没有强制要求在 Exchange 连接器的展位上进行配置，即 Exchange 发送 + 接收连接器。
  但是，很多时候，业务使用强制 TLS 的要求将决定是否需要在连接器展位上配置 TLS。这种“需求”带来了另一个困难，因为 Exchange 本地发送连接器与 Exchange 本地接收连接器的选项和界面并不相同。

在 Exchange 本地环境中配置强制 TLS 选项

在本文中，我们将回顾如何在 Exchange 中配置“强制 TLS”选项2010 年本地。

快速提醒一下 - 默认情况下，Exchange 服务器配置为使用 机会 TLS 选项。

• 每次 Exchange 服务器尝试连接另一台邮件服务器时，他都会尝试使用 TLS 建立通信通道。
• 每次外部邮件服务器尝试与 Exchange 服务器通信时，Exchange 服务器都会“提议”使用 TLS 建立通信通道。

默认情况下，Office 365 使用 TLS 加密发送邮件，前提是目标服务器也支持 TLS。如果您的合作伙伴组织支持 TLS，则仅当您想要强制执行某些安全限制时才需要创建连接器 - 例如，您始终希望应用 TLS，或者每当邮件从合作伙伴发送到您的组织时都需要进行证书验证。

我们脑海中可能出现的问题是：

问：如果 Exchange 配置为使用 机会性 TLS 选项并始终尝试创建安全的通信链接，为什么或何时应该使用强制 TLS选项>？

A：这个问题的答案可能是

1.业务需要确保仅启用 TLS 通信。

安全需求或特定的监管要求，这表明需要验证我们的 Exchange 服务器和目标服务器之间的通信通道是使用 TLS 协议的加密通信通道。

换句话说 - 我们不愿意冒险特定组织或特定邮件服务器的通信链接将通过使用非加密协议（例如 SMTP）来实现。这是一个非黑即白的场景，我们唯一同意创建邮件通信通道的是 - 使用 TLS 协议。

2 需要识别“其他邮件服务器”。 ”

除了创建安全邮件通信通道的强制性需求之外，我们还希望定义与目标邮件服务器的 TLS 会话相关的其他安全设置。

例如，每个邮件服务器都需要有一个证书，该证书将用于加密在通信通道中流动的数据并可用于身份验证 - 每个邮件服务器都可以“出示”他的证书作为证明其合法身份的一种方式。

在某些情况下，除了强制需要使用 TLS 加密通信通道外，我们还需要通过指定应出现在其服务器证书上的特定参数来毫无疑问地证明“其他邮件服务器”的身份。

例如，验证目标邮件服务器是否使用公共证书，并检查其主机名是否出现在公共证书中。

为了能够满足这些要求，我们需要使用强制 TLS 选项。

1. 在 Exchange 本地环境中配置域安全（相互 TLS）选项

如前所述，在基于 Exchange 的环境中，强制 TLS 配置有两种风格使用邮件连接器。

1. 域安全（双向 TLS）
2. TlsAuth级别

在本节中，我们将简要回顾一下 Exchange 本地功能 - 域安全 和下一节，我们将回顾一下 TlsAuthLevel 选项
Domain Security 选项是仅与“双方”使用 Exchange 本地邮件基础结构的场景相关。

域安全（相互 TLS）选项可以在 Exchange 2010 和 2013 服务器版本中使用。

正确的披露是，我可以获得有关使用域安全选项时实现的特定参数的清晰且信息丰富的信息 （相互 TLS）。

域安全（Mutual TLS）解决方案是在“合作伙伴关系”的场景中实现的”。两个不同的 Exchange 组织希望在它们之间建立安全的通信通道。

域安全（相互 TLS）所需的配置需要在每个“关系中涉及的双方”。

使用域安全（相互 TLS）选项时，还涉及 Outlook 等 Exchange 客户端在此过程中，他们能够“理解”电子邮件地址何时从使用域安全 的“其他组织”发送（相互 TLS）与“我们的 Exchange 组织”。

在下图中，我们可以看到两个之间的域安全（相互 TLS）示例基于交换的组织。

“信任”是在名为 o365pilot.com 的 Exchange 组织与公共域名代表的 Exchange 组织（其他组织）之间创建的 - thankyouforsharing .org

我们不会详细介绍使用域安全选项所需配置的具体细节（相互 TLS）

但是，一般来说，要完成配置 域安全（相互 TLS）选项的任务在 Exchange 本地环境中，我们需要创建两个邮件连接器：

发送连接器和接收连接器r将用于与“合作伙伴”一起服务传入和传出邮件流。

阶段 1#2 - 配置启用域安全 |发送 + 接收连接器选项

当我们创建所需的发送连接器时，我们需要在“网络”选项卡中选中该选项 - 启用域安全（相互身份验证 TLS）。

当我们创建所需的接收连接器时，我们需要在“网络”选项卡中选中该选项 - 启用域安全（相互身份验证 TLS）。

阶段 2#2 - 使用 PowerShell 命令 Set-TransportConfig

我们需要使用两个 PowerShell 命令，这将在 发送连接器 上设置所需的参数，并接收连接器

在我们的场景中，我们将使用 PowerShell 命令来配置 域安全 （相互 TLS）与由域名 thankyouforsharing.org 表示的“其他 Exchange 组织”的关系是：

Set-TransportConfig -TLSSendDomainSecureList thankyouforsharing.org

下一个 PowerShell 命令将配置接收连接器

Set-TransportConfig -TLSReceiveDomainSecureList o365info.com

附上 Microsoft 文章中关于以下主题的一些引文：域安全（相互 TLS）：

相互 TLS 相互 TLS 身份验证与 TLS 不同，因为通常会部署 TLS。通常，部署 TLS 时，它仅用于以加密形式提供机密性。发送方和接收方之间不进行身份验证。
此外，有时部署 TLS 时，仅对接收服务器进行身份验证。 TLS 的这种部署是 TLS 的 HTTP 实现的典型。此实现是 SSL，
仅对接收服务器进行身份验证。
通过相互 TLS 身份验证，每台服务器通过验证另一台服务器提供的证书来验证另一台服务器的身份。在这种情况下，如果在 Exchange 2013 环境中通过经过验证的连接从外部域接收邮件，则 Microsoft Outlook 将显示“域安全”图标。
域安全 域安全是一组功能，例如证书管理、连接器功能和Outlook 客户端行为使相互 TLS 成为一种可管理且有用的技术。通过 Exchange 2013 客户端访问服务器路由出站电子邮件时，不支持域安全。
DomainSecureEnabled
DomainSecureEnabled 参数是为此服务的域启用相互传输层安全 (TLS) 身份验证的过程的一部分发送连接器。仅当满足以下条件时，相互 TLS 身份验证才能正确运行：
DomainSecureEnabled 参数的值必须为 $true。
DNSRoutingEnabled 参数的值必须为 $true。
IgnoreStartTLS 参数的值必须为 $true。为 $false。
配置为相互 TLS 身份验证的域中不支持通配符 (*)。还必须在相应的接收连接器和传输配置的 TLSReceiveDomainSecureList 属性中定义相同的域。
通过验证其他服务器提供的证书，因此根本不包括客户端。我们通常通过 Internet 在两个 Exchange 服务器之间建立安全的 SMTP 通道。
邮件客户端（例如 Outlook 和 Outlook Web App）将意识到已建立的域安全性。实施域安全的服务器之间交换的每条消息上都会显示带有复选标记的绿色图标。
域安全是指 Microsoft Exchange Server 2010 和 Microsoft Office Outlook 2007 中提供相对较低的功能集。 S/MIME 或其他消息级安全解决方案的成本替代方案。域安全功能集的目的是为管理员提供一种管理 Internet 上与业务合作伙伴的安全消息路径的方法。配置这些安全邮件路径后，从经过身份验证的发件人成功通过安全路径传输的邮件将在 Outlook 和 Microsoft Office Outlook Web App 界面中以“域安全”的形式向用户显示。
域安全性使用相互传输层安全性 (TLS) ) 身份验证提供基于会话的身份验证和加密。相互 TLS 身份验证与通常实施的 TLS 不同。通常，实施 TLS 后，客户端会通过验证服务器的证书来验证连接是否安全地连接到目标服务器。这是作为 TLS 协商的一部分接收的。在这种情况下，客户端在传输数据之前对服务器进行身份验证。但是，服务器不会对与客户端的会话进行身份验证。
通过相互 TLS 身份验证，每台服务器都会通过验证另一台服务器提供的证书来验证与另一台服务器的连接。在这种情况下，如果在 Exchange 2010 环境中通过经过验证的连接从外部域接收邮件，则 Outlook 2007 将显示“域安全”图标。

2. 使用 TlsAuthLevel 在 Exchange 中配置强制 TLS

在本节中，我们将回顾在 Exchange 本地环境中使用强制 TLS 的实施情况TlsAuthLevel 选项。

如前所述，“TlsAuthLevel”的使用将在“其他邮件服务器”不是基于 Exchange 的服务器或不是基于 Exchange 本地服务器的情况下实现。

例如，如果我们需要在 Exchange on- 之间配置 强制 TLS 选项Premises Server 和 Exchange Online 服务器，我们将需要使用 TlsAuthLevel 选项，因为尽管 Exchange Online 基于 Exchange 服务器架构，但 Exchange Online 与 Exchange on-Premises 服务器不同。

当前部分包括两部分

1. 设置 Exchange 本地强制 TLS 选项所需的配置发送连接器。
2. 设置 Exchange 本地强制 TLS 选项所需的配置接收连接器。

1. Exchange 本地发送连接器 |设置强制 TLS 选项

在本部分中，我们将重点关注“另一端”不是必需的 Exchange 本地服务器的情况下所需的强制 TLS 配置设置。

在这种情况下，我们需要使用 PowerShell 命令来帮助我们设置参数所需的值 - TlsAuthLevel

当我们打开 TlsAuthLevel 参数时，我们就“打开”了强制 TLS 选项。

TlsAuthLevel 参数的“激活”遵循配置与“其他邮件服务器”关系的三个可能选项之一。

我们可以从三个可能的选项中选择作为 TlsAuthLevel 的值

选项 1 -仅加密

-EncryptionOnly 选项适用于目标邮件服务器使用的证书无法用于“识别”邮件服务器的场景。例如目标邮件服务器使用自签名证书的场景。

在这种情况下，目标邮件服务器的证书将仅用于加密通过通信通道传递的数据。

也就是说，当我们配置EncryptionOnly选项时，意味着我们不需要通过检查对方的服务器证书来识别对方的邮件服务器。主要关注点是需要使用 TLS 加密通信通道。

选项 2 -证书验证

-CertificateValidation 选项，适用于源邮件服务器（我们场景中的 Exchange 服务器）需要验证目标邮件服务器身份的场景。

目标邮件服务器可以通过提供由公共CA（证书颁发机构）创建的公共证书来证明其身份。

选项 3 - 域验证

-DomainValidation 选项可以认为是限制性最强的选项。

在这种情况下，强制性要求将包括以下部分：

• 需要对通过通信通道传递的数据进行加密。
• 需要识别目标服务器。目标邮件服务器需要提供由 CA 创建的合法公共证书。
• 目标服务器提供的证书必须包含以下选项之一：FQDN 或由附加参数配置的域名 TlsDomain

当我们使用 DomainValidation 选项时，我们还需要提供 TlsDomain 的附加值。

当使用 TlsDomain 选项时，我们需要“激活”名为 RequireTls 的附加参数

在下图中，我们可以看到与强制 TLS 相关的各种选项和组合。

为了能够演示当我们想要配置 强制 TLS 选项时需要使用的所需 PowerShell 命令语法>，让我们使用以下场景：

我们希望与使用公共域名的公司合作伙伴实施强制 TLS 配置 - contoso.com

在我们的场景中，我们都创建了一个专用的 发送连接器，用于将电子邮件发送到来自域 contoso.com 的收件人

发送连接器的名称是 - Contoso

场景 1 - 仅使用强制 TLS 选项来加密邮件流

在这种情况下，不需要识别其他邮件服务器。

TlsAuthLevel级别将通过配置参数EncryptionOnly来设置

PowerShell 命令语法为：

Set-SendConnector -Identity Contoso -TlsAuthLevel EncryptionOnly

场景 2 - 加密邮件流+向其他邮件服务器请求有效的服务器证书

在这种情况下，我们需要识别其他邮件服务器。其他邮件服务器需要提供有效的服务器证书。

TlsAuthLevel级别将通过配置参数CertificateValidation来设置

PowerShell 命令语法为：

Set-SendConnector -Identity Contoso -TlsAuthLevel CertificateValidation

场景 3 - 加密邮件流 + 从其他邮件服务器请求有效的服务器证书 + 验证服务器证书是否包含特定主机名

在这种情况下，我们希望使用强制 TLS 选项，除了需要加密通信线路之外，我们还希望能够识别 Contoso 邮件服务器，验证其是否使用受信任的公共证书以及此外，验证服务器证书是否包含域名 - contoso.com

TlsAuthLevel级别将通过配置参数DomainValidation来设置

当使用-DomainValidation选项时，我们需要设置两个额外的参数

TlsDomain 参数 - TlsDomain 参数用于定义需要包含在“其他邮件服务器”作为其身份证明的服务器证书中的特定主机名或域名。
RequireTls $true

PowerShell 命令语法为：

Set-SendConnector -Identity contoso3 -RequireTls $true -TlsAuthLevel DomainValidation -TlsDomain *.contoso.com

附上 Microsoft TechNet 文章的引用：

TlsAuthLevel
TlsAuthLevel 参数指定用于此发送连接器建立的出站 TLS 连接的 TLS 身份验证级别。有效值为：
EncryptionOnly：TLS 仅用于加密通信通道。未执行证书身份验证。
CertificateValidation：TLS 用于加密通道和证书链验证，并执行吊销列表检查。
DomainValidation：除了通道加密和证书验证之外，发送连接器还验证 FQDN目标证书的域与 TlsDomain 参数中指定的域匹配。如果 TlsDomain 参数中未指定域，则会将证书上的 FQDN 与收件人的域进行比较。
如果 IgnoreSTARTTLS 参数设置为 $true，或者 RequireTLS 参数为设置为 $false。

TlsDomain 参数指定发送连接器在建立 TLS 安全连接时用于验证目标证书的 FQDN 的域名。
仅当 TlsAuthLevel 参数设置为 DomainValidation 时才使用此参数。
一个值如果满足以下条件，则需要此参数：
TLSAuthLevel 参数设置为 DomainValidation。
DNSRoutingEnabled 参数设置为 $false（智能主机发送连接器）。

2.交换本地接收连接器 |设置强制 TLS 选项

关于在本地 Exchange 接收连接器上实施强制 TLS 选项所需的配置，我们需要使用两个参数的组合：

1. 认证机制
2. RequireTLS - 该值“激活”强制 TLS 选项

在下面的屏幕截图中，我们可以看到 Exchange 本地接收连接器的默认参数的示例。

我们可以看到参数 - AuthMechanism 包含几个选项，其中包括 TLS。
此外，我们可以看到 RequireTLS 参数的默认值设置为 False>。

在我们的场景中，我们希望对由域名（thankyouforsharing.org）代表的合作伙伴发送给我们的邮件实施强制 TLS 选项

我们已在名为 - EX01 的 Exchange 本地服务器上创建了接收连接器，连接器名称为 -thanksyouforsharing.org

为了能够将 Exchange 本地接收连接器配置为使用强制 TLS，我们需要将 RequireTLS 参数的值设置为 true。

我们将在我们的场景中使用的 PowerShell 命令是：

Set-ReceiveConnector EX01\<strong><em>thankyouforsharing-receive</em></strong> -RequireTLS $true

附上微软文章的一些引用：

AuthMechanism 参数指定公布和接受的身份验证机制。身份验证选项包括“无”、“Tls”、“集成”、“BasicAuth”、“BasicAuthRequireTLS”、“ExchangeServer”和“ExternalAuthoritative”。您可以为 AuthMechanism 参数输入多个值，方法是用逗号分隔各个值。
如果 RequireTLS 参数设置为 $true，则 AuthMechanism 参数必须设置为 TLS（传输层安全性）。如果将 AuthMechanism 参数设置为 BasicAuthRequireTLS，则还必须选择 BasicAuth 和 TLS。
AuthMechanism 参数值ExternalAuthoritative 只能与值Tls 共存。如果将 AuthMechanism 参数设置为ExternalAuthoritative，则 PermissionGroups 参数也必须具有该值

下一篇

TLS 文章系列中的下一篇文章（强制 TLS | Exchange Online 环境与 Exchange 本地环境 | 第 5#12 部分）专门讨论以下主题：基于 Exchange 本地环境与 Exchange 本地环境之间存在的差异基于 Exchange Online 的环境，涉及邮件连接器和 TLS 设置，以及我们将在 TLS 文章系列的下一篇文章中使用的方案字符的描述，这将帮助我们演示 Exchange 本地和基于 Exchange Online 的环境之间的可选 TLS 流。