錯誤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 服務租使用者。 在預設租使用者內，沒有任何鏈接目錄可執行任何動作。 這是預期的行為。

在先前的體驗中，目錄 (例如：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 身分識別平台 只支援 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 圖形 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) 互動。 如需常見的移轉問題，請參閱 移轉常見問題。 注意： 1.0.x 版的 MSOnline 可能會在 2024 年 6 月 30 日之後中斷。

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

注意事項

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

當來賓使用者接受邀請時，用戶的LiveID屬性 (使用者的唯一登入標識碼) 儲存在 屬性中AlternativeSecurityIdskey。 因為使用者帳戶已刪除並在主租使用者中建立， NetID 所以主租用戶中使用者的帳戶值將會變更。 NetID將主租使用者中的用戶帳戶值與儲存在資源租使用者中來賓帳戶內AlternativeSecurityIds的密鑰值進行比較，如下所示：

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

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

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

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

  3. 使用 base64.guru) 等線上轉換器 (，將base64編碼的字串轉換成十六進位值。

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

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

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

與我們連絡，以取得說明

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