你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

增强安全性混合消息传递基础结构 - 桌面客户端访问

Microsoft Entra ID
Microsoft 365
Office 365

本文介绍如何为访问 Microsoft Exchange 的 Outlook 桌面客户端实现多重身份验证。 与具有用户邮箱的 Microsoft Exchange 存在的四种不同可能性相对应的四种体系结构:

注意

在图中,黑色虚线显示本地 Active Directory、Microsoft Entra Connect、Microsoft Entra ID、AD FS 和 Web 应用程序代理组件之间的基本交互。 可以在混合标识所需的端口和协议中了解有关这些交互的信息。

体系结构(Exchange Online)

Diagram that shows an architecture for enhanced security in an Outlook client access scenario. The user's mailbox is in Exchange Online.

下载包含本文中所有示意图的 Visio 文件

在此方案中,用户需要使用支持新式身份验证的 Outlook 客户端版本。 有关详细信息,请参阅如何对 Office 2013、Office 2016 和 Office 2019 客户端应用使用新式身份验证。 该体系结构涵盖 Outlook for Windows 和 Outlook for Mac。

工作流(Exchange Online)

  1. 用户尝试通过 Outlook 访问 Exchange Online。
  2. Exchange Online 提供 Microsoft Entra 终结点的 URL,用于检索访问令牌以获取对邮箱的访问权限。
  3. Outlook 使用该 URL 连接到 Microsoft Entra ID。
  4. 域联合后,Microsoft Entra ID 会将请求重定向到本地 AD FS。
  5. 用户在 AD FS 登录页上输入凭据。
  6. AD FS 会将会话重定向回 Microsoft Entra ID。
  7. Microsoft Entra ID 对移动应用和桌面客户端应用具有多重身份验证要求的 Azure 条件访问策略。 有关设置该策略的信息,请参阅本文的部署部分
  8. 条件访问策略调用 Microsoft Entra 多重身份验证。 用户获取完成多重身份验证的请求。
  9. 用户完成多重身份验证。
  10. Microsoft Entra ID 发出访问和刷新令牌,并将其返回到客户端。
  11. 通过使用访问令牌,客户端连接到 Exchange Online 并检索内容。

配置(Exchange Online)

若要阻止尝试通过旧式身份验证访问 Exchange Online (关系图中的红色虚线),需要创建一个身份验证策略,以禁用 Outlook 服务使用的协议的旧式身份验证。 以下是需要禁用的特定协议:自动发现、MAPI、脱机通讯簿和 EWS。 下面是相应的配置:

AllowBasicAuthAutodiscover : False

AllowBasicAuthMapi : False

AllowBasicAuthOfflineAddressBook : False

AllowBasicAuthWebServices : False

AllowBasicAuthRpc : False

Office 365 不再支持远程过程调用 (RPC) 协议,因此最后一个参数不影响客户端。

下面是用于创建此身份验证策略的命令示例:

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false

注意

默认情况下,创建策略后,还会禁用所有其他协议(如 IMAP、POP 和 ActiveSync) 的旧式身份验证。 若要更改此行为,可以使用如下所示的 PowerShell 命令启用协议:

Set-AuthenticationPolicy -Identity BlockOutlook -AllowBasicAuthImap:$true

创建身份验证策略后,首先可以使用 Set-User user01 -AuthenticationPolicy <name_of_policy> 命令将其分配给试点用户组。 测试后,可以扩展策略以包括所有用户。 若要在组织级别应用策略,请使用 Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> 命令。 需要为此配置使用 Exchange Online PowerShell。

体系结构(Exchange Online、AD FS)

Diagram that shows an alternative architecture for enhanced security in an Outlook client access scenario.

下载包含本文中所有示意图的 Visio 文件

这个场景与上个场景相同,只不过它使用不同的触发器进行多重身份验证。 在上一方案中,我们使用本地 AD FS 进行身份验证。 然后,我们将有关成功身份验证的信息重定向到 Microsoft Entra ID,其中条件访问策略强制实施多重身份验证。 在此场景中,我们不会使用条件访问强制实施多重身份验证,而是在 AD FS 级别创建访问控制策略,并在其中强制实施多重身份验证。 体系结构的其余部分与前面的情况相同。

注意

仅当无法使用上一方案时,才建议使用此方案。

在此方案中,用户需要使用支持新式身份验证的 Outlook 客户端版本。 有关详细信息,请参阅如何对 Office 2013、Office 2016 和 Office 2019 客户端应用使用新式身份验证。 该体系结构涵盖 Outlook for Windows 和 Outlook for Mac。

工作流(Exchange Online、AD FS)

  1. 用户尝试通过 Outlook 访问 Exchange Online。

  2. Exchange Online 提供 Microsoft Entra 终结点的 URL,用于检索访问令牌以获取对邮箱的访问权限。

  3. Outlook 使用该 URL 连接到 Microsoft Entra ID。

  4. 如果域已联合,Microsoft Entra ID 会将请求重定向到本地 AD FS。

  5. 用户在 AD FS 登录页上输入凭据。

  6. 响应 AF DS 访问控制策略,AD FS 调用 Microsoft Entra 多重身份验证来完成身份验证。 下面是此种 AD FS 访问控制策略的示例:

    Screenshot that shows an example of an AD FS access control policy.

    用户获取完成多重身份验证的请求。

  7. 用户完成多重身份验证。

  8. AD FS 会将会话重定向回 Microsoft Entra ID。

  9. Microsoft Entra ID 发出访问和刷新令牌,并将其返回到客户端。

  10. 通过使用访问令牌,客户端连接到 Exchange Online 并检索内容。

配置(Exchange Online、AD FS)

注意

在步骤 6 中实现的访问控制策略应用于信赖方信任级别,因此会影响通过 AD FS 使用的所有 Office 365 服务的所有身份验证请求。 可以使用 AD FS 身份验证规则应用其他筛选。 但是,我们建议使用(上述体系结构中所述的)条件访问策略,而不是对 Microsoft 365 服务使用 AD FS 访问控制策略。 上一方案更常见,通过使用该方案,可以实现更好的灵活性。

若要阻止尝试通过旧式身份验证访问 Exchange Online (关系图中的红色虚线),需要创建一个身份验证策略,以禁用 Outlook 服务使用的协议的旧式身份验证。 以下是需要禁用的特定协议:自动发现、MAPI、脱机通讯簿和 EWS。 下面是相应的配置:

AllowBasicAuthAutodiscover : False

AllowBasicAuthMapi : False

AllowBasicAuthOfflineAddressBook : False

AllowBasicAuthWebServices : False

AllowBasicAuthRpc : False

Office 365 不再支持 RPC 协议,因此最后一个参数不影响客户端。

下面是用于创建此身份验证策略的命令示例:

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false

体系结构(本地 Exchange)

Diagram that shows an enhanced security architecture in an on-premises Outlook client access scenario.

下载包含本文中所有示意图的 Visio 文件

该体系结构涵盖 Outlook for Windows 和 Outlook for Mac。

工作流(本地 Exchange)

  1. Exchange Server 上具有邮箱的用户将启动 Outlook 客户端。 Outlook 客户端连接到 Exchange Server,并指定其具有新式身份验证功能。
  2. Exchange Server 向请求从 Microsoft Entra ID 获取令牌的客户端发送响应。
  3. Outlook 客户端连接到 Exchange Server 提供的 Microsoft Entra URL。
  4. Azure 标识用户的域是联合的,因此它将请求发送到 AD FS (通过 Web 应用程序代理)。
  5. 用户在 AD FS 登录页上输入凭据。
  6. AD FS 会将会话重定向回 Microsoft Entra ID。
  7. Microsoft Entra ID 对移动应用和桌面客户端应用具有多重身份验证要求的 Azure 条件访问策略。 有关设置该策略的信息,请参阅本文的部署部分
  8. 条件访问策略调用 Microsoft Entra 多重身份验证。 用户获取完成多重身份验证的请求。
  9. 用户完成多重身份验证。
  10. Microsoft Entra ID 发出访问和刷新令牌,并将其返回到客户端。
  11. 用户向 Exchange Server 提供访问令牌,Exchange 则授权访问邮箱。

配置(本地 Exchange)

若要阻止尝试通过旧式身份验证访问本地 Exchange (关系图中的红色虚线),需要创建一个身份验证策略,以禁用 Outlook 服务使用的协议的旧式身份验证。 以下是需要禁用的特定协议:自动发现、MAPI、脱机通讯簿、EWS 和 RPC。 下面是相应的配置:

BlockLegacyAuthAutodiscover : True

BlockLegacyAuthMapi : True

BlockLegacyAuthOfflineAddressBook : True

BlockLegacyAuthRpc : True

BlockLegacyAuthWebServices : True

RPC 协议不支持新式身份验证,因此不支持 Microsoft Entra 多重身份验证。 Microsoft 建议将 MAPI 协议用于 Windows 客户端的 Outlook。

下面是用于创建此身份验证策略的命令示例:

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc

创建身份验证策略后,首先可以使用 Set-User user01 -AuthenticationPolicy <name_of_policy> 命令将其分配给试点用户组。 测试后,可以扩展策略以包括所有用户。 若要在组织级别应用策略,请使用 Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> 命令。 需要为此配置使用 Exchange 本地 PowerShell。

体系结构(本地 Exchange、AD FS)

Diagram that shows an alternative enhanced security architecture in an on-premises Outlook client access scenario.

下载包含本文中所有示意图的 Visio 文件

此方案类似于前面所述的方案。 但是,在此场景中,多重身份验证由 AD FS 触发。 该体系结构涵盖 Outlook for Windows 和 Outlook for Mac。

注意

仅当无法使用上一方案时,才建议使用此方案。

工作流(本地 Exchange、AD FS)

  1. 用户启动 Outlook 客户端。 客户端连接到 Exchange Server,并指定其具有新式身份验证功能。

  2. Exchange Server 向请求从 Microsoft Entra ID 获取令牌的客户端发送响应。 Exchange Server 向客户端提供访问 Microsoft Entra ID 的 URL。

  3. 客户端使用 URL 访问 Microsoft Entra ID。

  4. 在此方案中,域是联合的。 Microsoft Entra ID 通过 Web 应用程序代理将客户端重定向到 AD FS。

  5. 用户在 AD FS 登录页上输入凭据。

  6. AD FS 触发多重身份验证。 下面是此种 AD FS 访问控制策略的示例:

    Screenshot that shows an AD FS access control policy.

    用户获取完成多重身份验证的请求。

  7. 用户完成多重身份验证。

  8. AD FS 会将会话重定向回 Microsoft Entra ID。

  9. Microsoft Entra ID 向用户颁发访问和刷新令牌。

  10. 客户端向 Exchange 本地服务器提供访问令牌。 Exchange 授权访问用户的邮箱。

配置(本地 Exchange、AD FS)

注意

在步骤 6 中实现的访问控制策略应用于信赖方信任级别,因此会影响通过 AD FS 的所有Office 365 服务的所有身份验证请求。 可以使用 AD FS 身份验证规则应用其他筛选。 但是,我们建议使用(上述体系结构中所述的)条件访问策略,而不是对 Microsoft 365 服务使用 AD FS 访问控制策略。 上一方案更常见,通过使用该方案,可以实现更好的灵活性。

若要阻止尝试通过旧式身份验证访问本地 Exchange (关系图中的红色虚线),需要创建一个身份验证策略,以禁用 Outlook 服务使用的协议的旧式身份验证。 以下是需要禁用的特定协议:自动发现、MAPI、脱机通讯簿、EWS 和 RPC。 下面是相应的配置:

BlockLegacyAuthAutodiscover : True

BlockLegacyAuthMapi : True

BlockLegacyAuthOfflineAddressBook : True

BlockLegacyAuthRpc : True

BlockLegacyAuthWebServices : True

RPC 协议不支持新式身份验证,因此不支持 Microsoft Entra 多重身份验证。 Microsoft 建议将 MAPI 协议用于 Windows 客户端的 Outlook。

下面是用于创建此身份验证策略的命令示例:

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc

创建身份验证策略后,首先可以使用 Set-User user01 -AuthenticationPolicy <name_of_policy> 命令将其分配给试点用户组。 测试后,可以扩展策略以包括所有用户。 若要在组织级别应用策略,请使用 Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> 命令。 需要为此配置使用 Exchange 本地 PowerShell。

组件

  • Microsoft Entra ID。 Microsoft Entra ID 是 Microsoft 基于云的标识和访问管理服务。 它提供基于 EvoSTS(Microsoft Entra ID 使用的安全令牌服务)的新式身份验证。 它用作本地 Exchange Server 的身份验证服务器。
  • Microsoft Entra 多重身份验证。 多重身份验证是系统在用户登录时提醒其输入另一种身份验证的过程,比如在手机上输入代码或提供指纹扫描。
  • Microsoft Entra 条件访问。 条件访问是 Microsoft Entra ID 用来强制实施组织策略(如多重身份验证)的功能。
  • AD FS。 AD FS 通过跨安全与企业边界共享数字标识和权利权限,实现联合标识和访问管理,从而提高安全性。 在这些体系结构中,它用于帮助具有联合标识的用户登录。
  • Web 应用程序代理。 Web 应用程序代理使用 AD FS 对 web 应用程序进行预身份验证。 它还充当 AD FS 代理。
  • Microsoft Intune。 Intune 是基于云的统一终结点管理工具,可跨 Windows、Android、Mac、iOS 和 Linux 操作系统管理终结点。
  • Exchange Server。 Exchange Server 在本地托管用户邮箱。 在这些体系结构中,它使用 Microsoft Entra ID 向用户颁发的令牌来授权访问邮箱。
  • Active Directory 服务。 Active Directory 服务存储有关域成员的信息,包括设备和用户。 在这些体系结构中,用户帐户属于 Active Directory 服务,并同步到 Microsoft Entra ID。
  • 适用于企业的 Outlook。 Outlook 是支持新式身份验证的客户端应用程序。

方案详细信息

Enterprise 消息传递基础结构 (EMI) 是组织的关键服务。 从较旧、不安全的身份验证方法和授权方法转移到新式身份验证是远程工作普遍面临的一个关键挑战。 实现消息传递服务访问的多重身份验证要求是满足这一挑战的最有效方法之一。

本文介绍使用 Microsoft Entra 多重身份验证增强 Outlook 桌面客户端访问场景中的安全性的四种体系结构。

与 Microsoft Exchange 存在的四种不同可能性相对应的四种体系结构:

这四种体系结构都涵盖 Outlook for Windows 和 Outlook for Mac。

有关在其他混合消息传递场景中应用多重身份验证的信息,请参阅以下文章:

本文不讨论其他协议,如 IMAP 或 POP。 通常,这些方案不使用这些协议。

一般说明

  • 这些体系结构使用联合 Microsoft Entra 标识模型。 对于密码哈希同步和直通身份验证模型,逻辑和流是相同的。 唯一的区别在于,Microsoft Entra ID 不会将身份验证请求重定向到本地 Active Directory 联合身份验证服务 (AD FS)。
  • 通过本地 Exchange,我们是指 Exchange 2019 具有最新更新和邮箱角色。
  • 在实际环境中,不会只有一台服务器。 将有一个负载均衡的 Exchange 服务器数组,以实现高可用性。 此处介绍的方案适用于该配置。

可能的用例

此体系结构适用于以下方案:

  • 增强 EMI 安全性。
  • 采用零信任安全策略。
  • 在过渡到 Exchange Online 或与 Exchange Online 共存期间,对本地消息服务应用标准的高级保护。
  • 在封闭或高度安全的组织(如金融部门)中强制实施严格的安全或合规性要求。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则,即一套可用于改善工作负载质量的指导原则。 有关详细信息,请参阅 Microsoft Azure 架构良好的框架

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息,请参阅可靠性支柱概述

可用性

总体可用性取决于所涉及的组件的可用性。 有关可用性的详细信息,请参阅这些资源:

本地解决方案组件的可用性取决于实现的设计、硬件可用性以及内部操作和维护例程。 有关其中一些组件的可用性信息,请参阅以下资源:

若要使用混合新式身份验证,需要确保网络上的所有客户端都可以访问 Microsoft Entra ID。 还需要持续维护 Office 365 防火墙端口和 IP 范围开放端口。

有关 Exchange Server 的协议和端口要求,请参阅混合新式身份验证概述中的“Exchange 客户端和协议要求”,以用于本地 Skype for Business 和Exchange 服务器

有关 Office 365 IP 范围和端口,请参阅 Office 365 URL 和 IP 地址范围

有关混合新式身份验证和移动设备的信息,请阅读 Office 365 IP 地址和 URL Web 服务中不包含的其他终结点中的自动检测终结点。

复原

有关此体系结构中组件的复原能力的信息,请参阅以下资源。

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息,请参阅安全性支柱概述

有关安全性和混合新式身份验证的信息,请参阅深入探讨:混合身份验证的工作原理

对于具有传统强外围保护的封闭组织,存在与 Exchange 混合经典配置相关的安全问题。 Exchange 混合新式配置不支持混合新式身份验证。

有关 Microsoft Entra ID 的信息,请参阅 Microsoft Entra 安全操作指南

有关使用 AD FS 安全性的方案的信息,请参阅以下文章:

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息,请参阅成本优化支柱概述

实现的成本取决于 Microsoft Entra ID 和 Microsoft 365 许可证成本。 总成本还包括本地组件的软硬件、IT 运营、培训和教育以及项目实施等成本。

这些解决方案至少需要 Microsoft Entra ID P1。 有关定价详细信息,请参阅 Microsoft Entra 定价

有关 AD FS 和 Web 应用程序代理的信息,请参阅 Windows Server 2022 的定价和许可

有关更多定价信息,请参阅这些资源:

性能效率

性能效率是指工作负载能够以高效的方式进行缩放以满足你的用户对它的需求。 有关详细信息,请参阅性能效率要素概述

工作负载性能取决于所涉及组件的性能以及网络性能。 有关详细信息,请参阅使用基线和性能历史进行 Office 365 性能优化

有关影响 AD FS 服务方案性能的本地因素的信息,请参阅以下资源:

有关 AD FS 可伸缩性的信息,请参阅规划 AD FS 服务器容量

有关 Exchange Server 本地可伸缩性的信息,请参阅 Exchange 2019 首选体系结构

部署此方案

下面是概要步骤:

  1. 通过配置 Exchange 混合配置和启用混合新式身份验证来保护 Outlook 桌面访问。
  2. 阻止 Microsoft Entra ID 级别的所有旧式身份验证尝试。 使用身份验证策略阻止消息传送服务级别的旧式身份验证尝试。

设置条件访问策略

若要设置强制实施多重身份验证的 Microsoft Entra 条件访问策略,请参阅本文的一些体系结构:

  1. 在“客户端应用”窗口中,选择“移动应用”和“桌面客户端”:

    Screenshot that shows the Client apps window.

  2. 在“授予”窗口中应用多重身份验证要求:

    Screenshot that shows the Grant window.

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

主要作者:

若要查看非公开领英个人资料,请登录领英。

后续步骤