エラー 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 Services テナントに接続されます。 既定のテナント内には、アクションを実行するためのリンクされたディレクトリはありません。 この動作は仕様です。
以前のエクスペリエンスでは、ディレクトリ (例: UserNamehotmail735.onmicrosoft.com) が作成され、個人用アカウントにリンクされ、ディレクトリにユーザー アカウントを作成するなどのアクションを実行できます。 動作が変更されました。
解決策: 新しいテナントを使用して Azure アカウントをCreateする
ディレクトリを作成する場合は、Azure アカウントと新しいテナントを作成する必要があります。
- を参照し https://azure.microsoft.com/en-us/free/、[ 無料で開始 ] を選択します。
- 手順に従って Azure アカウントを作成します。
- テナントは Azure アカウントと共に生成され、グローバル管理者として自動的に指定されます。 これにより、このテナント内のすべてのオプションへのフル アクセスが許可されます。
原因 2: サポートされていないアカウントの種類 (マルチテナント アカウントと個人用アカウント) を使用しました
アプリの登録がシングルテナント アカウントの種類に設定されている場合、他のディレクトリまたは ID プロバイダーのユーザーは、そのアプリケーションにサインインできません。
解決策: アプリ登録マニフェストのサインイン対象ユーザー設定を変更する
アプリの登録がシングルテナント アカウントの種類ではないことを確認するには、次の手順を実行します。
Azure portalで、[アプリの登録] を検索して選択します。
アプリ登録の名前を選択します。
サイドバーで、[マニフェスト] を選択 します。
JSON コードで、 signInAudience 設定を見つけます。
設定に次のいずれかの値が含まれているかどうかを確認します。
- AzureADandPersonalMicrosoftAccount
- AzureADMultipleOrgs
- PersonalMicrosoftAccount
signInAudience 設定にこれらの値のいずれかが含まれていない場合は、正しいアカウントの種類を選択してアプリの登録を再作成します。 現在、マニフェストで signInAudience を変更することはできません。
アプリケーションを登録する方法の詳細については、「クイック スタート: アプリケーションをMicrosoft ID プラットフォームに登録する」を参照してください。
原因 3: 間違ったエンドポイント (個人用アカウントとorganization アカウント) を使用しました
アプリ登録のサポートされているアカウントの種類が次のいずれかの値に設定されている場合、認証呼び出しは選択した URL をターゲットにする必要があります。
任意の組織のディレクトリ内のアカウント (任意のMicrosoft Entra ディレクトリ - Multitenant)
任意の組織ディレクトリ内のアカウント (任意の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アクセスしようとします。 どちらの場合も、ユーザーはアプリケーションにサインインするようにリダイレクトされます。 場合によっては、ユーザーが既にアクティブなセッションを持っていて、使用する個人用アカウントとは異なる個人用アカウントを使用している可能性があります。 または、個人のゲスト アカウント (またはその逆) を使用することを意図しているにもかかわらず、organization アカウントを使用するセッションがあります。
このシナリオが問題であることを確認するには、エラー メッセージで と Identity provider のUser account値を探します。 これらの値は、予想される組み合わせと一致しますか? たとえば、ユーザーがホーム テナントではなくテナントにorganization アカウントを使用してサインインしたとします。 または、ユーザーが既にlive.com招待されたものとは異なる個人用アカウントを使用して ID プロバイダーにサインインしましたか?
解決策: サインアウトしてから、別のブラウザーまたはプライベート ブラウザー セッションから再度サインインする
新しいプライベート ブラウザー セッションを開くか、別のブラウザーからアクセスするようにユーザーに指示します。 この場合、ユーザーはアクティブなセッションからサインアウトしてから、もう一度サインインする必要があります。
原因 5: ゲスト ユーザーが招待されませんでした
サインインしようとしたゲスト ユーザーがテナントに招待されませんでした。
解決策: ゲスト ユーザーを招待する
「クイック スタート: ゲスト ユーザーをAzure portalのディレクトリに追加する」の手順に従って、ゲスト ユーザーを招待してください。
原因 6: アプリにユーザーの割り当てが必要
アプリケーションがユーザー割り当てを必要とするエンタープライズ アプリケーションの場合、アプリケーションへのアクセス権が割り当てられている許可されたユーザーの一覧にユーザーがいない場合、エラー AADSTS50020 が発生します。 エンタープライズ アプリケーションでユーザー割り当てが必要かどうかをチェックするには:
Azure portalで、エンタープライズ アプリケーションを検索して選択します。
エンタープライズ アプリケーションを選択します。
サイドバーで、[プロパティ] を選択 します。
[ 割り当て必須] オプションが [はい] に設定されているかどうかを確認します。
解決策: ユーザーに個別に、またはグループの一部としてアクセス権を割り当てる
ユーザーにアクセス権を割り当てるには、次のいずれかのオプションを使用します。
ユーザー アクセスをアプリケーションに個別に割り当てるには、「 エンタープライズ アプリケーションにユーザー アカウントを割り当てる」を参照してください。
割り当てられたグループまたは動的グループのメンバーである場合にユーザーを割り当てるには、「 アプリケーションへのアクセスを管理する」を参照してください。
原因 7: 個人アカウントにリソース所有者のパスワード資格情報フローを使用しようとしました
ユーザーが個人アカウントにリソース所有者パスワード資格情報 (ROPC) フローを使用しようとすると、エラー AADSTS50020 が発生します。 Microsoft ID プラットフォームでは、個人アカウントではなく、Microsoft Entra テナント内でのみ ROPC がサポートされます。
解決策: テナントまたはorganizationに固有のエンドポイントを使用する
テナント固有のエンドポイント (https://login.microsoftonline.com/<TenantIDOrName>) またはorganizationのエンドポイントを使用します。 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
注:
MSOnline PowerShell モジュールは非推奨に設定されています。 PowerShell Core とも互換性がないため、次のコマンドを実行できるように、互換性のある PowerShell バージョンを使用していることを確認してください。
Get-MsolUser PowerShell コマンドレットを実行して、次のようにユーザーの作成日を確認します。
Get-MsolUser -SearchString user@contoso.com | Format-List whenCreated
次に、リソース テナント内のゲスト ユーザーの作成日を、ホーム テナント内のユーザー アカウントの作成日に対してチェックします。 このシナリオでは、ホーム テナントのユーザー アカウントが作成される前にゲスト ユーザーが作成されたかどうかが確認されます。
注:
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 と異なるかどうかを確認する
注:
MSOnline PowerShell モジュールは非推奨に設定されています。 PowerShell Core とも互換性がないため、次のコマンドを実行できるように、互換性のある PowerShell バージョンを使用していることを確認してください。
ゲスト ユーザーが招待を受け入れると、ユーザーの属性 (ユーザーのLiveID一意のサインイン ID) が 属性内にkey格納されますAlternativeSecurityIds。 ユーザー アカウントが削除され、ホーム テナントに作成されたため、 NetID ホーム テナント内のユーザーのアカウントの値が変更されます。 NetID次のように、ホーム テナント内のユーザー アカウントの値を、リソース テナントのゲスト アカウント内AlternativeSecurityIdsに格納されているキー値と比較します。
ホーム テナントで、PowerShell コマンドレットを使用して属性の
LiveID値をGet-MsolUser取得します。Get-MsolUser -SearchString tuser1 | Select-Object -ExpandProperty LiveIDリソース テナントで、 内
AlternativeSecurityIdsの属性の値をkeybase64 でエンコードされた文字列に変換します。[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 フィードバック コミュニティに製品フィードバックを送信することもできます。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示