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

在自动化方案中多重身份验证对 Azure CLI 的影响

2025-05-21

本文探讨多重身份验证（MFA）如何影响使用 Microsoft Entra 用户标识的自动化任务，并提供有关不间断自动化替代方法的指导。

重要

如果您使用 Microsoft Entra 用户身份进行自动化，则需要采取行动。 MFA 要求可防止在自动化方案中使用 Microsoft Entra 用户标识进行身份验证。组织必须切换到专为自动化设计的身份验证方法，例如托管标识或服务主体，这些主体支持非交互式自动化用例。

自动化中使用 MFA 的用户身份限制

注释

可能会遇到错误消息：在自动化中使用用户标识时，需要交互式身份验证。

交互式身份验证：使用 Microsoft Entra 用户标识时，在交互式登录期间触发 MFA。对于依赖于用户标识的自动化脚本，MFA 会中断该过程，因为它需要额外的验证步骤。例如，无法自动完成的验证器应用、电话呼叫等。除非以非交互方式（例如使用托管标识或服务主体）处理身份验证，否则此验证可防止自动化运行。
脚本化登录失败：在自动化方案中（例如无人参与运行 Azure CLI 脚本）中，启用了 MFA 的用户标识会导致脚本在尝试进行身份验证时失败。由于 MFA 需要用户交互，因此它与非交互式脚本不兼容。这意味着您必须切换到托管标识或服务主体，这两者都使用非交互式的身份验证方式。
安全注意事项：虽然 MFA 增加了额外的安全层，但它可以限制自动化灵活性，尤其是在必须运行自动化且无需手动干预的生产环境中。转移到托管标识、服务主体或联合标识（专为自动化目的设计且不需要 MFA）在此类环境中更为实用和安全。

需要更新的方案

以下列表提供了一些示例方案，客户可以使用 Microsoft Entra 用户标识通过 Azure CLI 实现自动化。此列表并非所有方案都详尽无遗。

警告

使用 Microsoft Entra 用户标识的任何自动化方案都需要更新。

个性化或专门权限：需要用户特定权限的自动化任务，例如与个人角色或特定 Microsoft Entra ID 属性相关的操作任务。
OAuth 2.0 ROPC 流：OAuth 2.0 资源所有者密码凭证（ROPC）令牌授予流程与 MFA 不兼容。当需要 MFA 时，使用 ROPC 进行身份验证的自动化方案会失败，因为 MFA 无法在非交互式流中完成。
访问 Azure 外部资源：需要访问 Microsoft 365 资源的自动化方案。例如，与单个用户的Microsoft帐户绑定的 SharePoint、Exchange 或其他云服务。
从 Active Directory 同步到 Microsoft Entra ID 的服务帐户：使用从 Active Directory (AD) 同步到 Microsoft Entra ID 的服务帐户的组织。请务必注意，这些帐户也受 MFA 要求的约束，并触发与其他用户标识相同的问题。
用于审核或合规的用户上下文：出于合规性原因，需要对单个用户级别的操作进行审核的情况。
小型或低风险自动化的简单配置：适用于小规模或低风险自动化任务。例如，用于管理一些资源的脚本。
非生产环境中的用户驱动自动化：如果自动化适用于负责任务的个人或非生产环境。
用户自己的 Azure 订阅中的自动化：如果用户需要在用户拥有足够权限的自己的 Azure 订阅中自动执行任务。

鉴于 Microsoft Entra 用户身份已强制实施 MFA，在自动化场景中需要切换到托管身份或服务主体。

如何开始

要将 Azure CLI 脚本从使用 az login 和 Microsoft Entra ID 用户帐户及密码迁移，请执行以下步骤：

确定哪个工作负荷标识最适合你。
- 服务主体
- 托管标识
- 联合标识
获取创建新工作负荷标识所需的权限，或联系 Azure 管理员以获取帮助。
创建工作负荷标识。
将角色分配给新身份。有关 Azure 角色分配的详细信息，请参阅分配 Azure 角色的步骤。若要使用 Azure CLI 分配角色，请参阅使用 Azure CLI 分配 Azure 角色。
更新 Azure CLI 脚本以使用服务主体或托管标识登录。

服务主体关键概念

可以访问多个 Azure 资源的非人标识。服务主体由许多 Azure 资源使用，不绑定到单个 Azure 资源。
可以根据需要更改服务主体的属性和凭据。
非常适合需要跨不同订阅访问多个 Azure 资源的应用程序。
认为比托管标识更灵活，但安全性更低。
通常称为 Azure 租户中的“应用程序对象”或 Microsoft Entra ID 目录中的对象。

若要了解有关服务主体的详细信息，请参阅：

若要了解如何使用 Azure CLI 和服务主体登录到 Azure，请参阅使用 Azure CLI 通过服务主体登录到 Azure

托管标识关键概念

绑定到特定的 Azure 资源，允许单个资源访问其他 Azure 应用程序。
你无法访问凭据。 Azure 处理机密、凭据、证书和密钥。
非常适合需要在单个订阅中访问其他 Azure 资源的 Azure 资源。
被认为灵活性较低，但比服务主体更安全。
托管标识分为两种类型：
- 系统分配：此类型是两个 Azure 资源之间的 1：1（一对一）访问链接。
- 用户分配：此类型具有 1：M（一对多）关系，其中托管标识可以访问多个 Azure 资源。

若要了解托管标识的详细信息，请参阅 Azure 资源托管标识。

若要了解如何使用 Azure CLI 和托管标识登录到 Azure，请参阅使用 Azure CLI 使用托管标识登录到 Azure

联合标识密钥概念

联合标识允许服务主体（应用注册）和用户分配的托管标识信任来自外部标识提供者（IdP）（例如 GitHub 或 Google）的令牌。
创建信任关系后，外部软件工作负载将从外部 IdP 交换可信令牌，以获取来自 Microsoft 身份平台的访问令牌。
然后，软件工作负荷将使用该访问令牌来访问自身已获得访问权限的受 Microsoft Entra 保护的资源。
联合标识通常是以下方案的最佳解决方案：
- 在任何 Kubernetes 群集上运行的工作负荷
- GitHub 操作
- 使用应用程序标识在 Azure 计算平台上运行的工作负荷
- Google Cloud
- Amazon Web Services （AWS）
- 在 Azure 外部的计算平台中运行的工作负荷

若要了解有关联合标识的详细信息，请参阅：

故障排除

ROPC 错误：由于管理员所做的配置更改

尝试使用密码登录到 Azure 时，这称为 ROPC 流（资源所有者密码凭据）。 MFA 不支持此身份验证方法。下面是一个示例：

az login --username $username –password $password

如果用户需要 MFA，上述命令将失败并显示以下错误消息：

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new ___location, you must use multi-factor authentication to access ‘’. Trace ID Correlation ID: Timestamp:

方案： 切换到使用与多因素认证兼容的身份验证方法。

跨租户警告：对特定租户的身份验证失败

如果您有权访问多个租户，并且其中一个租户需要 MFA，Azure CLI 可能会显示如下所示的警告消息：

Authentication failed against tenant 00000000-0000-0000-0000-000000000000 'Tenant Name': AADSTSXXXXX: Due to a configuration change made by your administrator, or because you moved to a new ___location, you must use multi-factor authentication to access '00000000-0000-0000-0000-000000000000'. Trace ID: 00000000-0000-0000-0000-000000000000 Correlation ID: 00000000-0000-0000-0000-000000000000 Timestamp: yyyy-mm-dd hh:mm:ss.

在登录阶段，Azure CLI 尝试使用 找到的第一个租户登录。虽然我们正在努力解决此问题，请指定要与 --tenant 参数一起使用的租户：

az login --tenant 00000000-0000-0000-0000-000000000000

详细了解多重身份验证

Microsoft Entra ID 文档网站提供有关 MFA 的更多详细信息。

通过