エラー AADSTS50020 - ID プロバイダーのユーザー アカウントがテナントに存在しません
この記事は、ID プロバイダー (IdP) のゲスト ユーザーが Microsoft Entra ID のリソース テナントにサインインできない場合に返されるエラー コード AADSTS50020 のトラブルシューティングに役立ちます。
現象
ゲスト ユーザーがリソース テナント内のアプリケーションまたはリソースにアクセスしようとすると、サインインが失敗し、次のエラー メッセージが表示されます。
AADSTS50020: ID プロバイダー {IdentityProviderURL} のユーザー アカウント 'user@domain.com' がテナント {ResourceTenantName} に存在しません。
管理者がホーム テナントのサインイン ログを確認すると、"90072" エラー コード エントリはサインインエラーを示します。 エラー メッセージの状態は次のとおりです。
ID プロバイダー {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: サポートされていないアカウントの種類 (マルチテナントと個人用アカウント) を使用しました
アプリの登録がシングルテナント アカウントの種類に設定されている場合、他のディレクトリまたは ID プロバイダーのユーザーは、そのアプリケーションにサインインできません。
解決策: アプリ登録マニフェストでサインイン対象ユーザーの設定を変更する
アプリの登録がシングルテナント アカウントの種類ではないことを確認するには、次の手順に従います。
Azure portal で、 [アプリの登録] を検索して選択します。
アプリ登録の名前を選択します。
サイドバーで Manifest を選択します。
JSON コードで、 signInAudience 設定を見つけます。
設定に次のいずれかの値が含まれているかどうかを確認します。
- AzureADandPersonalMicrosoftAccount
- AzureADMultipleOrgs
- PersonalMicrosoftAccount
signInAudience設定にこれらの値のいずれかが含まれていない場合は、適切なアカウントの種類を選択してアプリの登録を再作成します。 現在、マニフェスト signInAudience を変更することはできません。
アプリケーションを登録する方法の詳細については、「Quickstart: Microsoft ID プラットフォームにアプリケーションを登録する」を参照してください。
原因 3: 間違ったエンドポイント (個人アカウントと組織アカウント) を使用しました
アプリ登録でサポートされているアカウントの種類が次のいずれかの値に設定されている場合、認証呼び出しは選択内容に一致する URL をターゲットにする必要があります。
任意の組織ディレクトリ内のアカウント (任意の Microsoft Entra ディレクトリ - マルチテナント)
任意の組織ディレクトリ (任意の Microsoft Entra ディレクトリ - マルチテナント) および個人用 Microsoft アカウント (Skype、Xbox など) 内のアカウント
個人用 Microsoft アカウントのみ
https://login.microsoftonline.com/<YourTenantNameOrID>を使用する場合、他の組織のユーザーはアプリケーションにアクセスできません。 これらのユーザーを、要求で指定されたテナントのゲストとして追加する必要があります。 その場合、認証はテナントでのみ実行されることが想定されます。 このシナリオでは、ユーザーが別のテナントまたは ID プロバイダーとのフェデレーションを使用してサインインすることが予想される場合、サインイン エラーが発生します。
解決策: 正しいサインイン URL を使用する
次の表に示すように、特定のアプリケーションの種類に対応するサインイン URL を使用します。
| アプリケーションの種類 | サインイン URL |
|---|---|
| マルチテナント アプリケーション | https://login.microsoftonline.com/organizations |
| マルチテナントと個人用アカウント | https://login.microsoftonline.com/common |
| 個人アカウントのみ | https://login.microsoftonline.com/consumers |
アプリケーション コードで、この URL 値を Authority 設定に適用します。 Authorityの詳細については、アプリケーション構成オプションMicrosoft ID プラットフォーム参照してください。
原因 4: 間違ったテナントにサインインしている
ユーザーがアプリケーションにアクセスしようとすると、アプリケーションへの直接リンクが送信されるか、 https://myapps.microsoft.com経由でアクセスしようとします。 いずれの場合も、ユーザーはアプリケーションにサインインするようにリダイレクトされます。 場合によっては、ユーザーが既にアクティブなセッションを持っていて、使用する個人用アカウントとは異なる個人用アカウントを使用している場合があります。 または、個人のゲスト アカウント (またはその逆) を使用することを意図しているにもかかわらず、組織アカウントを使用するセッションがあります。
このシナリオが問題であることを確認するには、エラー メッセージで User account 値と Identity provider 値を探します。 これらの値は予想される組み合わせと一致しますか? たとえば、ユーザーがホーム テナントではなく、自分の組織アカウントを使用してテナントにサインインしたとします。 または、ユーザーが既に招待されたものとは異なる個人用アカウントを使用して、live.com ID プロバイダーにサインインしましたか?
解決策: サインアウトしてから、別のブラウザーまたはプライベート ブラウザー セッションからもう一度サインインする
新しいプライベート ブラウザー セッションを開くか、別のブラウザーからアクセスするようにユーザーに指示します。 この場合、ユーザーはアクティブなセッションからサインアウトしてから、もう一度サインインを試みる必要があります。
原因 5: ゲスト ユーザーが招待されませんでした
サインインしようとしたゲスト ユーザーがテナントに招待されませんでした。
解決策: ゲスト ユーザーを招待する
ゲスト ユーザーを招待するには、「 Quickstart: Azure portal でディレクトリにゲスト ユーザーを追加する 」の手順に従っていることを確認します。
原因 6: アプリにユーザーの割り当てが必要
アプリケーションがユーザー割り当てを必要とするエンタープライズ アプリケーションの場合、ユーザーがアプリケーションへのアクセス権を割り当てられている許可されたユーザーの一覧にない場合、エラー AADSTS50020 が発生します。 エンタープライズ アプリケーションでユーザーの割り当てが必要かどうかを確認するには:
Azure ポータルでアプリケーション検索して選択します。
エンタープライズ アプリケーションを選択します。
サイドバーで Properties を選択します。
割り当て必須 オプションが Yes に設定されているかどうかを確認します。
解決策: ユーザーに個別に、またはグループの一部としてアクセス権を割り当てる
次のいずれかのオプションを使用して、ユーザーにアクセス権を割り当てます。
アプリケーションへのユーザー アクセス権を個別に割り当てるには、「 エンタープライズ アプリケーションにユーザー アカウントを割り当てるを参照してください。
割り当てられたグループまたは動的グループのメンバーであるユーザーを割り当てるには、「 アプリケーションへのアクセス権の管理を参照してください。
原因 7: 個人用アカウントのリソース所有者パスワード資格情報フローを使用しようとしました
ユーザーがリソース所有者パスワード資格情報 (ROPC) フローを個人用アカウントに使用しようとすると、エラー AADSTS50020が発生します。 Microsoft ID プラットフォームは、個人用アカウントではなく、Microsoft Entra テナント内でのみ ROPC をサポートします。
解決策: テナントまたは組織に固有のエンドポイントを使用する
テナント固有のエンドポイント (https://login.microsoftonline.com/<TenantIDOrName>) または組織のエンドポイントを使用します。 Microsoft Entra テナントに招待された個人アカウントでは、ROPC を使用できません。 詳細については、「Microsoft ID プラットフォームと 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
Note
MSOnline PowerShell モジュールは非推奨に設定されています。 PowerShell Core とも互換性がないため、次のコマンドを実行できるように、互換性のある PowerShell バージョンを使用していることを確認してください。
次のように、 Get-MsolUser PowerShell コマンドレットを実行して、ユーザーの作成日を確認します。
Get-MsolUser -SearchString user@contoso.com | Format-List whenCreated
次に、リソース テナント内のゲスト ユーザーの作成日と、ホーム テナント内のユーザー アカウントの作成日を確認します。 シナリオは、ホーム テナントのユーザー アカウントが作成される前にゲスト ユーザーが作成されたかどうかを確認します。
Note
Azure AD および MSOnline PowerShell モジュールは、2024 年 3 月 30 日の時点で非推奨となります。 詳細については、非推奨の最新情報を参照してください。 この日以降、これらのモジュールのサポートは、Microsoft Graph PowerShell SDK への移行支援とセキュリティ修正プログラムに限定されます。 非推奨になるモジュールは、2025 年 3 月 30 日まで引き続き機能します。
Microsoft Entra ID (旧称 Azure AD) を使用するには、Microsoft Graph PowerShell に移行することをお勧めします。 移行に関する一般的な質問については、「移行に関する FAQ」を参照してください。 ノート: バージョン 1.0.x の MSOnline では、2024 年 6 月 30 日以降に使用障害が発生する可能性があります。
検証オプション 2: リソース テナントのゲスト代替セキュリティ ID がホーム テナントのユーザーネット ID と異なるかどうかを確認する
Note
MSOnline PowerShell モジュールは非推奨に設定されています。 PowerShell Core とも互換性がないため、次のコマンドを実行できるように、互換性のある PowerShell バージョンを使用していることを確認してください。
ゲスト ユーザーが招待を受け入れると、ユーザーのLiveID属性 (ユーザーの一意のサインイン ID) がkey属性のAlternativeSecurityIds内に格納されます。 ユーザー アカウントが削除され、ホーム テナントに作成されたため、そのアカウントの NetID の値は、ホーム テナントのユーザーに対して変更されます。 次のように、ホーム テナント内のユーザー アカウントの NetID 値と、リソース テナント内のゲスト アカウントの AlternativeSecurityIds 内に格納されているキー値を比較します。
ホーム テナントで、
Get-MsolUserPowerShell コマンドレットを使用して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 でエンコードされた文字列を 16 進数の値に変換。
手順 1 と手順 3 の値を比較して、値が異なっていることを確認します。 ホーム テナント内のユーザー アカウントの
NetIDは、アカウントが削除されて再作成されたときに変更されました。
解決策: ゲスト ユーザー アカウントの引き換え状態をリセットする
リソース テナントのゲスト ユーザー アカウントの引き換え状態をリセットします。 その後、ゲスト アカウントを削除して再作成しなくても、ゲスト ユーザー オブジェクトを保持できます。 引き換えの状態は、Azure portal、Azure PowerShell、または Microsoft Graph API を使用してリセットできます。 手順については、「 ゲスト ユーザーの引き換え状態を設定するを参照してください。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。