在 Exchange Server 中配置 Windows 扩展保护
概述
Windows 扩展保护 增强了 Windows Server 中的现有身份验证，并缓解身份验证中继或中间人 (MitM) 攻击。 此缓解措施通过使用安全信息来实现，该信息通过指定的通道绑定信息实现， Channel Binding Token (CBT) 该信息主要用于 TLS 连接。
安装 Exchange Server 2019 CU14 (或更高版本) 时，默认启用扩展保护。 有关详细信息，请参阅已发布：2024 H1 Exchange Server累积更新。
例如，在较旧版本的 Exchange Server (（Exchange Server 2016) ），可以在部分或所有 Exchange 服务器上通过 ExchangeExtendedProtectionManagement.ps1 脚本的帮助启用扩展保护。
本文档中使用的术语
虚拟目录或 vDir
由 Exchange Server 用于允许访问 、 Outlook on the Web和 AutoDiscover 等 Exchange ActiveSyncWeb 应用程序。 管理员可以配置多个虚拟目录设置，包括身份验证、安全性和报告设置。 扩展保护就是此类身份验证设置之一。
扩展保护设置
控制检查 Channel Binding Tokens 或 CBT的行为。 下表列出了此设置的可能值：
| 扩展保护设置 | 说明 |
|---|---|
| 无 | 指定 IIS 不执行 CBT 检查。 |
| 允许 | 指定启用 CBT 检查，但不是必需的。 此设置允许与支持扩展保护的客户端进行安全通信，并且仍支持无法使用扩展保护的客户端。 |
| 需要 | 此值指定需要进行 CBT 检查。 此设置阻止不支持扩展保护的客户端。 |
SSL 标志
需要配置 SSL 设置，以确保客户端使用客户端证书以特定方式连接到 IIS 虚拟目录。 若要启用扩展保护，所需的 SSL 标志为 SSL 和 SSL128。
SSL 卸载
终止客户端与Exchange Server设备上的连接，然后使用非连接连接到Exchange Server。
SSL 桥接
描述位于网络边缘的设备解密 SSL 流量，然后在将其发送到 Web 服务器之前对其进行重新加密的过程。
新式混合代理或混合代理
这是配置 Exchange 混合的方法的名称，该方法删除了经典混合 (的某些配置要求，例如，通过防火墙的入站网络连接) 启用 Exchange 混合功能。 可 在此处了解有关此功能的详细信息。
公用文件夹
专为共享访问而设计，有助于使深层层次结构中的内容更易于浏览。 可 在此处了解有关公用文件夹的详细信息。
在 Exchange Server 上启用扩展保护的先决条件
重要
建议运行 Exchange Server 运行状况检查器脚本，以检查是否满足应激活扩展保护的 Exchange 服务器上的所有先决条件。
支持扩展保护的 Exchange 服务器版本
从 2022 年 8 月开始的 Exchange Server 2013、2016 和 2019 Exchange Server 安全更新 (SU) 版本支持扩展保护。
如果组织已安装 Exchange Server 2016 或 Exchange Server 2019，则必须运行2021 年 9 月季度 Exchange 累积汇报或 2022 H1 累积更新。 在继续配置扩展保护之前， 必须 至少安装 2022 年 8 月或更高版本的安全更新。
如果组织已安装 Exchange Server 2013，Exchange Server必须在 CU23 上安装 2022 年 8 月或更高版本的安全更新。
警告
Exchange Server 2013 已于 2023 年 4 月 11 日终止支持。
Outlook Anywhere 配置要求
默认情况下，已启用 的 Outlook Anywhere SSL 卸载，必须在启用扩展保护之前 禁用 。 按照 示例 3 中所述的步骤进行操作。
重要
Exchange Server 2019 CU14 (或更高版本) 安装程序自动禁用 SSL 卸载Outlook Anywhere。 这是默认启用的扩展保护评估的一部分。
NTLM 版本要求
NTLMv1 很弱，无法防止中间人 (MitM) 攻击。 它应 被视为易受攻击， 不再使用。
NTLMv1 不能与扩展保护一起使用。 如果强制客户端使用 NTLMv1 而不是 NTLMv2 ，并且已在 Exchange 服务器上启用了扩展保护，则此配置会导致客户端出现密码提示，而无法成功对 Exchange 服务器进行身份验证。
注意
为了提高安全性，建议查看并配置此设置，无论是否遇到问题。
如果在启用扩展保护后客户端上遇到密码提示，则应在客户端和Exchange Server端检查以下注册表项和值：
注册表项： HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
注册表值： LmCompatibilityLevel
建议将其设置为 的值 5，即 Send NTLMv2 response only. Refuse LM & NTLM。 它必须至少设置为 的 3Send NTLMv2 response only值为 。
如果删除该值，操作系统将强制实施系统默认值。 在 Windows Server 2008 R2 及更高版本中，我们将其视为设置为 3。
如果要集中管理设置，可以使用 组策略：
策略位置： Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
详细信息： 网络安全：LAN 管理器身份验证级别
TLS 要求
在启用扩展保护之前，必须确保所有 Exchange 服务器中的所有 TLS 配置都是一致的。 例如，如果其中一个服务器使用 TLS 1.2，则必须确保使用 配置 TLS 1.2组织中的所有服务器。 服务器之间 TLS 版本使用的任何变化都可能导致客户端或服务器到服务器的连接失败。
除此要求外，还必须将 SchUseStrongCrypto 注册表值的值设置为 1 组织内所有 Exchange 服务器的值。
如果未将此值显式设置为 1，则可以将此键的默认值解释为 0 或1，具体取决于Exchange Server二进制文件使用的 .NET 版本，并且你可能会遇到服务器到服务器的通信连接问题。 这种情况可能发生，尤其是在不同版本的Exchange Server (（例如，Exchange Server 2016 和 Exchange Server 2019) ）正在使用时。
这同样适用于 SystemDefaultTlsVersions 注册表值，还必须将其显式设置为 值 1。
如果这些注册表值未按预期配置，则这种错误配置可能会导致服务器到服务器或客户端到服务器的通信中的 TLS 不匹配，从而导致连接问题。
请参阅此Exchange Server TLS 配置最佳做法指南，在 Exchange 服务器上配置所需的 TLS 设置。
第三方软件兼容性
确保测试在Exchange Server环境中运行的所有第三方产品，以确保在启用扩展保护后它们正常工作。
例如，我们看到了防病毒解决方案，它们通过本地代理服务器发送连接以保护客户端计算机。 这种情况会阻止与 Exchange 服务器的通信，并且需要禁用，因为它被视为中间人 (MitM) 连接，扩展保护会阻止该连接。
启用扩展保护时可能影响客户端连接的方案
SSL 卸载方案
在使用 SSL 卸载的环境中 不支持 扩展保护。 SSL 卸载期间 SSL 终止会导致扩展保护失败。 若要在 Exchange 环境中启用扩展保护， 不得对负载均衡器使用 SSL 卸载 。
SSL 桥接方案
在某些条件下使用 SSL 桥接的环境中 ，支持 扩展保护。 若要使用 SSL 桥接在 Exchange 环境中启用扩展保护， 必须在 Exchange 和负载均衡器上使用相同的 SSL 证书。 使用不同的证书会导致扩展保护通道绑定令牌检查失败，从而阻止客户端连接到 Exchange 服务器。
扩展保护和公用文件夹方案
以下部分介绍在启用扩展保护时可能导致失败的公用文件夹方案。
无法在共存环境中具有公用文件夹的 Exchange Server 2013 服务器上启用扩展保护
若要在 Exchange Server 2013 上启用扩展保护，请确保没有任何托管在 Exchange Server 2013 上的公用文件夹。 如果 Exchange Server 2013 与 Exchange Server 2016 或 Exchange Server 2019 共存，则必须将公用文件夹迁移到 Exchange Server 2016 或 Exchange Server 2019，然后才能启用扩展保护。 启用扩展保护后，Exchange Server 2013 上存在公用文件夹，它们将不再向最终用户显示！
警告
Exchange Server 2013 已于 2023 年 4 月 11 日终止支持。
无法在承载公用文件夹层次结构的 Exchange Server 2016 CU22 或 Exchange Server 2019 CU11 或更早版本上启用扩展保护
如果环境包含 Exchange Server 2016 CU22 或 Exchange Server 2019 CU11 或更早版本，并且正在使用公用文件夹，则必须在启用扩展保护之前确认托管公用文件夹层次结构的服务器版本！
确保托管公用文件夹层次结构的服务器已升级到 Exchange Server 2016 CU23 或 Exchange Server 2019 CU12 (或更高版本) ，并安装了最新的安全汇报。 如果无法将 Exchange 服务器升级到受支持的版本，请将公用文件夹层次结构移动到运行所需版本的Exchange Server。
下表可用于阐明：
| Exchange 版本 | 已安装 CU | 已安装 SU | 托管 PF 邮箱 | 是否支持 EP？ |
|---|---|---|---|---|
| Exchange 2013 | CU23 | 2022 年 8 月 (或更高版本) | 否 | 是 |
| Exchange 2016 | CU22 | 2022 年 8 月 (或更高版本) | 无层次结构邮箱 | 是 |
| Exchange 2016 | CU23 (2022 H1) 或更高版本 | 2022 年 8 月 (或更高版本) | 任何 | 是 |
| Exchange 2019 | CU11 | 2022 年 8 月 (或更高版本) | 无层次结构邮箱 | 是 |
| Exchange 2019 | CU12 (2022 H1) 或更高版本 | 2022 年 8 月 (或更高版本) | 任何 | 是 |
| 任何其他版本 | 任何其他 CU | 任何其他 SU | 任何 | 否 |
扩展保护和新式混合配置
以下部分介绍Exchange Server新式混合方案，在启用扩展保护时可能会导致故障。
无法在使用混合代理发布的 Exchange 服务器上完全配置扩展保护
在现代混合配置中，Exchange 服务器通过混合代理发布，该代理将Exchange Online调用代理到 Exchange 服务器。
在通过混合代理发布的 Exchange 服务器上启用扩展保护可能会导致混合功能（如邮箱移动和忙/闲呼叫）（如果未正确执行）中断。 因此，必须识别所有 Exchange 服务器，这些服务器是通过混合代理的帮助发布的，并且不要在 Front-End EWS 虚拟目录上启用扩展保护。
标识使用混合代理发布的 Exchange 服务器
如果没有通过混合代理发布的服务器列表，可以使用以下步骤来标识它们。 如果要运行经典Exchange Server混合部署，则不需要执行这些步骤。
- 登录到安装了混合代理的计算机，并打开混合代理的 PowerShell 模块 。 运行
Get-HybridApplication以标识TargetUri混合代理使用的 。 - 参数
TargetUri提供 Exchange 服务器的 Fqdn，该服务器配置为由混合代理使用。- 使用 Fqdn 推断 Exchange 服务器标识，并记下 Exchange 服务器名称。
- 如果在 中使用
TargetUri负载均衡器 URL，Client Access则需要标识所有安装了角色的 Exchange 服务器，以及可在 负载均衡器 URL 后面访问哪些服务器。
重要
不能在通过混合代理发布的 Exchange 服务器上的 Front-End EWS 虚拟目录上启用扩展保护。
建议执行以下步骤来保护通过混合代理发布的 Exchange 服务器：
注意
在以下方案中，混合代理安装在不运行Exchange Server的服务器上。 此外，此服务器位于与生产 Exchange 服务器不同的网络段中。
- 对于通过混合代理发布的 Exchange 服务器，入站连接应受防火墙限制，仅允许从安装了混合代理的计算机进行连接。 这不会影响从 Exchange 服务器到Exchange Online的出站通信。
- 不应在通过混合代理发布的 Exchange 服务器上托管任何邮箱。 现有邮箱应迁移到其他邮箱服务器。
启用扩展保护
在 Exchange Server 2019 CU14 (或更高版本) 设置期间，会自动启用扩展保护。 在支持扩展保护的旧版 Exchange Server 上，可以通过 Microsoft 提供的脚本启用扩展保护， (建议) 或通过 IIS 管理器手动启用。
若要正确配置扩展保护，组织中的所有 Exchange 服务器上的每个虚拟目录 (边缘传输服务器) 都必须设置为 和 sslFlags的Extended Protection指定值。
下表汇总了 Microsoft Exchange 受支持版本上每个虚拟目录所需的设置。
| IIS 网站 | 虚拟目录 | 建议的扩展保护 | 建议的 sslFlags |
|---|---|---|---|
Default Website |
API |
Required |
Ssl,Ssl128 |
Default Website |
AutoDiscover |
Off |
Ssl,Ssl128 |
Default Website |
ECP |
Required |
Ssl,Ssl128 |
Default Website |
EWS |
Accept (UI) / Allow (脚本) |
Ssl,Ssl128 |
Default Website |
MAPI |
Required |
Ssl,Ssl128 |
Default Website |
Microsoft-Server-ActiveSync |
Accept (UI) / Allow (脚本) |
Ssl,Ssl128 |
Default Website |
Microsoft-Server-ActiveSync/Proxy |
Accept (UI) / Allow (脚本) |
Ssl,Ssl128 |
Default Website |
OAB |
Accept (UI) / Allow (脚本) |
Ssl,Ssl128 |
Default Website |
OWA |
Required |
Ssl,Ssl128 |
Default Website |
PowerShell |
Off |
SslNegotiateCert |
Default Website |
RPC |
Required |
Ssl,Ssl128 |
Exchange Backend |
API |
Required |
Ssl,Ssl128 |
Exchange Backend |
AutoDiscover |
Off |
Ssl,Ssl128 |
Exchange Backend |
ECP |
Required |
Ssl,Ssl128 |
Exchange Backend |
EWS |
Required |
Ssl,Ssl128 |
Exchange Backend |
Microsoft-Server-ActiveSync |
Required |
Ssl,Ssl128 |
Exchange Backend |
Microsoft-Server-ActiveSync/Proxy |
Required |
Ssl,Ssl128 |
Exchange Backend |
OAB |
Required |
Ssl,Ssl128 |
Exchange Backend |
OWA |
Required |
Ssl,Ssl128 |
Exchange Backend |
PowerShell |
Required |
Ssl,SslNegotiateCert,Ssl128 |
Exchange Backend |
RPC |
Required |
Ssl,Ssl128 |
Exchange Backend |
PushNotifications |
Required |
Ssl,Ssl128 |
Exchange Backend |
RPCWithCert |
Required |
Ssl,Ssl128 |
Exchange Backend |
MAPI/emsmdb |
Required |
Ssl,Ssl128 |
Exchange Backend |
MAPI/nspi |
Required |
Ssl,Ssl128 |
注意
在初始版本发布后，我们已更新为 而不是 ，Default Website/PowerShell并更新为 Off 而不是 Required。RequiredAccept/AllowDefault Website/OAB 更改为 Default Website/OAB 的原因是Outlook for Mac客户端无法使用 设置下载 Required OAB。 更改为 Default Website/PowerShell 的原因是，Exchange Server默认配置不允许使用 NTLM 身份验证连接到 PowerShell Front-End 虚拟目录，因此，扩展保护不适用。
除非 Microsoft 客户服务和支持 (CSS) 明确建议，否则不支持对 Default Website/PowerShell 虚拟目录进行修改。
使用 Exchange Server 2019 CU14 (或更高版本) 安装程序启用扩展保护
对于 Exchange Server 2019 CU14 及更高版本，Exchange Server 2019 累积更新 (CU) 安装程序会自动在执行安装程序的邮箱服务器上启用扩展保护。 对于任何新安装或将现有Exchange Server安装升级到最新版本时，都会发生这种情况。
在无人参与安装模式下，可以使用两个新参数来控制默认启用的扩展保护行为。
这些参数可用于跳过自动激活扩展保护 () /DoNotEnableEP 或未在 Front-End EWS 虚拟目录上启用扩展保护 (/DoNotEnableEP_FEEWS) 。
警告
禁用扩展保护会使服务器容易受到已知 Exchange 漏洞的攻击，并削弱对未知威胁的保护。 建议启用此功能。
扩展保护 CU 安装程序配置方案
在本部分中，我们将提供在 Exchange Server 2019 CU14 (或更高版本的帮助下在 Exchange Server 上配置扩展保护的最常见方案，) 累积更新 (CU) 安装程序。
确保正确配置 Exchange 服务器，并满足在 Exchange Server 上启用扩展保护的先决条件部分中概述的要求。
方案 1：在 Exchange Server 2019 上启用扩展保护
在参与或无人参与模式下运行Exchange Server 2019 CU14 (或更高版本) 设置。 安装程序将在运行扩展保护的服务器安装过程中配置扩展保护。
方案 2：在通过混合代理发布的 Exchange Server 2019 上启用扩展保护
按照 使用混合代理标识发布的 Exchange 服务器 部分中概述的步骤来标识通过混合代理发布的 Exchange 服务器。
使用 /DoNotEnableEP_FEEWS 参数在无人参与模式下运行Exchange Server 2019 CU14 (或更高版本) 设置。 它跳过在 Front-End EWS 虚拟目录上启用扩展保护：
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP_FEEWS
方案 3：跳过 Exchange Server 2019 CU14 (或更高版本启用扩展保护) 设置
使用 /DoNotEnableEP 参数在无人参与模式下运行Exchange Server 2019 CU14 (或更高版本) 设置。 它跳过了启用扩展保护：
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP
警告
不启用扩展保护会使服务器容易受到已知 Exchange 漏洞的攻击，并削弱对未知威胁的保护。 建议打开此功能。
使用 PowerShell 脚本启用扩展保护
可以使用 ExchangeExtendedProtectionManagement.ps1 脚本，在部分或所有 Exchange 服务器上同时启用扩展保护。
重要
在Exchange Server环境中启用扩展保护涉及在所有 Exchange 服务器上进行许多更改。 建议使用 Microsoft 提供的脚本，而不是通过 IIS 管理器手动进行这些更改。
在运行脚本以配置扩展保护之前，请确保下载最新版本的脚本。
可以在环境中安装了 Exchange 命令行管理程序 (EMS) 的任何特定Exchange Server上运行脚本。
使用 PowerShell 脚本配置扩展保护的权限
运行脚本的用户必须是角色组的成员 Organization Management 。 必须从提升的 Exchange 命令行管理程序 (EMS) 执行脚本。
扩展保护脚本配置方案
在本部分中，我们将提供在 ExchangeExtendedProtectionManagement.ps1PowerShell 脚本的帮助下在 Exchange Server 上配置扩展保护的最常见方案。
有关更多示例和脚本参数的说明，请阅读脚本 文档 。
方案 1：在所有Exchange Server启用扩展保护
按如下所示运行脚本，在组织内的所有 Exchange 服务器上启用扩展保护：
.\ExchangeExtendedProtectionManagement.ps1
该脚本会执行多项检查，以确保所有 Exchange 服务器都处于启用扩展保护所需的最低 CU 和 SU 版本。 它还会检查所有 Exchange 服务器是否都使用相同的 TLS 配置。
通过先决条件检查后，脚本将启用扩展保护，并在范围内所有 Exchange 服务器的所有虚拟目录上添加所需的 SSL 标志。 如果 Exchange 服务器未满足 (要求（例如，如果) 检测到不一致的 TLS 配置），则会停止。
方案 2：在运行新式混合配置时配置扩展保护
如果具有新式混合配置，则必须跳过在 Exchange 服务器上的 Front-End EWS 虚拟目录上启用扩展保护，该目录是使用新式混合代理发布的。
可以使用 参数完成 ExcludeVirtualDirectories 此配置：
.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames MHServer1, MHServer2 -ExcludeVirtualDirectories "EWSFrontEnd"
使用 IIS 管理器启用扩展保护
如果要在不使用脚本的情况下在环境中手动启用扩展保护，可以使用以下步骤。
注意
手动启用扩展保护时，请确保 Exchange 服务器上的所有虚拟目录都根据 上表所述配置了扩展保护。
在虚拟目录上将扩展保护设置为必需或接受
IIS Manager (INetMgr.exe)在要配置扩展保护的 Exchange 服务器上启动- 转到
Sites并选择Default Web Site或Exchange Back End - 选择要配置的虚拟目录
- 选择
Authentication - 如果
Windows Authentication已启用，请选择Windows Authentication
- 选择
Advanced Settings右侧) (，然后在打开的窗口中，从“扩展保护”下拉列表中选择适当的值
为虚拟目录设置所需的 SSL 设置
- 单击虚拟目录以打开主页
- 选择
SSL Settings - 检查
Require SSL设置，确保Require SSL为虚拟目录启用
- 单击
Apply以确认新设置
禁用扩展保护
可以使用 ExchangeExtendedProtectionManagement.ps1 PowerShell 脚本禁用扩展保护。
警告
禁用扩展保护会使服务器容易受到已知 Exchange 漏洞的攻击，并削弱对未知威胁的保护。 建议启用此功能。
以下命令将通过将所有当前配置位置的值设置为 None来禁用所有联机 Exchange Server 的扩展保护配置：
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection
还可以指定应禁用扩展保护的服务器子集：
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection -ExchangeServerNames ExchServer1, ExchServer2
疑难解答
本部分包含扩展保护存在的已知问题，并列出了已知故障方案的一些故障排除提示。
扩展保护的已知问题
提示
已修复以前报告的所有Exchange Server扩展保护问题。 我们强烈建议为组织中运行的 Exchange 版本安装最新的Exchange Server更新，以便从最新的修补程序和改进中受益。
问题：在 Exchange Server 2019 CU14 无人参与模式安装程序中执行 /PrepareSchema、/PrepareDomain 或 /PrepareAllDomains 时，显示已激活扩展保护
这是Exchange Server 2019 CU14 的已知问题，可以放心忽略。 运行 /PrepareSchema/PrepareDomain 或/PrepareAllDomains准备环境时，不会启用扩展保护，如准备 active Directory 和域Exchange Server文档中所述。
问题：使用 Outlook 客户端更改公用文件夹的权限失败，并出现以下错误：“无法更改修改的权限”
如果尝试更改其权限的公用文件夹托管在辅助公用文件夹邮箱上，而主公用文件夹邮箱位于其他服务器上，则会发生此问题。
最新Exchange Server更新已修复此问题。 按照 此知识库 中概述的说明启用修复。
扩展保护配置脚本执行期间的警告和错误
该脚本显示已知问题的警告，并要求确认：
为了防止管理员遇到由于启用扩展保护而中断现有Exchange Server功能的情况，该脚本提供了具有已知问题的方案列表。 在启用扩展保护之前，请仔细阅读并评估此列表。 可以通过按
Y继续打开扩展保护。
脚本未启用扩展保护，因为先决条件检查失败：
没有 Exchange 服务器运行支持扩展保护的内部版本：
如果组织中没有 Exchange 服务器正在运行支持扩展保护的内部版本，则脚本不会在不支持的服务器上启用扩展保护，以确保服务器到服务器的通信不会失败。
若要解决此问题，请将所有 Exchange 服务器更新为最新的 CU 和 SU，并再次运行脚本以启用扩展保护。
检测到 TLS 不匹配：
范围中的所有 Exchange 服务器上 都需要有效且一致的 TLS 配置 。 如果范围内所有服务器上的 TLS 设置不同，则启用扩展保护会中断与邮箱服务器的客户端连接。
有关详细信息，请阅读Exchange Server TLS 配置最佳做法。
某些 Exchange 服务器不可用/无法访问：
该脚本针对范围内的所有 Exchange 服务器执行多个测试。 如果无法访问其中一个或多个服务器，脚本会排除它们，因为它无法在这些计算机上执行所需的配置操作。
如果服务器处于脱机状态，则应在服务器恢复联机后立即配置扩展保护。 如果由于其他原因无法访问服务器，则应在服务器本身上运行脚本以启用扩展保护。
用户无法通过一个或多个客户端访问其邮箱
在管理员启用扩展保护后，某些或所有客户端可能开始向用户提供身份验证错误的原因可能有多种。 如果发生此问题，检查以下部分：
例如，如果 Exchange 组织中的 TLS 配置不是相同的 (，则启用扩展保护后，某个 Exchange 服务器上的 TLS 配置已更改) ，则此错误配置可能会导致客户端连接失败。 若要解决此问题，检查在所有 Exchange 服务器上正确配置 TLS 的说明，然后使用脚本再次配置扩展保护。
检查是否使用了 SSL 卸载。 任何 SSL 终止都会导致扩展保护通道绑定令牌检查失败，因为 SSL 卸载被视为中间人，这是扩展保护所阻止的。 若要解决此问题，请禁用 SSL 卸载并使用脚本再次启用扩展保护。
用户可以使用 Outlook for Windows 和 Outlook 网页版访问其电子邮件，但不能通过非 Windows 客户端（如 Outlook for Mac、Outlook Mobile 或 iOS 本机电子邮件客户端）访问电子邮件。 如果在一台或所有 Front-End 服务器上将 EWS 和/或Exchange ActiveSync的扩展保护设置设置为
Required，则可能会发生这种情况。若要解决此问题，请使用 参数运行
ExchangeExtendedProtectionManagement.ps1脚本ExchangeServerNames，并传递 Exchange 服务器的名称，该服务器具有错误配置的扩展保护设置。 还可以运行不带任何参数的脚本来检查并再次为所有服务器配置扩展保护或者，还可以使用
IIS Manager (INetMgr.exe)这些虚拟目录的扩展保护设置并将其更改为 表中列出的正确值。 强烈建议使用脚本，因为它检查正确的值，如果值未按预期设置，则自动执行重新配置。如果执行上述步骤后，某些客户端仍无法按预期工作，你可以暂时回滚扩展保护，并通过向我们提出支持案例向 Microsoft 报告问题。 按照 禁用扩展保护 部分中所述的步骤进行操作。
混合忙/闲或邮箱迁移不起作用
如果使用新式混合，启用扩展保护可能会导致混合功能（如闲/忙和邮箱迁移）停止工作，前提是未按本文所述执行配置。 若要解决此问题， 请确定使用混合代理发布的混合服务器 ，并 对这些服务器上的 Front-End EWS 虚拟目录禁用扩展保护。
公用文件夹不再可见/可访问
启用扩展保护时，有两个问题可能会影响公用文件夹连接。 请务必按照本文 的扩展保护和公用文件夹 部分中所述的说明进行操作。
常见问题解答
问题： 如果已在以前的累积更新 (CU) 上安装 2022 年 8 月安全更新 (SU) ，是否需要安装它？
回答：是的，如果更新到较新的 CU 版本 (（例如，Exchange Server 2019 CU11 Exchange Server 2019 CU12) ），则需要再次安装 2022 年 8 月 SU。
记得： 如果计划立即执行更新 (意味着 CU + SU 安装) ，则不需要关闭扩展保护。 如果计划在不立即安装 SU 的情况下继续使用 CU，则必须禁用扩展保护，因为 CU 生成 (未) 安装 SU，不支持扩展保护，因此可能会遇到客户端连接问题。
问题：在使用 Active Directory 联合身份验证服务 (AD FS) Outlook 网页版 (OWA) 的环境中启用扩展保护是否安全？
回答： 是的，扩展保护不会影响使用 OWA 进行基于 AD FS 声明的身份验证。
问题： 在使用混合新式身份验证 (HMA) 的环境中启用 Windows 扩展保护是否安全？
回答： 是的，HMA 不会受到此更改的影响。 虽然扩展保护不会进一步增强 HMA，但Windows 身份验证仍可用于不支持混合新式身份验证的应用程序。鉴于此，建议在仍具有 Exchange 本地服务的任何符合条件的环境中启用扩展保护。
问题： 扩展保护是否影响混合新式身份验证或 Microsoft Teams 集成？
回答： 扩展保护不会影响 Microsoft Teams 集成或混合新式身份验证。
问题：使用 HTTP 400 状态代码启用扩展保护后，我无法访问 OWA/ECP，我的 OWA/ECP 是通过 Entra 应用程序代理发布的，我该如何解决此问题？
回答：不支持通过 Entra 应用程序代理发布 Exchange OWA/ECP，你需要通过扩展保护标准支持的网络拓扑发布 OWA/ECP。
问题： 虽然我们知道防止 MitM 攻击很重要，但我们能否将自己的设备与自己的证书在中间？
回答： 如果设备使用与 Exchange 服务器相同的证书，则可以使用它们。