为 Azure 和其他管理门户规划强制多重身份验证

在 Microsoft，我们致力于为客户提供最高级别的安全性。 他们可以使用的最有效的安全措施之一是多重身份验证 (MFA)。 Microsoft 的研究表明，MFA 可以阻止超过 99.2% 的帐户入侵攻击。

因此，从 2024 年开始，我们将对所有 Azure 登录尝试强制执行 MFA。 有关此要求的详细信息，请参阅我们的 博客文章。 本主题介绍哪些应用程序和帐户会受到影响、如何向租户推出强制实施，以及其他常见问题和答案。

如果你所在组织已经为用户强制实施 MFA，或者用户已使用无密码或密码密钥 (FIDO2) 等更强的方法登录，则用户不会发生任何更改。 若要验证已为所有用户启用了 MFA，请参阅 如何验证用户的强制 MFA 设置。

强制实施范围

强制范围包括何时计划实施、哪些应用程序计划强制实施 MFA、未确定范围的应用程序以及哪些帐户具有强制 MFA 要求。

强制实施阶段

应用程序的 MFA 强制实施分为两个阶段。

阶段 1 应用程序

从 2024 年 10 月开始，登录到 Azure 门户、Microsoft Entra 管理中心和 Microsoft Intune 管理中心的帐户需要 MFA 才能执行任何创建、读取、更新或删除（CRUD）作。 强制实施将逐步向全球所有租户推出。 从 2025 年 2 月起，将逐步开始对登录 Microsoft 365 管理中心的过程实施 MFA 强制措施。 阶段 1 不会影响其他 Azure 客户端，例如 Azure CLI、Azure PowerShell、Azure 移动应用或 IaC 工具。

阶段 2 应用程序

从 2025 年 9 月 15 日开始，MFA 强制实施将逐渐开始用于登录到 Azure CLI、Azure PowerShell、Azure 移动应用、IaC 工具和 REST API 终结点的帐户，以进行任何创建、更新或删除操作。 读取操作不需要多因素认证。

某些客户可以使用 Microsoft Entra ID 中的用户帐户作为服务帐户。 建议迁移这些基于用户的服务帐户，以保护具有工作负荷标识的基于云的服务帐户。

应用程序 ID 和 URL

下表列出了 Azure 受影响的应用、应用 ID 和 URL。

下表列出了 Microsoft 365 受影响的应用和 URL。

Accounts

当强制执行开始后，所有登录以执行“应用”部分中所列操作的帐户，都必须完成 MFA。 如果用户访问 Azure 上托管的其他应用程序、网站或服务，则无需使用 MFA。 前面列出的每个应用程序、网站或服务所有者都会控制对用户的身份验证要求。

开始强制实施后，要使用 MFA 进行登录，还需要“破窗”或紧急访问帐户。 建议更新这些帐户以使用 通行密钥（FIDO2） 或为 MFA 配置 基于证书的身份验证 。 这两种方法都满足 MFA 要求。

工作负荷标识（如托管标识和服务主体）不受此 MFA 强制实施 任一阶段 的影响。 如果用户标识以服务帐户身份登录以运行自动化（包括脚本或其他自动化任务），则这些用户标识需要在强制实施开始后使用 MFA 登录。 不建议将用户标识用于自动化。 应将这些用户标识迁移到 工作负荷标识。

客户端库

OAuth 2.0 资源所有者密码凭据 (ROPC) 令牌授予流与 MFA 不兼容。 在 Microsoft Entra 租户中启用 MFA 后，应用程序中使用的基于 ROPC 的 API 将引发异常。 有关如何从基于 ROPC 的 API 迁移到 Microsoft 身份验证库 （MSAL）的详细信息，请参阅 如何从 ROPC 迁移。 有关特定于语言的 MSAL 指南，请参阅以下选项卡。

相同的常规 MSAL 指南适用于 Azure 标识库。 UsernamePasswordCredential这些库中提供的类使用基于 MSAL ROPC 的 API。 有关特定于语言的指南，请参阅以下选项卡。

将基于用户的服务帐户迁移到工作负载标识

我们建议客户发现用作服务帐户的用户帐户，并开始将其迁移到工作负荷标识。 迁移通常需要更新脚本和自动化过程才能使用工作负载标识。

查看 如何验证是否已为强制 MFA 设置用户 ，以标识登录到 应用程序的所有用户帐户，包括用作服务帐户的用户帐户。

有关如何从基于用户的服务帐户迁移到工作负载标识以向这些应用程序进行身份验证的详细信息，请参阅：

• 使用 Azure CLI 通过托管标识登录到 Azure
• 使用 Azure CLI 通过服务主体登录到 Azure
• 通过非交互方式登录到 Azure PowerShell 以实现自动化方案，其中包括适用于托管标识和服务主体用例的指导

一些客户将条件访问策略应用于基于用户的服务帐户。 可以回收基于用户的许可证，并添加工作负载标识许可证，以便应用工作负载标识的条件访问。

将联合标识提供者迁移到外部身份验证方法

对外部 MFA 解决方案的支持目前处于预览阶段，利用外部身份验证方法，可以用来符合 MFA 要求。 旧版条件访问自定义控件预览版不符合 MFA 要求。 应迁移到外部身份验证方法预览版，以使用具有 Microsoft Entra ID 的外部解决方案。

如果使用的是 Active Directory 联合身份验证服务等联合标识提供者 (IdP)，并且 MFA 提供程序直接与此联合 IdP 集成，则必须将联合 IdP 配置为发送 MFA 声明。 有关详细信息，请参阅 Microsoft Entra MFA 的预期入站断言。

准备强制实施 MFA

若要准备实施 MFA，请配置要求用户使用 MFA 登录 的条件访问策略 。 如果在策略中配置了异常或排除项，它们将不再适用。 如果具有更严格的条件访问策略，这些策略以 Azure 为目标，并且需要更强的身份验证，例如网络钓鱼防护 MFA，则仍强制实施这些策略。

条件访问需要Microsoft Entra ID P1 或 P2 许可证。 如果无法使用条件访问，请启用 安全默认值。

可以使用 Azure Policy 中的内置定义自行强制实施 MFA。 若要了解详细信息并按照分步概述在环境中应用这些策略分配，请参阅 教程：通过 Azure Policy 应用 MFA 自强制实施。

请求更多时间来准备阶段 1 MFA 强制实施

我们知道，某些客户可能需要更多时间为此 MFA 要求做准备。 Microsoft允许具有复杂环境或技术障碍的客户将第 1 阶段的强制实施推迟到 2025 年 9 月 30 日。

对于要推迟强制实施开始日期的每个租户，全局管理员可以转到 https://aka.ms/managemfaforazure 选择开始日期。

如果以前从未使用 MFA 登录到 Azure 门户，系统会提示完成 MFA 登录或推迟执行 MFA。 此屏幕仅显示一次。 关于如何设置 MFA 的更多信息，请参阅 如何验证用户是否已为强制 MFA 设置。

如果选择 “推迟 MFA”，则 MFA 执行日期将在未来一个月或 2025 年 9 月 30 日（以较早者为准）。 登录后，可以在 https://aka.ms/managemfaforazure 更改日期。 若要确认要继续执行推迟请求，请单击“ 确认推迟”。 全局管理员必须 提升访问权限 ，以推迟 MFA 强制执行的开始日期。

请求更多时间来准备执行第 2 阶段的 MFA 强制实施

Microsoft允许具有复杂环境或技术障碍的客户将第 2 阶段的强制实施推迟到 2026 年 7 月 1 日。 可以在 https://aka.ms/postponePhase2MFA 请求更多时间来准备阶段 2 MFA 强制实施。 选择其他开始日期，然后单击“ 应用”。

确认强制实施 MFA

强制执行后， Azure 门户中会显示一个横幅：

Microsoft Entra ID 登录日志 显示强制实施 MFA 的应用程序作为 MFA 要求的源。

FAQs

问题：如果租户仅用于测试，是否需要 MFA？

答：是的，每个 Azure 租户都需要 MFA，测试环境没有任何例外。

问：此要求对 Microsoft 365 管理中心有何影响？

答：强制 MFA 将于 2025 年 2 月推广到 Microsoft 365 管理中心。 在博客文章中详细了解Microsoft 365 管理中心的强制 MFA 要求， 宣布对 Microsoft 365 管理中心进行强制多重身份验证。

问：MFA 是否对所有用户或仅管理员是强制性的？

答：登录到前面列出的任何 应用程序 的所有用户都需要完成 MFA，而不管激活或符合其条件的任何管理员角色，或者为其启用的任何 用户排除 。

问：如果我选择“ 保持登录状态”选项，是否需要完成 MFA？

答：是的，即使你选择 “保持登录”，也需要先完成 MFA，然后才能登录到这些 应用程序。

问：强制实施是否适用于 B2B 来宾帐户？

答：是的，如果已正确设置 MFA 以使用跨租户访问将 MFA 声明发送到资源租户，则必须遵循合作伙伴资源租户或用户的主租户。

问：强制实施是否适用于美国政府或 Azure 主权云？

答：Microsoft仅在公有 Azure 云中强制实施强制 MFA。 Microsoft目前不会针对美国政府或其他 Azure 主权云在 Azure 中强制实施 MFA。

问：如果我们使用另一个标识提供者或 MFA 解决方案强制执行 MFA，并且我们不会使用 Microsoft Entra MFA 来强制实施 MFA，我们应如何遵守？

答：第三方 MFA 可以直接与 Microsoft Entra ID 集成。 有关详细信息，请参阅 Microsoft Entra 多重身份验证外部方法提供程序参考。 Microsoft Entra ID 可以选择性地配置为使用联合身份提供程序。 如果是这样，则需要正确配置标识提供者解决方案，以便将多身份验证声明发送到 Microsoft Entra ID。 有关详细信息，请参阅使用来自联合 IdP 的 MFA 声明实现 Microsoft Entra ID 多重身份验证 (MFA) 控制。

问：强制 MFA 是否会影响我与 Microsoft Entra Connect 或 Microsoft Entra Cloud Sync 同步的能力？

答：否。 同步服务帐户不受强制 MFA 要求的影响。 只有前面列出的 应用程序 需要 MFA 才能登录。

问：我能否选择退出？

答：没有办法选择退出。此安全运动对于 Azure 平台的安全和安全至关重要，并且跨云供应商重复。 例如，请参阅 “通过设计保障安全：AWS 将在 2024 年增强 MFA 要求”。

客户可以选择推迟强制实施开始日期。 全局管理员可以转到 Azure 门户 ，推迟其租户的强制实施日期。 全局管理员必须 具有提升的访问权限 ，然后才能推迟此页上的 MFA 强制实施开始日期。 他们必须针对需要推迟的每个租户执行此操作。

问：在 Azure 强制实施策略以确保没有任何中断之前，是否可以测试 MFA？

答：是的，可以通过 MFA 的手动配置过程来 测试您的 MFA。 我们鼓励您进行设置并测试。 如果使用条件访问来强制实施 MFA，则可以使用条件访问模板来测试策略。 有关详细信息，请参阅 “要求对访问Microsoft管理门户的管理员进行多重身份验证”。 如果运行免费版的 Microsoft Entra ID，则可以启用 安全默认值。

问：如果我已启用 MFA，接下来会发生什么情况？

答：如果客户已要求访问前面列出的应用程序的用户使用多因素认证，则不会看到任何变化。 如果只对一部分用户要求 MFA，则任何尚未使用 MFA 的用户现在都需要在登录到应用程序时使用 MFA。

问：如何在 Microsoft Entra ID 中查看 MFA 活动？

答：要查看有关系统合适提示用户通过 MFA 登录的详细信息，请使用 Microsoft Entra 登录日志。 有关详细信息，请参阅 Microsoft Entra 多重身份验证的登录事件详细信息。

问题：如果我遇到“破窗”情况，会怎么样？

答：建议更新这些帐户以使用 密码（FIDO2） 或为 MFA 配置 基于证书的身份验证 。 这两种方法都满足 MFA 要求。

问：如果我在强制实施 MFA 之前未收到有关启用 MFA 的电子邮件，然后我被锁定，该怎么办。应如何解决此问题？

答：用户不应被锁定，但可能会收到一条消息，提示他们在对其租户强制实施后启用 MFA。 如果用户被锁定，则可能存在其他问题。 有关详细信息，请参阅 帐户已被锁定。

相关内容

查看以下主题，详细了解如何配置和部署 MFA：

• 如何推迟用户无法签名的租户强制实施
• 如何验证是否已为用户设置强制性 MFA
• 教程：使用 Microsoft Entra 多重身份验证保护用户登录事件
• 使用 Microsoft Entra 多重身份验证保护登录事件
• 规划Microsoft Entra 多重身份验证部署
• 防网络钓鱼 MFA 方法
• Microsoft Entra 多重身份验证
• 身份验证方法