MENU

AADSTS5000224でAzure/Entraポータルにサインインできない原因と対処法【テナント無効化とMFAエラー500121】

Azure

Azure ポータルや Entra ID に突然サインインできなくなり、「AADSTS5000224 テナントは無効化されました」と表示されると、テナントが消えたのでは…と不安になります。本記事では、実際にあった事例をもとに原因の整理と復旧・再発防止策を具体的に解説します。

目次

AADSTS5000224 とは？「テナントが無効化された」の正体

AADSTS5000224 は、Azure AD（現 Entra ID）のサインイン時に表示されるエラー コードの一つで、メッセージとしては次のような内容が表示されます。

  • 「アクセスしようとしているテナントは無効化され、利用できません」
  • 「The tenant is disabled and cannot be accessed」 など（英語環境の場合）

ここでポイントになるのは、メッセージに出ている「テナント」が、必ずしも自分が管理しているメイン テナントとは限らない、という点です。

Entra ID（旧 Azure AD）では、1 つのアカウントが複数のディレクトリ（テナント）に所属できます。特に、個人用 Microsoft アカウント（MSA）を使っている場合、次のような状態になることがあります。

  • 自分が管理しているテナント A（本番環境）
  • お客様やパートナーのテナント B に「ゲスト」として参加

このとき、テナント B が無効化・削除されていると、認証時に誤ってテナント B 側に飛ばされることで、AADSTS5000224 が出ることがあります。つまり、

「エラー画面に出ているテナント」≠「自分が管理しているメイン テナント」

というケースが十分にあり、「自分のテナントが消えた」「無効化された」と早合点してしまうと、状況を余計にこじらせかねません。

今回の事例の前提

この記事の元になっているケースでは、次のような状況が重なっていました。

  • ログインに使っているのは 個人用 Microsoft アカウント（MSA）
  • その MSA が、別の組織テナントにゲストとして参加していた
  • ゲスト先のテナントが無効化されていたか、アクセス出来ない状態だった
  • 認証要求がそのゲスト テナント側にリダイレクトされ、AADSTS5000224 が表示
  • 途中からは 500121（想定外の認証コード） が出て、MFA も通らなくなった

結果として、本人も他の全体管理者も Azure / Entra ポータルに入れず、テナント管理者の実質ロックアウト状態になっていました。

AADSTS5000224・500121 周辺の代表的なエラー

エラー コード代表的なメッセージ意味のイメージ
AADSTS5000224「テナントは無効化され利用できません」アクセスしようとしているそのテナント側が無効化・使用不可
AADSTS50020「ユーザーはこのテナントで承認されていません」アカウントがそのテナントに存在しない / 招待されていない
AADSTS500121「想定外の認証コード」など多要素認証コードが無効・不一致・期限切れなどで拒否された

このうち AADSTS5000224 は、「自分のテナントが無効化された」と誤解しやすい点が注意ポイントです。

根本原因：MSA が別ディレクトリのゲストになっていた

今回の事例で採用された結論は次の通りです。

  • メインのテナント自体は無効化されていなかった
  • MSA が別テナントに「ゲスト」として所属しており、そちらへ認証が飛んでいた
  • そのゲスト テナント側が利用不可だったため、AADSTS5000224 が表示されていた

つまり、

「誤ったテナントにサインインしようとしていて、そのテナントが無効だった」

という構図です。

なぜメイン テナントに入れなくなったのか

Entra / Azure ポータルでは、直近にアクセスしたディレクトリや、ブラウザーに残っているセッション情報をもとに、サインイン後に自動でテナントを選択することがあります。

今回の事例では、

  1. 以前、MSA でゲスト テナント B へアクセスした
  2. その情報がブラウザーに残っていた
  3. 再度ポータルへアクセスすると、自動的に B テナントに接続しようとする
  4. B テナントが無効化されているため、AADSTS5000224 が表示
  5. 「テナントが無効化された」とだけ見えてしまい、自分のテナント A が死んだように見えた

という挙動になっていました。

さらに追い打ちとして、MFA 設定の不整合により 500121 が発生し、MFA の再登録なしには先へ進めない状態になっていました。他の全体管理者も同じように MFA が通らない状態で、セルフサービスでの回復が難しい状況に陥っていた、というわけです。

すぐに試すべき対処：正しいテナントでサインインできるか確認する

同様の症状に遭遇した場合、真っ先に行いたいのは「本当に自分のテナントにサインインしようとしているか？」の確認です。以下の手順は、ブラウザーのキャッシュやゲスト テナントの影響を最小化しながら、正しいテナントでのサインインを強制するためのものです。

テナント指定 URL からサインインする

通常、Azure ポータルには https://portal.azure.com/ などの URL からアクセスしますが、テナントを明示してアクセスすることで、別ディレクトリへの誤誘導を避けることができます。

  • https://ms.portal.azure.com/<テナント ID>
  • https://ms.portal.azure.com/<テナント初期ドメイン> （例：contoso.onmicrosoft.com）

あるいは、クエリ文字列を使ってテナントを指定することもできます。

  • https://portal.azure.com/?tenant=<テナント ID>
  • https://portal.azure.com/?tenant=<テナント初期ドメイン>

このようにテナントを指定した URL からアクセスすることで、ブラウザーに残っているゲスト テナントの情報よりも、URL で指定したテナントが優先されるため、誤ったディレクトリに入ってしまうリスクを減らせます。

必ずシークレット ウィンドウで実行する

既存のログイン状態が残っているブラウザーでは、どうしても過去のセッションや Cookie の影響を受けます。必ず次のようなモードで試してください。

  • Chrome：シークレット ウィンドウ
  • Edge：InPrivate ウィンドウ
  • Firefox：プライベート ウィンドウ

新しいシークレット ウィンドウを開き、上記のテナント指定 URLを直接入力するのがポイントです。

サインイン時に組織（ディレクトリ）を慎重に選ぶ

サインインが進み、組織選択画面が出る場合は、以下の点に注意します。

  • 自分が管理しているメインのテナント名・初期ドメインを選ぶ
  • 普段あまり使っていないゲスト先の組織名をうっかり選ばない
  • 個人用アカウント（MSA）と職場または学校アカウントが混在している場合、どちらでログインしているかを必ず確認

状況別の確認ポイントをまとめると、次のようになります。

状況確認することポイント
MSA でログインしているゲスト参加しているテナントが選ばれていないか組織名やドメイン名をよく見る
職場 / 学校アカウントでログインディレクトリ切替で別テナントに飛んでいないかポータル右上のアカウントメニューから確認可能
サインイン前にエラーが出るテナント指定 URL を使っているかブラウザーのセッションを疑う

ここまでの手順で、正しいテナントを指定してもなお AADSTS5000224 が出る場合は、そのテナント自体が本当に利用不可な可能性が高くなります。その時点で、素早く Microsoft サポートへのエスカレーションを検討しましょう。

MFA エラー 500121 が出る場合は、サポートでの再登録を前提に動く

今回の事例では、途中から 500121（想定外の認証コード） が出て、MFA のコードをどう入力しても通らない状態になっていました。このエラーは、多くの場合次のような状況で発生します。

  • 認証アプリの登録情報がサーバー側と食い違っている
  • 端末の時刻ずれなどでワンタイムパスワードが無効になる
  • 古いデバイスの認証情報が残っていて、新旧の情報が混在している

一般ユーザーであれば、MFA の再登録を管理者に依頼して解決できますが、今回はその管理者自身がロックアウトされているという点がポイントです。Entra ID では、

  • 管理者自身は自分の MFA をリセットできない
  • 他の全体管理者がいればその人がリセットできるが、今回は全員ロックアウト

という状況だったため、セルフサービスではどうにもならない状態でした。このようなケースでは、早めに腹を括って、

「Microsoft サポートに MFA 再登録（リセット）を依頼する」

という方向で動いたほうが、トータルのダウンタイムを短くできます。

Microsoft のデータ保護チームへのエスカレーション

今回の事例では、サポート チケットを通じて Microsoft のデータ保護チームにエスカレーションされ、最終的に次のような対応方針で解決しました。

  • テナントやアカウントの所有者確認
  • 対象管理者アカウントの MFA 情報のリセット
  • 再度 MFA を登録し直すためのサインイン手順の案内

サポートに依頼する際は、「何に困っているか」をできるだけ具体的に伝えることが重要です。特に、次のキーワードははっきりと明示しましょう。

  • 「ゲスト所属の別テナントにリダイレクトされている疑いがある」
  • 「全体管理者が MFA でロックアウトされており、再登録を行いたい」

サポートに伝えるべき情報

サポートを効率よく動かすためには、最初の問い合わせの段階で、必要な情報を整理して伝えることが重要です。代表的な項目を整理すると次の通りです。

項目例備考
テナントの初期ドメインcontoso.onmicrosoft.com分かる場合は最優先で伝える
テナント IDxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx不明な場合は後述の方法で調査
対象アカウントの UPN[email protected]全体管理者（グローバル管理者）のアカウント
用途・業務影響本番環境 / 社内全ユーザーに影響 など優先度判断の材料になる
エラー コードAADSTS5000224, 500121 など複数ある場合はすべて記載する
Trace ID / Correlation IDエラー画面右下などに表示必ずタイムスタンプとセットで伝える
Timestamp2025-12-11T02:34:56Z などタイムゾーン込みで記録しておく

特に、Trace ID / Correlation ID / Timestamp は、サポート側がログを追跡する際の「座標」のようなものです。エラー画面が表示されたら、スクリーンショットを撮るか、文字列をコピーして、問い合わせ時に添付できるようにしておきましょう。

個人情報（PII）や機密情報を含む場合は、必ず Microsoft が案内する安全なチャネル（ポータルのアップロード機能など）を通じて共有し、メール本文にむやみに貼り付けないようにしてください。

テナント ID が分からないときの取得ヒント

サポートに問い合わせるうえで「テナント ID を教えてください」と言われることはよくあります。しかし、管理者が全員ロックアウトしているような状況では、Azure ポータルに入って確認することも難しいケースが多いでしょう。以下に、テナント ID を探すためのヒントをまとめます。

過去のメールを検索する

Azure / Entra ID を初めてセットアップしたとき、Microsoft から次のようなメールが届いているはずです。

  • 初回登録完了のお知らせ
  • カスタム ドメインの確認メール
  • サブスクリプションの請求関連メール

これらのメールには、テナントの初期ドメイン（xxxxx.onmicrosoft.com）やサブスクリプション ID が記載されていることが多く、間接的にテナントを特定する手掛かりになります。メール クライアントで、

  • onmicrosoft.com
  • Azure
  • Microsoft Entra

といったキーワードで検索してみてください。

スクリプト・CLI の履歴を確認する

普段 PowerShell や Azure CLI を使って管理している場合、次のような場所にテナント ID が残っていることがあります。

  • 過去に実行したスクリプト ファイル（.ps1 や .sh）
  • リポジトリ（Git など）の構成ファイル
  • Azure CLI の設定（az account show の出力を残していればそこに記載）

スクリプトや設定ファイルの中で、

  • tenant
  • tenantId
  • directory

といった文字列を検索してみると、過去に明示的に指定した GUID が見つかることがあります。

カスタム ドメインから OpenID 構成をたどる

もし、contoso.com のようなカスタム ドメイン名だけは覚えている、という場合は、そのドメインを使って OpenID Connect の構成ドキュメントを参照する方法があります。

ブラウザーで、次のような URL にアクセスします。

  • https://login.microsoftonline.com/<カスタムドメイン>/v2.0/.well-known/openid-configuration

たとえば、カスタム ドメインが contoso.com なら、

あわせて読みたい

にアクセスします。すると JSON 形式の設定情報が表示され、その中の issuer に次のような値が含まれているはずです。

"issuer": "https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0"

この xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx がテナント ID です。企業のポリシー上、ブラウザーから直接こうした情報にアクセスしてよいかどうかは事前に確認し、取得した ID をどこまで共有するかも慎重に判断してください。

同じテナントの他ユーザーに確認してもらう

もし自分以外に、まだサインインできるユーザーが残っている場合（一般ユーザーや別の管理者アカウントなど）、その人に Entra 管理センターでテナント情報を確認してもらうのが最も確実です。

  • Entra 管理センター（https://entra.microsoft.com/）にサインイン
  • 左メニューの「ID」→「概要」などからテナント ID を確認
  • 安全な方法で管理者に共有してもらう

共有の際は、メールではなく社内のセキュアなチャットやパスワード マネージャー等を利用し、スクリーンショットの扱いには十分注意しましょう。

方法必要な前提メリット / 注意点
過去のメールから探す登録時のメールを削除していない最も手軽だが、情報が古い場合もある
スクリプト / CLI の履歴普段からスクリプト管理している複数テナントを扱っている場合は識別に注意
OpenID 構成から issuer を確認カスタム ドメイン名が分かるブラウザーで直接確認可能だが、ポリシー順守が必須
別ユーザーに確認してもらう同じテナントでサインイン可能な人がいる最も確実。共有方法だけ慎重に

再発防止のベストプラクティス

今回のケースでは最終的に、Microsoft サポートの支援で MFA の再登録とアクセス復旧に成功しました。しかし、同じことが再び起きないように、テナント運用としての設計を見直すことが非常に重要です。代表的な対策をいくつか紹介します。

緊急用（ブレークグラス）管理者アカウントを最低 2 つ用意する

「ブレークグラス アカウント」とは、通常は使わないが、緊急時にのみ使用するための管理者アカウントです。代表的な設計例は次の通りです。

  • テナントごとに最低 2 つのブレークグラス アカウントを作成
  • 全体管理者（グローバル管理者）ロールを付与
  • 日常運用で使うアカウントとは完全に分離（メール受信用にも使わない）
  • 条件付きアクセス（CA）からは除外し、MFA の強制も避ける（代わりに超長く複雑なパスワード）
  • サインインが発生したら即座にアラートが飛ぶよう監査・モニタリングを設定
  • 資格情報はオフライン（耐火金庫等）に保管し、アクセスできる人物・手順を明文化

「MFA をかけないアカウントなんて危険では？」と感じるかもしれませんが、ブレークグラス アカウントは、

  • 普段は絶対に使わない
  • 使うときは必ず複数人で確認する

といった運用でリスクを抑えながら、「全管理者が MFA や条件付きアクセスでロックアウトされる」事態を避けるための最後の砦として設計するのが一般的です。

管理者用アカウントを分離し、個人アカウントと混在させない

今回の原因の一つは、MSA が複数テナントのゲストとして使われていた点にあります。これを避けるには、

  • 日常利用する個人用アカウント（MSA）
  • 自テナントを管理するための管理者アカウント（組織アカウント）

を明確に分離し、管理者アカウントではむやみに外部テナントに参加しないようにするのが理想です。どうしても外部テナントへの参加が必要な場合は、別の専用アカウントを用意することも検討しましょう。

テナント情報の台帳化

障害時に「誰が何を知っているか」が属人化していると、復旧のスピードが大きく低下します。次のような情報を、社内で共有可能な台帳としてまとめておくと安心です。

  • テナント ID
  • テナントの初期ドメイン（xxxxx.onmicrosoft.com）
  • カスタム ドメインとその用途（本番 / 検証 / 開発）
  • サブスクリプション ID と請求担当者の連絡先
  • 全体管理者・特権ロール管理者などのアカウント一覧
  • ブレークグラス アカウントの存在・保管場所・利用手順
  • Microsoft サポートへの問い合わせ経路と契約情報

ゲスト所属の棚卸しと MFA / 回復手段の二重化

管理者アカウントがどのテナントにゲスト参加しているかを定期的に見直し、不要なゲスト所属は整理しましょう。また、MFA の観点では、次のような「二重化」を意識することが重要です。

  • 認証アプリを複数デバイスに登録（スマホ + タブレットなど）
  • 電話番号（SMS / 音声）やハードウェア トークンなど、別経路の要素も登録
  • パスワード リセット用のメール アドレスを最新に保つ
対策実施例期待できる効果
ブレークグラス アカウント2 つの非常用全体管理者アカウントを作成し、CA から除外全管理者がロックアウトする事態を防ぐ最後の砦
管理者アカウントの分離日常用 MSA と管理用アカウントを分けるゲスト所属による予期しないエラーを低減
テナント情報の台帳化テナント ID やサブスクリプション ID を共有ドキュメントで管理障害時の情報収集時間を大幅短縮
MFA の二重化認証アプリ + 電話番号 + ハードウェア トークン端末紛失時やアプリ故障時にも認証継続が可能

よくある勘違いとアンチパターン

最後に、AADSTS5000224 や MFA ロックアウトに関連して、よく見られる勘違いやアンチパターンを整理しておきます。

  • 「AADSTS5000224＝自分のテナントが削除された」
    実際には「アクセスしようとしているテナント」が無効化されているだけで、自分のメイン テナントが健在なケースも多くあります。まずは、どのテナントにサインインしようとしているかを確認しましょう。
  • 「管理者は自分一人だから、MFA のトラブルは自分で何とかできる」
    管理者自身は自分の MFA をリセットできません。自分しか管理者がいないテナントで MFA を強制している場合、今回のようなロックアウトリスクが非常に高くなります。
  • 「Authenticator アプリはスマホ 1 台に入っていれば十分」
    端末紛失・故障・機種変更などで認証情報が失われることを想定し、複数デバイスや別経路（電話・ハードウェア トークン等）を必ず用意しましょう。
  • 「管理者アカウントで何でもやる」
    日常的なメール・ブラウジング・外部サービスへのサインアップなどを管理者アカウントで行うと、ゲスト所属やフィッシングなどのリスクも増大します。管理者作業専用のアカウントを用意し、用途を分けることが重要です。

まとめ：エラー メッセージだけで判断せず、サインイン フローを分解して考える

本記事で取り上げたケースでは、表面的には「AADSTS5000224 テナントが無効化された」「MFA で 500121」といったエラーが出ていたものの、実際の根本原因は、

  • MSA が別テナントにゲスト参加していたこと
  • そのゲスト テナントが利用不可で、そちらに認証が流れていたこと

にありました。エラー メッセージだけを見ると、自分のテナントが消えてしまったように感じますが、サインイン フローを冷静に分解すれば、

  • 「どのテナントに対して」サインインしようとしているのか
  • 「どのアカウントで」認証を行っているのか（MSA / 組織アカウント）

を切り分けて考えることができ、原因に近づきやすくなります。

そして、管理者ロックアウトのようなクリティカルな状況では、無理に自力解決を試みるよりも、早期に Microsoft サポートにエスカレーションし、必要な情報（テナント ID、Trace ID、Correlation ID など）を揃えて相談することが、結果的に復旧の近道になります。

復旧が完了した後は、

  • ブレークグラス管理者アカウントの整備
  • テナント情報の台帳化
  • 管理者アカウントの分離とゲスト所属の見直し
  • MFA と回復手段の二重化

といった再発防止策を着実に実装し、二度と同じ種類のトラブルで業務を止めないようにしておきましょう。

Azure
エラーコード Azure MFA Entra ID テナント

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次