为合作伙伴租户强制执行多重身份验证 (MFA)

项目
05/13/2024

相应的角色：管理员代理 | 销售代理 | 支持人员代理 | 计费管理员 | 全局管理员

更好的安全性和持续的安全和隐私保护措施是我们的首要任务之一，我们将继续帮助合作伙伴保护其客户和租户。

为了帮助合作伙伴保护其业务和客户免受身份盗窃和未经授权的访问，我们为合作伙伴租户激活了更多的安全措施。这些保障措施授权并验证 MFA。通过管理 MFA，合作伙伴可以保护其访问客户资源免受凭据泄露的影响。

本文提供了有关在合作伙伴中心管理多重身份验证（MFA）的详细示例和指南。

参与云解决方案提供商（CSP）计划的合作伙伴、控制面板供应商（CPV）和顾问必须实施合作伙伴安全要求才能保持合规。

合作伙伴必须为其合作伙伴租户中的所有用户帐户（包括来宾用户）强制实施 MFA。用户必须完成以下方面的 MFA 验证：

合作伙伴中心
合作伙伴中心 API
合作伙伴委派的管理

合作伙伴中心

合作伙伴中心的某些页面受 MFA 保护，包括：

“客户”选项卡下的所有页面（即 URL 开头https://partner.microsoft.com/commerce/*的所有页面）
“支持>客户请求”选项卡下的所有页面（例如，以 URL 开头https://partner.microsoft.com/dashboard/v2/support/customers/*访问的所有页面）
“ 计费 ”选项卡中的所有页面

合作伙伴中心中的其他页面（例如“概述”页和服务运行状况检查页）不需要 MFA。

下表显示了哪些用户类型有权访问这些受 MFA 保护的页面（并且受此功能影响）。

受 MFA 保护的页面	管理员代理	销售代理	支持人员代理	全局管理员	计费管理员
“客户”选项卡下的所有页面	x	X	x
“ 支持 > 客户请求 ”选项卡下的所有页面	x		x
计费页	x			X	x

若要访问这些页面，必须先完成 MFA 验证。

受支持的 MFA 选项

使用 Microsoft 支持的 Microsoft Entra 多重身份验证的合作伙伴。有关详细信息，请参阅启用 Microsoft Entra 多重身份验证的多种方法（支持 MFA）
实现了集成 MFA 联合身份验证的合作伙伴。允许这些合作伙伴用户访问合作伙伴中心并使用 GDAP 管理客户。请参阅 AD FS 提供的具有 MFA 产品/服务的集成 MFA 提供程序：为 AD FS 配置方法。

重要

合作伙伴需要使用与 Microsoft Entra ID 的集成 MFA 声明兼容的身份验证提供程序。集成声明指示身份验证期间提供的实际凭据类型。合作伙伴需要使用集成的 MFA 来管理使用 GDAP 的客户租户。

合作伙伴中心和 API

对于以下合作伙伴中心 API，需要应用+用户访问和 Microsoft Entra ID 支持 MFA：

发现（价格/目录/促销）
交易和管理
计费和对帐
使用委派访问权限/AOBO 管理客户
用户和许可证分配（仅限 DAP）
用户和许可证分配（限 GDAP）
精细的管理员关系请求和访问权限分配

以下选项适用于合作伙伴：

使用 Microsoft 内置身份验证方法满足 MFA 要求。
如果使用联合标识提供者，请确保联合身份验证配置为接受联合 MFA。
如果要使用 ADFS 配置外部第二因素，请参阅具有 AD FS 提供的 MFA 产品/服务的第三方提供商：为 AD FS 配置身份验证方法
实现 MFA：按照安全默认值指南或条件访问立即启用 MFA。

验证示例

若要说明验证在合作伙伴中心的工作原理，请考虑以下示例。

示例 1：合作伙伴已实现 Microsoft Entra 多重身份验证

Alejandra 适用于名为 Contoso 的 CSP。 Contoso 使用 Microsoft Entra 多重身份验证为 Contoso 合作伙伴租户下的所有用户实现了 MFA。
Alejandra 启动新的浏览器会话，并转到合作伙伴中心概述页（不受 MFA 保护）。合作伙伴中心将 Alejandra 重定向到 Microsoft Entra ID 以登录。
由于 Contoso 现有的 Microsoft Entra 多重身份验证设置，Alejandra 需要完成 MFA 验证。成功登录和 MFA 验证后，Alejandra 将重定向回合作伙伴中心概述页。
Alejandra 尝试访问合作伙伴中心中受 MFA 保护的页面之一。由于 Alejandra 在登录期间已完成 MFA 验证，因此 Alejandra 可以访问受 MFA 保护的页面，而无需再次通过 MFA 验证。

示例 2：合作伙伴已使用联合身份验证实现了非 Microsoft MFA

Prashob 为名为 Wingtip 的 CSP 工作。 Wingtip 使用非 Microsoft MFA（通过联合身份验证与 Microsoft Entra ID 集成）为 Wingtip 合作伙伴租户下的所有用户实现了 MFA。
Prashob 启动新的浏览器会话，并转到合作伙伴中心概述页（不受 MFA 保护）。合作伙伴中心将 Prashob 重定向到 Microsoft Entra ID 以登录。
由于 Wingtip 设置了标识联合，因此 Microsoft Entra ID 会将 Prashob 重定向到联合标识提供者以完成登录和 MFA 验证。成功登录和 MFA 验证后，Prashob 会重定向回 Microsoft Entra ID，然后重定向到合作伙伴中心概述页。
Prashob 尝试访问合作伙伴中心中任一受 MFA 保护的页面。由于 Prashob 在登录之前已完成 MFA 验证，因此他无需再次通过 MFA 验证即可访问受 MFA 保护的页面。
Prashob 然后转到服务管理页，将用户添加到 Contoso 的 Microsoft Entra ID 中。由于 Prashob 已将 Entra 兼容的身份验证提供程序与强身份验证配合使用，因此他们无需任何问题即可访问客户租户。

此示例中 Prashob 的建议是使用 Microsoft Entra 多重身份验证解决方案或与 Entra 兼容的身份验证提供程序，以便他们可以成功管理客户的租户。

示例 3：合作伙伴尚未实现 MFA

名为 Fabrikam 的 CSP 合作伙伴尚未实现 MFA。 Microsoft 建议他们实现 Microsoft Entra ID 支持的 MFA 解决方案。
John 为 Fabrikam 工作。 Fabrikam 尚未为 Fabrikam 合作伙伴租户下的任何用户实现 MFA。
John 启动新的浏览器会话，并转到合作伙伴中心概述页（不受 MFA 保护）。合作伙伴中心将 John 重定向到 Microsoft Entra ID 以登录。
成功登录后，John 将重定向回合作伙伴中心概述页，因为他尚未完成 MFA 验证。
John 尝试访问合作伙伴中心中任一受 MFA 保护的页面。由于 John 尚未完成 MFA 验证，合作伙伴中心会将 John 重定向到 Microsoft Entra ID 以完成 MFA 验证。由于这是约翰首次需要完成 MFA，因此还要求 John 注册 MFA。成功进行 MFA 注册和 MFA 验证后，John 可以访问受 MFA 保护的页面。
在另一天，在 Fabrikam 为任何用户实现 MFA 之前，John 会启动新的浏览器会话，并转到合作伙伴中心概述页（不受 MFA 保护）。合作伙伴中心将 John 重定向到 Microsoft Entra ID 以在没有 MFA 提示的情况下登录。
John 尝试访问合作伙伴中心中任一受 MFA 保护的页面。由于 John 尚未完成 MFA 验证，合作伙伴中心会将 John 重定向到 Microsoft Entra ID 以完成 MFA 验证。由于 John 已注册 MFA，所以这次他只要求完成 MFA 验证。

示例 4：合作伙伴实现了与 Microsoft Entra 不兼容的非 Microsoft MFA

Trent 为名为 Wingtip 的 CSP 工作。 Wingtip 已在 Wingtip 合作伙伴租户下为其所有用户实施 MFA，并在具有条件访问的云环境中使用非 Microsoft MFA。
Trent 启动新的浏览器会话，并转到合作伙伴中心概述页（不受 MFA 保护）。合作伙伴中心将 Trent 重定向到 Microsoft Entra ID 以登录。
由于 Wingtip 使用了与 Microsoft Entra ID 不兼容且没有强身份验证的非 Microsoft MFA 集成，因此 Trent 将被阻止访问合作伙伴中心内所有受 MFA 保护的页面和 API。

由于 Trent 正在访问受 MFA 保护的页面，因此需要向 MFA 提供强身份验证才能访问受 MFA 保护的页面。

合作伙伴需要使用与 Microsoft Entra ID 兼容的身份验证提供程序，该提供程序支持凭据方法声明（Access 令牌声明引用中的“amr 声明”- Microsoft 标识平台，反映身份验证期间提供的实际凭据类型。

我们强烈建议云解决方案提供商合作伙伴实施与 Microsoft Entra ID 兼容的 MFA，以立即提高租户的安全基线。

合作伙伴中心 API

合作伙伴中心 API 同时支持“仅应用”身份验证和“应用程序 + 用户（应用 + 用户）”身份验证。

使用 App+User 身份验证时，合作伙伴中心需要 MFA 验证。更具体地说，当合作伙伴应用程序向合作伙伴中心发送 API 请求时，它必须在请求的授权标头中包含访问令牌。

注意

安全应用程序模型框架是一种可缩放的框架，用于在你调用合作伙伴中心 API 时通过 Microsoft Azure MFA 体系结构对 CSP 合作伙伴和 CPV 进行身份验证。在服务自动化中使用 MFA 时，必须实现此框架。

当合作伙伴中心收到具有使用 App+User 身份验证获取的访问令牌的 API 请求时，合作伙伴中心 API 检查身份验证方法参考（AMR）声明中是否存在 MFA 值。你可以使用 JWT 解码器来验证访问令牌是否包含所需的身份验证方法引用 (AMR) 值：

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "23ec45a3-5127-4185-9eff-c8887839e6ab",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "4988e250-5aee-482a-9136-6d269cb755c0",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "df845f1a-7b35-40a2-ba78-6481de91f8ae",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

如果值存在，合作伙伴中心则会得出已完成 MFA 验证的结论并处理 API 请求。

如果值不存在，合作伙伴中心 API 会使用以下响应拒绝请求：

HTTP/1.1 401 Unauthorized - MFA required
Transfer-Encoding: chunked
Request-Context: appId=cid-v1:03ce8ca8-8373-4021-8f25-d5dd45c7b12f
WWW-Authenticate: Bearer error="invalid_token"
Date: Thu, 14 Feb 2019 21:54:58 GMT

调用合作伙伴中心 API 时，仅客户租户中不需要 GDAP 角色分配的操作才支持仅限应用的访问令牌。

若要了解更多详细信息，请参阅 API 身份验证和授权 - 概述。

合作伙伴委派的管理

合作伙伴租户应使用精细委派的管理员权限（GDAP）通过 Microsoft Online Services 门户（portal.azure.com 或 admin.microsoft.com）、命令行界面（CLI）和 API（使用 App+User 身份验证）管理客户资源。有关详细信息，请参阅支持的 MFA 选项。

使用服务门户

CSP 合作伙伴可以通过服务管理界面从合作伙伴中心门户管理客户。合作伙伴可以导航到客户并选择“服务管理”，以便为客户管理特定服务。合作伙伴需要遵循 GDAP 角色指南来获取正确的最低特权 GDAP 角色来管理其客户。

使用合作伙伴委派管理员特权（管理员代理）访问 Microsoft Online Services 门户来管理客户资源时，其中许多门户要求合作伙伴帐户以交互方式进行身份验证，并将客户 Microsoft Entra 租户设置为身份验证上下文。需要合作伙伴帐户才能登录到客户租户。

如果存在需要 MFA 的策略，Microsoft Entra ID 身份验证要求用户完成 MFA 验证。可以使用两种用户体验，具体取决于合作伙伴帐户是托管标识还是联合身份标识：

如果合作伙伴帐户是托管标识，Microsoft Entra ID 会直接提示用户完成 MFA 验证。如果合作伙伴帐户以前未使用 Microsoft Entra ID 注册 MFA，则要求用户首先完成 MFA 注册。
如果合作伙伴帐户是联合标识，体验取决于合作伙伴管理员在 Microsoft Entra ID 中配置联合身份验证的方式。在 Microsoft Entra ID 中设置联合身份验证时，合作伙伴管理员可以向 Microsoft Entra ID 指示联合标识提供者是否支持 MFA。
- 如果是这样，Microsoft Entra ID 会将用户重定向到联合标识提供者以完成 MFA 验证。
- 否则，Microsoft Entra ID 会直接提示用户完成 MFA 验证。如果合作伙伴帐户以前未使用 Microsoft Entra ID 注册 MFA，则要求用户首先完成 MFA 注册。

整体体验类似于最终用户租户为其管理员实现 MFA 的方案。例如，客户租户已启用 Microsoft Entra 安全默认值，这要求具有管理权限的所有帐户使用 MFA 验证登录到客户租户，包括管理员代理和支持人员代理。

出于测试目的，合作伙伴可以在客户租户中启用 Microsoft Entra 安全默认值，然后尝试使用合作伙伴粒度委派管理员特权（GDAP）访问客户租户。

注意

并非所有 Microsoft Online Service 门户都需要合作伙伴帐户在使用 GDAP 访问客户资源时登录到客户租户。相反，有些人只需要合作伙伴帐户登录到合作伙伴租户。 Exchange 管理中心就是一个例子。随着时间的推移，我们希望这些门户要求合作伙伴帐户在使用 GDAP 时登录到客户租户。

MFA 注册体验

在 MFA 验证期间，如果合作伙伴帐户以前未注册 MFA，Microsoft Entra ID 会提示用户先完成 MFA 注册。

查看有关 Microsoft Authenticator 方法的详细信息：

MFA 注册的第一步的屏幕截图。

用户选择 “下一步”后，系统会要求他们从验证方法列表中选择。

MFA 注册中第二步的屏幕截图。

注册成功后，用户必须使用所选的验证方法完成 MFA 验证。

常见问题

查看其他合作伙伴报告的常见问题列表，以了解请求是否有效。

问题 1：合作伙伴需要更多时间来为其合作伙伴代理实施 MFA

合作伙伴尚未为他们的合作伙伴代理实现 MFA 或者正在实现过程中，这些代理需要使用合作伙伴委派的管理权限来访问 Microsoft Online Services 门户以管理客户资源。合作伙伴需要更多的时间来完成 MFA 实现。这能否成为请求技术例外的有效理由？

答：否。合作伙伴需要计划为其用户实施 MFA，以避免中断。

注意

尽管合作伙伴尚未为其合作伙伴代理实现 MFA，但合作伙伴代理仍可以使用合作伙伴委派管理员特权访问 Microsoft Online Services 门户，如果他们可以在登录客户租户期间出现提示时完成 MFA 注册和 MFA 验证。完成 MFA 注册不会自动为用户启用 MFA。

问题 2：合作伙伴尚未实施 MFA，因为它们不需要访问来管理客户

合作伙伴在其合作伙伴租户中拥有一些用户，他们不需要访问 Microsoft Online Services 门户，以使用合作伙伴委派管理员权限管理客户资源。合作伙伴正在为这些用户实现 MFA，需要更多的时间才能完成。这能否成为请求技术例外的有效理由？

答：否。由于这些用户帐户不使用合作伙伴委派管理员特权来管理客户资源，因此无需登录到客户租户。它们不会受到 Microsoft Entra ID 的影响，要求在登录到客户租户期间进行 MFA 验证。所有用户都需要拥有 MFA 才能访问合作伙伴中心或客户工作负载来管理客户资源。

问题 3：合作伙伴尚未为用户帐户实现 MFA

某一合作伙伴在他们的合作伙伴租户中拥有一些用户帐户，这些帐户由设备作为服务帐户使用。这些低特权帐户不需要访问合作伙伴中心或 Microsoft Online Services 门户，才能使用合作伙伴委派管理员特权管理客户资源。这是技术异常的有效原因吗？

答：否。由于这些用户帐户不使用合作伙伴委派管理员权限来管理客户资源，因此无需登录到客户租户。它们不会受到 Microsoft Entra ID 的影响，要求在登录到客户租户期间进行 MFA 验证。如果 API 或门户需要应用+用户身份验证，则每个用户都需要使用 MFA 进行身份验证。

问题 4：合作伙伴无法使用 Microsoft Authenticator 应用实现 MFA

合作伙伴具有“清洁办公桌”策略，不允许员工将个人移动设备带到其工作区。员工无法访问其个人移动设备，则无法安装 Microsoft Authenticator 应用，这是 Microsoft Entra 安全默认设置支持的唯一 MFA 验证。这能否成为请求技术例外的有效理由？

答：否。合作伙伴应考虑以下替代方法，以便其员工在访问合作伙伴中心时仍可以完成 MFA 验证：

合作伙伴还可以注册 Microsoft Entra ID P1 或 P2，或使用与 Microsoft Entra ID 兼容的非 Microsoft MFA 解决方案，以提供更多验证方法。若要了解详细信息，请参阅支持的身份验证方法。

问题 5：由于使用旧式身份验证协议，合作伙伴无法实现 MFA

某一合作伙伴的某些合作伙伴代理仍然在使用旧式身份验证协议，这与 MFA 不兼容。例如，用户仍然在使用 Outlook 2010，此程序基于的是旧式身份验证协议。为这些合作伙伴代理启用 MFA 将中断旧式身份验证协议的使用。这能否成为请求技术例外的有效理由？

答：否。由于潜在的安全隐患，鼓励合作伙伴远离旧式身份验证协议的使用，因为这些协议无法通过 MFA 验证进行保护，并且更容易受到凭据泄露的影响。建议弃用任何旧式身份验证并使用安全默认值或条件访问。若要准备退出旧式身份验证，请查看使用旧式身份验证工作簿的登录以及有关如何阻止旧身份验证的指导。

若要了解支持 Outlook 旧式身份验证的最新计划，请阅读有关基本身份验证和 Exchange Online 的文章，并按照 Exchange 团队博客获取即将发布的新闻。

问题 6：合作伙伴已实现 Microsoft Entra ID 无法识别的非 Microsoft MFA

合作伙伴已使用非 Microsoft MFA 解决方案为其用户实现 MFA。但是，合作伙伴无法正确配置非 Microsoft MFA 解决方案，以中继到在用户身份验证期间已完成 MFA 验证的 Microsoft Entra ID。这能否成为请求技术例外的有效理由？

答：否，合作伙伴需要使用与 Entra ID 兼容的身份验证提供程序，该提供程序支持凭据方法声明（“AMR”），访问令牌声明引用 - Microsoft 标识平台，反映身份验证期间提供的实际凭据类型。

强烈建议你实现与 Microsoft Entra ID 立即兼容的 MFA，以提高租户的安全基线。

后续步骤

合作伙伴安全要求状态

通过