共用方式為

錯誤AADSTS50020 - 身分識別提供者的用戶帳戶不存在於租使用者中

  • 發行項

本文可協助您針對來自識別提供者 （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 Services 租使用者。 在預設租使用者中，沒有任何鏈接的目錄可執行任何動作。 此行為是預期的。

在先前的體驗中，會建立目錄（例如：UserNamehotmail735.onmicrosoft.com），並連結到個人帳戶，您可以執行動作，例如在目錄中建立用戶帳戶。 行為現已變更。

解決方案：使用新的租使用者建立 Azure 帳戶

如果您的目標是要有目錄，您必須建立 Azure 帳戶和新的租使用者：

  1. 流覽至 https://azure.microsoft.com/en-us/free/，然後選取 [ 免費啟動 ]。
  2. 請遵循指示來建立 Azure 帳戶。
  3. 租使用者將會與 Azure 帳戶一起產生，且會自動指定為全域管理員。 這會授與您此租用戶內所有選項的完整存取權。

原因 2：使用不支援的帳戶類型 （多租使用者和個人帳戶）

如果您的應用程式註冊設定為單一租用戶帳戶類型，則來自其他目錄或識別提供者的用戶無法登入該應用程式。

解決方案：變更應用程式註冊指令清單中的登入物件設定

若要確定您的應用程式註冊不是單一租用戶帳戶類型，請執行下列步驟：

  1. 在 Azure 入口網站中，搜尋並選取應用程式註冊。

  2. 選取應用程式註冊的名稱。

  3. 在提要欄位中，選取 [ 指令清單]。

  4. 在 JSON 程式代碼中，尋找 signInAudience 設定。

  5. 檢查設定是否包含下列其中一個值：

    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

    如果 signInAudience 設定不包含其中一個值，請選取正確的帳戶類型，以重新建立應用程式註冊。 您目前無法在指令清單中變更 signInAudience 。

如需如何註冊應用程式的詳細資訊，請參閱快速入門：使用 Microsoft 身分識別平台 註冊應用程式。

原因 3：使用錯誤的端點 （個人和組織帳戶）

如果您的應用程式註冊支援的帳戶類型設定為下列其中一個值，您的驗證呼叫必須以符合您選取專案的 URL 為目標：

  • 任何組織目錄中的帳戶 （任何Microsoft Entra 目錄 - 多租使用者）

  • 任何組織目錄中的帳戶（任何Microsoft Entra 目錄 - 多租使用者）和個人Microsoft帳戶（例如 Skype、Xbox）

  • 僅限個人Microsoft帳戶

如果您使用 https://login.microsoftonline.com/<YourTenantNameOrID>，則來自其他組織的用戶無法存取應用程式。 您必須將這些使用者新增為要求中所指定租使用者中的來賓。 在此情況下，驗證應該只會在您的租用戶上執行。 如果您預期使用者使用與另一個租使用者或身分識別提供者的同盟來登入，此案例會導致登入錯誤。

解決方案：使用正確的登入URL

針對特定應用程式類型使用對應的登入 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 。 若要檢查您的企業應用程式是否需要使用者指派：

  1. 在 Azure 入口網站 中，搜尋並選取 [企業應用程式]。

  2. 選取您的企業應用程式。

  3. 在提要欄位中，選取 [ 屬性]。

  4. 檢查 [指派必要] 選項是否設定為 [是]。

解決方案：將個別或群組的存取權指派給使用者

使用下列其中一個選項將存取權指派給使用者：

原因 7：嘗試針對個人帳戶使用資源擁有者密碼認證流程

如果用戶嘗試使用個人帳戶的資源擁有者密碼認證 （ROPC） 流程，就會發生錯誤 AADSTS50020 。 Microsoft 身分識別平台 僅支援在 entra 租使用者內Microsoft 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) 互動。 如需了解常見的移轉問題，請參閱移轉常見問題。 注意：MSOnline 1.0.x 版可能會在 2024 年 6 月 30 日之後發生中斷。

驗證選項 2：檢查資源租用戶的來賓替代安全性識別碼是否與主租使用者的使用者凈標識碼不同

注意

MSOnline PowerShell 模組 已設定為已被取代。 因為它也與 PowerShell Core 不相容，所以請確定您使用相容的 PowerShell 版本，以便執行下列命令。

當來賓使用者接受邀請時，用戶的屬性（使用者LiveID的唯一登入標識符）會儲存在屬性中AlternativeSecurityIdskey。 由於使用者帳戶已刪除並在主租使用者中建立， NetID 因此帳戶的值將會變更為主租使用者中的使用者。 NetID比較主租用戶中用戶帳戶的值與資源租用戶中來賓帳戶內AlternativeSecurityIds儲存的索引鍵值，如下所示：

  1. 在主租使用者中，使用 Get-MsolUser PowerShell Cmdlet 擷取 屬性的值LiveID：

    Get-MsolUser -SearchString tuser1 | Select-Object -ExpandProperty LiveID

  2. 在資源租使用者中，將 key 中的 AlternativeSecurityIds 屬性值轉換為base64編碼的字串：

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

  3. 使用在線轉換器將base64編碼的字串轉換成十六進位值（例如 base64.guru）。

  4. 比較步驟 1 和步驟 3 中的值，以確認它們不同。 NetID當帳戶遭到刪除並重新建立時，主租使用者中的用戶帳戶的 變更。

解決方案：重設來賓用戶帳戶的兌換狀態

重設資源租用戶中來賓用戶帳戶的兌換狀態。 然後，您可以保留來賓用戶物件，而不需要刪除，然後重新建立來賓帳戶。 您可以使用 Azure 入口網站、Azure PowerShell 或 Microsoft Graph API 來重設兌換狀態。 如需指示，請參閱 重設來賓用戶的兌換狀態。

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。