AADSTS50020错误 - 租户中不存在来自标识提供者的用户帐户

项目
11/19/2024

本文可帮助你排查来自标识提供者（IdP）的来宾用户无法登录到Microsoft Entra ID 中的资源租户时返回的错误代码 AADSTS50020 。

现象

当来宾用户尝试访问资源租户中的应用程序或资源时，登录将失败，并显示以下错误消息：

AADSTS50020：来自标识提供者 {IdentityProviderURL} 的用户帐户“user@domain.com”在租户 {ResourceTenantName} 中不存在。

当管理员查看主租户上的登录日志时，“90072”错误代码条目表示登录失败。错误消息指出：

来自标识提供者 {idp} 的用户帐户 {email} 在租户 {tenant} 中不存在，并且无法访问该租户中的应用程序 {appId}（{appName}）。首先需要将该帐户作为外部用户添加到租户中。注销并使用另一 Microsoft Entra 用户帐户再次登录。

原因 1：用户使用个人Microsoft帐户登录到 Microsoft Entra 管理中心

尝试使用个人Microsoft帐户（Outlook、Hotmail 或 OneDrive）登录到 Microsoft Entra 管理中心时，默认连接到Microsoft服务租户。在默认租户中，没有用于执行任何操作的链接目录。这是预期的行为。

在以前的体验中，将创建一个目录（例如：UserNamehotmail735.onmicrosoft.com），并将其链接到个人帐户，你可以执行操作，例如在目录中创建用户帐户。行为现已更改。

解决方案：使用新租户创建 Azure 帐户

如果打算有一个目录，则必须创建一个 Azure 帐户和一个新租户：

浏览到 https://azure.microsoft.com/en-us/free/，然后选择“ 免费开始”。
按照说明创建 Azure 帐户。
租户将与 Azure 帐户一起生成，你将被自动指定为全局管理员。这会授予你对此租户中的所有选项的完全访问权限。

原因 2：使用了不受支持的帐户类型（多租户和个人帐户）

如果应用注册设置为单租户帐户类型，则来自其他目录或标识提供者的用户无法登录到该应用程序。

若要确保应用注册不是单租户帐户类型，请执行以下步骤：

在 Azure 门户中，搜索并选择“应用注册”。
选择应用注册的名称。
在边栏中，选择“ 清单”。
在 JSON 代码中 ，找到 signInAudience 设置。
检查设置是否包含以下值之一：
- AzureADandPersonalMicrosoftAccount
- AzureADMultipleOrgs
- PersonalMicrosoftAccount
如果 signInAudience 设置不包含这些值之一，请通过选择正确的帐户类型重新创建应用注册。当前无法在清单中更改 signInAudience 。

有关如何注册应用程序的详细信息，请参阅快速入门：将应用程序注册到Microsoft 标识平台。

原因 3：使用了错误的终结点（个人和组织帐户）

如果应用注册支持的帐户类型设置为以下值之一，身份验证调用必须以与所选内容匹配的 URL 为目标：

任何组织目录中的帐户（任何Microsoft Entra 目录 - 多租户）
任何组织目录中的帐户（任何Microsoft Entra 目录 - 多租户）和个人Microsoft帐户（例如 Skype、Xbox）
仅限个人Microsoft帐户

如果使用 https://login.microsoftonline.com/<YourTenantNameOrID>，则来自其他组织的用户无法访问该应用程序。必须在请求中指定的租户中将这些用户添加为来宾。在这种情况下，身份验证应仅在租户上运行。如果希望用户使用与其他租户或标识提供者的联合身份验证登录，则此方案会导致登录错误。

对特定应用程序类型使用相应的登录 URL，如下表所示：

应用程序类型	登录 URL
多租户应用程序	`https://login.microsoftonline.com/organizations`
多租户和个人帐户	`https://login.microsoftonline.com/common`
仅个人帐户	`https://login.microsoftonline.com/consumers`

在应用程序代码中，在设置中 Authority 应用此 URL 值。有关详细信息Authority，请参阅Microsoft 标识平台应用程序配置选项。

原因 4：登录到错误的租户

当用户尝试访问应用程序时，要么将直接链接发送到应用程序，要么尝试通过该 https://myapps.microsoft.com链接获取访问权限。在任一情况下，用户都重定向到登录到应用程序。在某些情况下，用户可能已经有一个活动会话，该会话使用与要使用的会话不同的个人帐户。或者，他们有一个使用其组织帐户的会话，尽管他们打算使用个人来宾帐户（反之亦然）。

若要确保这种情况是问题，请在错误消息中查找 User account 和 Identity provider 值。这些值是否与预期的组合匹配？例如，用户是否使用其组织帐户登录到租户而不是其主租户？或者用户是否使用与已邀请的标识提供者不同的个人帐户登录live.com？

指示用户打开新的专用浏览器会话，或者让用户尝试从其他浏览器访问。在这种情况下，用户必须从其活动会话中注销，然后再次尝试登录。

原因 5：未邀请来宾用户

尝试登录的来宾用户没有被邀请到租户。

解决方案：邀请来宾用户

请确保按照快速入门中的步骤操作：将来宾用户添加到Azure 门户中的目录以邀请来宾用户。

原因 6：应用需要用户分配

如果应用程序是需要用户分配的企业应用程序，则如果用户不在分配应用程序访问权限的允许用户列表中，则会发生错误 AADSTS50020 。若要检查企业应用程序是否需要用户分配，请执行以下操作：

在Azure 门户中，搜索并选择“企业应用程序”。
选择企业应用程序。
在边栏中，选择“ 属性”。
检查“分配所需的”选项是否设置为“是”。

解决方案：单独或作为组的一部分向用户分配访问权限

使用以下选项之一向用户分配访问权限：

若要单独向应用程序分配用户访问权限，请参阅向企业应用程序分配用户帐户。
若要为用户分配组或动态组的成员分配用户，请参阅 “管理对应用程序的访问权限”。

原因 7：尝试对个人帐户使用资源所有者密码凭据流

如果用户尝试将资源所有者密码凭据（ROPC）流用于个人帐户，则会发生错误AADSTS50020。 Microsoft 标识平台仅在 Microsoft Entra 租户中支持 ROPC，不支持个人帐户。

解决方案：使用特定于租户或组织的终结点

使用特定于租户的终结点（https://login.microsoftonline.com/<TenantIDOrName>）或组织的终结点。受邀加入 Microsoft Entra 租户的个人帐户不能使用 ROPC。有关详细信息，请参阅 Microsoft 标识平台和 OAuth 2.0 资源所有者密码凭据。

原因 8：以前删除的用户名由主租户管理员重新创建

如果主租户的管理员重新创建在资源租户中删除的来宾用户的名称，则可能会出现错误 AADSTS50020 。若要验证资源租户中的来宾用户帐户是否未与主租户中的用户帐户相关联，请使用以下选项之一：

验证选项 1：检查资源租户的来宾用户是否早于主租户的用户帐户

第一个验证选项涉及将资源租户的来宾用户与主租户用户帐户的年龄进行比较。可以使用 Microsoft Graph 或 MSOnline PowerShell 进行此验证。

Microsoft Graph

向 MS Graph API 发出请求以查看用户创建日期，如下所示：

GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}/createdDateTime

然后，根据主租户中用户帐户的创建日期检查资源租户中的来宾用户的创建日期。如果来宾用户是在创建主租户用户帐户之前创建的，则确认此方案。

MSOnline PowerShell

注意

MSOnline PowerShell 模块设置为已弃用。由于它与 PowerShell Core 不兼容，因此请确保使用的是兼容的 PowerShell 版本，以便可以运行以下命令。

运行 Get-MsolUser PowerShell cmdlet 以查看用户创建日期，如下所示：

Get-MsolUser -SearchString user@contoso.com | Format-List whenCreated

然后，根据主租户中用户帐户的创建日期检查资源租户中的来宾用户的创建日期。如果来宾用户是在创建主租户用户帐户之前创建的，则确认此方案。

注意

自 2024 年 3 月 30 日起，Azure AD 和 MSOnline PowerShell 模块已弃用。若要了解详细信息，请阅读有关弃用的更新。在此日期之后，对这些模块的支持仅限于到 Microsoft Graph PowerShell SDK 的迁移帮助和安全性修复。弃用的模块将持续运行至 2025 年 3 月 30 日。

我们建议迁移到 Microsoft Graph PowerShell，以便与 Microsoft Entra ID（以前称为 Azure AD）进行交互。有关常见迁移问题，请参阅迁移常见问题解答。 注意：2024 年 6 月 30 日之后，MSOnline 版本 1.0.x 可能会遇到中断。

验证选项 2：检查资源租户的来宾备用安全 ID 是否与主租户的用户净 ID 不同

注意

MSOnline PowerShell 模块设置为已弃用。由于它与 PowerShell Core 不兼容，因此请确保使用的是兼容的 PowerShell 版本，以便可以运行以下命令。

当来宾用户接受邀请时，用户 LiveID 的属性（用户的唯一登录 ID）存储在 AlternativeSecurityIds 属性中 key 。由于用户帐户已删除并在主租户中创建， NetID 因此该帐户的值将更改主租户中的用户。将 NetID 主租户中用户帐户的值与资源租户中来宾帐户中 AlternativeSecurityIds 存储的密钥值进行比较，如下所示：

在主租户中，使用 Get-MsolUser PowerShell cmdlet 检索属性的值LiveID：
```
Get-MsolUser -SearchString tuser1 | Select-Object -ExpandProperty LiveID
```

在资源租户中，将属性AlternativeSecurityIds的值key转换为 base64 编码的字符串：

[convert]::ToBase64String((Get-MsolUser -ObjectId 01234567-89ab-cdef-0123-456789abcdef
       ).AlternativeSecurityIds.key)

使用联机转换器（如 base64.guru）将 base64 编码的字符串转换为十六进制值。
比较步骤 1 和步骤 3 中的值，以验证它们是否不同。 NetID删除并重新创建帐户时，主租户中的用户帐户已更改。

解决方案：重置来宾用户帐户的兑换状态

重置资源租户中来宾用户帐户的兑换状态。然后，可以保留来宾用户对象，而无需删除，然后重新创建来宾帐户。可以使用 Azure 门户、Azure PowerShell 或 Microsoft 图形 API 重置兑换状态。有关说明，请参阅来宾用户的重置兑换状态。

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。你还可以将产品反馈提交到 Azure 反馈社区。

通过