使用 Microsoft Entra 条件访问阻止旧式身份验证
为使用户轻松访问云应用程序，Microsoft Entra ID 支持各种身份验证协议（包括旧式身份验证）。 但是，旧式身份验证不支持多重身份验证 (MFA) 等。 MFA 是改善组织安全状况的一项常见要求。
根据 Microsoft 的分析结果显示，超过 97% 的凭据填充攻击使用旧式身份验证，超过 99% 的密码喷洒攻击使用旧式身份验证协议。 禁用或阻止基本身份验证即可阻止上述攻击。
注意
自 2022 年 10 月 1 日起，我们将开始在所有 Microsoft 365 租户中永久禁用 Exchange Online 的基本身份验证，而不考虑使用情况，SMTP 身份验证除外。 有关详细信息，请参阅在 Exchange Online 中弃用基本身份验证一文
Microsoft 身份安全总监 Alex Weinert 在其 2020 年 3 月 12 日的博客文章阻止组织中旧式身份验证的新工具中，强调了组织应阻止旧式身份验证的原因，以及 Microsoft 提供了哪些其他工具来完成此任务：
本文介绍如何配置条件访问策略来阻止对租户内所有工作负荷的旧式身份验证。
在推出旧式身份验证阻止保护时，我们建议采用分阶段的方法，而不是一次为所有用户禁用它。 客户可以通过应用 Exchange Online 身份验证策略开始按协议禁用基本身份验证，然后（可选）在准备就绪时通过条件访问策略阻止旧式身份验证。
没有包含条件访问的许可证的客户可以使用安全默认值来阻止旧式身份验证。
先决条件
本文假设你熟悉 Microsoft Entra 条件访问的基本概念。
注意
完成第一因素身份验证后将强制执行条件访问策略。 在遇到拒绝服务 (DoS) 攻击等情景中，条件访问不应充当组织的第一道防线，但它可以使用这些事件的信号来确定访问权限。
方案描述
Microsoft Entra ID 支持使用最广泛的身份验证和授权协议（包括旧式身份验证）。 旧式身份验证无法直接提示用户满足条件访问策略所需的第二因素身份验证或其他身份验证要求。 此身份验证模式包括基本身份验证，是一种收集用户名和密码信息时广泛使用的行业标准方法。 通常或仅使用旧式身份验证的应用程序示例包括：
- Microsoft Office 2013 或更早版本。
- 使用邮件协议的应用，如 POP、IMAP 和 SMTP AUTH。
有关 Office 中新式身份验证支持的详细信息，请参阅如何对 Office 客户端应用使用新式身份验证。
如今，使用单因素身份验证（例如，用户名和密码）还不够安全。 使用密码也不安全，因为它们很容易被猜测到，我们（人类）并不擅长选择好密码。 密码也容易遭受各种攻击，如网络钓鱼和密码破解。 要防止密码威胁，可以做的最简单的事情之一就是实现多重身份验证 (MFA)。 使用 MFA，即使攻击者拥有用户密码，仅凭密码也不足以成功验证和访问数据。
如何阻止使用旧身份验证的应用访问租户的资源？ 建议只使用条件访问策略阻止它们。 如有必要，只允许某些用户和特定网络位置使用基于旧身份验证的应用程序。
实现
本节介绍如何配置条件访问策略以阻止旧式身份验证。
支持旧式身份验证的消息协议
以下消息协议支持旧式身份验证：
- 经过身份验证的 SMTP - 用于发送经过身份验证的电子邮件。
- 自动发现 - 由 Outlook 和 EAS 客户端用来查找和连接 Exchange Online 中的邮箱。
- Exchange ActiveSync (EAS) - 用于连接到 Exchange Online 中的邮箱。
- Exchange Online PowerShell - 用于通过远程 PowerShell 连接到 Exchange Online。 如果阻止 Exchange Online PowerShell 的基本身份验证，则需使用 Exchange Online PowerShell 模块进行连接。 有关说明，请参阅使用多重身份验证连接到 Exchange Online PowerShell。
- Exchange Web 服务 (EWS) - Outlook、Outlook for Mac 和非 Microsoft Apps 使用的编程接口。
- IMAP4 - 由 IMAP 电子邮件客户端使用。
- MAPI over HTTP (MAPI/HTTP) - Outlook 2010 SP2 及更高版本使用的主邮箱访问协议。
- 脱机通讯簿 (OAB) - 通过 Outlook 下载并使用的地址列表集合的副本。
- Outlook Anywhere (RPC over HTTP) - 所有当前 Outlook 版本支持的旧邮箱访问协议。
- POP3 - 由 POP 电子邮件客户端使用。
- Reporting Web Services - 用于在 Exchange Online 中检索报表数据。
- 通用 Outlook - 由适用于 Windows 10 的邮件和日历应用使用。
- 其他客户端 - 标识为使用旧式身份验证的其他协议。
若要详细了解这些身份验证协议和服务，请参阅登录日志活动详细信息。
识别是否以及如何使用了旧式身份验证
在目录中阻止旧式身份验证之前，需要先了解用户是否有使用旧式身份验证的客户端应用。
登录日志指示器
- 至少以报告读取者身份登录到 Microsoft Entra 管理中心。
- 浏览到“标识”>“监视和运行状况”>“登录日志”。
- 如果未显示“客户端应用”列，请单击“列”>“客户端应用”以添加该列。
- 选择“添加筛选器”>“客户端应用”>，选择所有旧式身份验证协议，并选择“应用”。
- 此外，可以在用户登录（非交互式）选项卡上执行这些步骤。
筛选显示通过旧式身份验证协议进行的登录尝试。 单击每个登录尝试会显示更多详细信息。 “基本信息”选项卡下的“客户端应用”字段将指示使用了哪个旧式身份验证协议。
这些日志指示用户在使用仍依赖于旧式身份验证的客户端。 对于未出现在这些日志中且已被确认不使用旧式身份验证的用户，请仅为这些用户实施条件访问策略。
此外，为了帮助在租户中会审旧式身份验证，请使用利用旧身份验证工作簿的登录。
客户端中的指示
若要根据登录时显示的对话框确定客户端使用的是旧式身份验证还是新式身份验证，请参阅文章弃用 Exchange Online 中的基本身份验证。
重要注意事项
同时支持旧式和新式验证的客户端可能需要配置更新才能从旧式验证转换为新式验证。 如果你在登录日志中看到客户端的“新式移动”、“桌面客户端”或“浏览器”，则它正在使用新式身份验证。 如果它具有特定的客户端或协议名称，例如“Exchange ActiveSync”，则它使用旧式身份验证。 条件访问、登录日志和旧式身份验证工作簿中的客户端类型可区分新式和旧式身份验证客户端。
- 应更新或重新配置支持新式身份验证但未配置为使用新式身份验证的客户端，以使用新式身份验证。
- 应替换所有不支持新式身份验证的客户端。
重要
具有基于证书的身份验证 (CBA) 的 Exchange Active Sync
实现具有 CBA 的 Exchange Active Sync (EAS) 时，将客户端配置为使用新式身份验证。 当在 Exchange Online 中弃用基本身份验证时，系统不会阻止未对具有 CBA 的 EAS 使用新式身份验证的客户端。 但是，这些客户端被配置为阻止旧式身份验证的条件访问策略阻止。
有关通过 Microsoft Entra ID 和新式身份验证实现对 CBA 的支持的详细信息，请参阅：如何配置 Microsoft Entra 基于证书的身份验证（预览版）。 也可以选择将在联合服务器上执行的 CBA 与新式身份验证一起使用。
如果使用的是 Microsoft Intune，可以使用推送或部署到设备的电子邮件配置文件来更改身份验证类型。 如果使用的是 iOS 设备（iPhone 和 iPad），则应查看在 Microsoft Intune 中添加适用于 iOS 和 iPadOS 设备的电子邮件设置。
阻止传统身份验证
使用条件访问策略来阻止旧式身份验证的方式有两种。
直接阻止旧式身份验证
在整个组织中阻止旧式身份验证的最简单方法是配置条件访问策略，该策略专门应用于旧式身份验证客户端并阻止访问。 在将用户和应用程序分配到该策略时，请确保排除仍需使用旧式身份验证进行登录的用户和服务帐户。 选择应用此策略的云应用时，请选择 “所有资源”、“Office 365（建议）或至少 Office 365 Exchange Online 等目标应用”。 组织可以使用条件访问模板中提供的策略，或将通用策略条件访问：阻止旧式身份验证作为参考。
间接阻止旧式身份验证
如果组织尚未准备好完全阻止旧式身份验证，则应确保使用旧式身份验证的登录不会绕过需要授权控制的策略，例如多重身份验证。 在身份验证过程中，旧式身份验证客户端不支持将 MFA、设备合规性或加入状态信息发送到 Microsoft Entra ID。 因此，请将具有授权控制的策略应用于所有客户端应用程序，以便阻止无法满足授权控制要求的基于旧式身份验证的登录。 随着客户端应用条件在 2020 年 8 月正式发布，新创建的条件访问策略会默认应用于所有客户端应用。
要点
条件访问策略生效可能需要长达 24 小时的时间。
阻止使用其他客户端的访问也会阻止使用基本身份验证的 Exchange Online PowerShell 和 Dynamics 365。
为“其他客户端”配置策略导致整个组织无法与 SPConnect 之类的特定客户端通信。 之所以发生这种阻止，是因为旧式客户端使用非预期的方式进行身份验证。 此问题不存在于主要的 Office 应用程序（例如旧式 Office 客户端）中。
可为其他客户端条件选择所有可用的授权控件；但是，最终用户体验始终是相同的 - 阻止访问。