「Azure Portal にサインインできていたのに、ある日突然 6 桁コードを求められ、手元の Microsoft Authenticator は 8 桁コードしか出ない」「Error Code 500121 が出てポータルに入れない」という相談は、実はテナント ロックアウトの典型パターンです。本記事では、唯一のグローバル管理者が締め出されてしまった場合の原因と復旧手順、再発防止のベストプラクティスを、運用目線で詳しく解説します。
Azure Portal にサインインできない典型パターン
まずは、今回のようなトラブルでよく見られる現象を整理します。
- これまで問題なく Azure Portal にサインインできていた。
- 突然、サインインの途中で 「6 桁の確認コード」 が求められるようになった。
- しかし Microsoft Authenticator アプリには 8 桁のワンタイム パスコード しか表示されない。
- サインインに使っているユーザーは 唯一のグローバル管理者。
- ユーザー設定画面では「ユーザーごとの MFA」は 無効 に見える。
- 一方で、パスワードレス サインイン（プッシュ通知） は有効化している。
- Azure mobile app にはサインインできるのに、ブラウザーの Azure Portal では失敗する。
- Authenticator アプリ側では「アカウントを再追加してください」といったエラーが出ることもある。
これらが組み合わさると、「どこが壊れているのか」が非常に分かりにくくなります。現象を表形式で整理すると次のようになります。
| 現象 | 具体的な状態 | ポイント |
|---|---|---|
| 6 桁コードの要求 | Azure Portal が TOTP 形式の 6 桁コード入力画面を表示 | テナント側は「6 桁 TOTP」を期待している |
| Authenticator は 8 桁コード | アプリに 8 桁の数字、または番号一致用のコードだけが表示 | パスワードレスや別種の認証方法用のコード |
| Azure mobile app ではサインイン可能 | スマホ アプリからはリソースが見える | テナント自体は生きており、アカウントも削除されていない |
| 唯一のグローバル管理者 | 他に管理者ロールを持ったユーザーがいない | 自力で MFA/Passwordless をリセットできない |
この状態は、単なる「MFA 設定の勘違い」ではなく、テナント ロックアウト と呼ばれる深刻な状態に発展している可能性が高いです。
6 桁コード vs 8 桁コードが合わない理由
「なぜ 6 桁を求められるのに、Authenticator は 8 桁なのか？」という疑問の背景には、認証方式の違いがあります。
Azure Portal が要求しているのは「6 桁 TOTP」
Azure Portal の MFA 入力画面で、単に「確認コード 6 桁を入力してください」と表示される場合、多くは OATH TOTP（時間ベースのワンタイム パスワード）方式の 6 桁コード を期待しています。
- 一定時間（通常 30 秒）ごとに変わる 6 桁のコード。
- Authenticator アプリ上の「<組織名> – <ユーザー名>」に 6 桁で表示されるタイプ。
- テナント側に登録された「認証方法」とユーザーのデバイス側のシークレットが一致している必要がある。
ところが、テナント設定や Authenticator の登録状況次第では、この 6 桁 TOTP が有効になっていない、あるいは Authenticator から削除されているにもかかわらず、テナント側は「あるはず」と認識してしまうことがあります。
Authenticator の 8 桁コードは何者か
対して、Authenticator が提示する 8 桁のコード は、多くの場合、次のような用途のコードです。
- パスワードレス/プッシュ通知と組み合わせた 番号一致 のためのコード。
- 別のサービス（他社サービスや別テナント）が発行している TOTP の桁数仕様によるもの。
つまり、Azure Portal のサインイン画面が求めている認証方法と、Authenticator アプリ上で表示している認証方法が食い違っているわけです。
イメージを表にすると次のようになります。
| 項目 | 6 桁コード | 8 桁コード |
|---|---|---|
| 主な用途 | TOTP 形式の MFA（追加のセキュリティ確認） | パスワードレスの番号一致や一部サービス向け TOTP |
| どこに表示されるか | Authenticator の「ワンタイム パスコード」欄 | パスワードレス通知の画面や別アカウント欄 |
| Azure Portal サインイン画面との対応 | 6 桁コード入力欄と一致 | 6 桁入力欄には使えない |
| 今回のトラブルでの挙動 | そもそも表示されない or 無効になっている | こちらだけが表示されるため、桁数が合わない |
この「期待している認証方法」と「実際に使える認証方法」のズレが、サインイン失敗の根本原因です。
テナント ロックアウトとは何か
今回のように、唯一のグローバル管理者がサインインできない状態は、Microsoft では一般的に テナント ロックアウト（Global Admin Lockout） として扱われます。
テナント ロックアウトが起きる典型パターン
- ユーザーごとの MFA（レガシー MFA）から、Conditional Access ベースの Azure AD MFA に移行した。
- パスワードレス サインインや FIDO2 セキュリティキーなどを追加したが、古い認証方法を適切に整理していない。
- Authenticator アプリを再インストール・機種変更した際、クラウド バックアップからの復元だけで済ませた（再登録をしていない）。
- MFA 設定の「無効化」やライセンス変更のタイミングで、テナント側に古い情報が残ったままになった。
- 唯一のグローバル管理者が、自分のアカウントだけで検証を繰り返し、最終的にサインイン不可になった。
特に危険なのは、グローバル管理者が 1 アカウントしか存在しないテナントです。このアカウントでパスワードレスや MFA 設定を試行錯誤しているうちに、気づかないうちに「どの認証方法でもサインインできない」状態に陥ることがあります。
テナント ロックアウトが起きたときの挙動
- パスワード自体は正しいのに、MFA やパスワードレスのステップで止まる。
- サインイン時に「アカウントが見つかりません」「このアカウントは多要素認証を完了できません」などのエラーが表示される。
- サインイン ログ上は 強制的な MFA 要求 が残っており、他の方法に切り替えられない。
このような状態になってしまうと、テナントの内部から設定を直すことができません。ここが非常に重要なポイントです。
なぜ唯一のグローバル管理者は自力復旧できないのか
「MFA が壊れたなら MFA を解除すればいい」と考えがちですが、唯一のグローバル管理者がサインインできない状態では、そもそも Azure Portal に入れません。そのため、次のような操作が行えなくなります。
- 自分自身の MFA を「再登録が必要」にする。
- 自分のサインイン方法（Authenticator、電話、メールなど）をポータル側から削除する。
- テナントの MFA ポリシーや Conditional Access の設定を変更する。
また、MFA の構成情報は、セキュリティ上の理由から強く保護されており、「本人がサインインしている」前提で変更する設計になっています。唯一のグローバル管理者がサインインできない状態では、その前提が崩れているため、自力で復旧できないのです。
ここで必要になるのが、Microsoft サポートによるテナント ロックアウト対応です。
Microsoft サポートに依頼して復旧する手順
唯一のグローバル管理者がロックアウトされている場合の基本方針はシンプルです。
「テナント ロックアウトとして Microsoft サポートに依頼し、MFA/Passwordless 設定を一時的に無効化してもらう」
ここからは、実務で使えるレベルの具体的な流れを整理します。
ステップ 1：サポート チケットを発行する
まず、Microsoft サポートに対して、次のような内容を伝えます。
- 対象テナントの情報
- テナント名（例：contoso.onmicrosoft.com）
- 問題が発生しているユーザー UPN（例：[email protected]）
- 現象の概要
- Azure Portal にサインインしようとすると 6 桁コードが要求される。
- Authenticator には 8 桁コード（またはプッシュ通知）しか表示されず、6 桁コードを入力できない。
- 当該ユーザーが唯一のグローバル管理者である。
- できれば「テナント ロックアウト（Global Admin Lockout）だと考えている」ことを明示する。
チケットの分類としては、一般に データ保護 (Data Protection) 関連のチームが担当するケースが多く、本人確認や所有権の確認が行われます。
ステップ 2：身元確認とテナント所有権の確認
セキュリティ上、Microsoft 側は「なりすましの攻撃者ではないか」を厳しく確認します。代表的には次のような情報が求められます。
- 組織の正式名称と住所。
- 契約しているサブスクリプション情報（契約 ID、請求先情報など）。
- 請求書に記載されている情報や支払いに関する情報。
- 過去のサポート チケットの情報。
これらは社内の経理担当や情報システム部門などに確認が必要となることも多く、事前にどこに何が保管されているかを把握しておくとスムーズです。
ステップ 3：MFA / Passwordless 設定の一時無効化を依頼
テナントの所有が確認できると、Microsoft 側で次のような対応を行ってもらえます。
- 問題のユーザーに対して、MFA を一時的に無効化する。
- パスワードレス サインインの登録情報を削除する。
- サインインに必要な条件を一時的に緩和する（特定ユーザーのみ）。
この対応によって、パスワードのみ、あるいは最低限の検証で Azure Portal にサインインできる状態を作ってもらうことができます。
ステップ 4：ポータルにサインインし、設定を整える
サポート側の操作によってサインイン可能になったら、すぐに次の作業を進めます。
- パスワードを強力なものに変更し、社内に安全な保管方法を定める。
- 別のグローバル管理者アカウントを最低 1〜2 件作成する。
- 後述の 緊急アクセス用アカウント（ブレークグラス アカウント） を作成する。
- 自分のアカウントの MFA・パスワードレス設定を一度リセットし、Authenticator への再登録を行う。
- Conditional Access やセキュリティのポリシーを確認し、「唯一のグローバル管理者にだけ過度な制約がかかっていないか」をチェックする。
この「復旧後の初期作業」が甘いと、再び同じロックアウトに陥る危険があります。後述のベストプラクティスも合わせて確認しておきましょう。
復旧ステップの整理
| 段階 | 担当 | 実施内容 | ポイント |
|---|---|---|---|
| ステップ 1 | 組織側 | サポート チケット発行（テナント ロックアウトとして報告） | 現象と唯一のグローバル管理者であることを明確に伝える |
| ステップ 2 | 組織 & Microsoft | 身元・テナント所有権の確認 | 契約情報・請求情報などを準備しておく |
| ステップ 3 | Microsoft | MFA / Passwordless 設定を一時的に無効化 | 対象ユーザーを限定してもらう |
| ステップ 4 | 組織側 | サインイン後の再設定（管理者追加・ブレークグラス・MFA 再登録） | ここで再発防止策まで一気に行う |
サインイン復旧後に必ずやるべき再発防止策
ロックアウトから復旧したら、「同じ事故を二度と起こさない仕組み」を整えることが何より大切です。具体的な対策を順番に見ていきます。
複数のグローバル管理者アカウントを用意する
Microsoft は、グローバル管理者は最低 2 名以上 とすることを強く推奨しています。現実には、次のような運用が望ましいです。
- 日常運用用の管理者アカウント：実際に作業する担当者が使用。
- バックアップ用の管理者アカウント：普段はサインインせず、緊急時だけ利用。
どちらのアカウントも、個人用メールアドレスではなく、組織として管理できるメールを紐づけておくと、担当者変更の際にスムーズです。
緊急アクセス用アカウント（ブレークグラス アカウント）を作成する
テナント ロックアウト対策として特に重要なのが、ブレークグラス アカウントの用意です。
- MFA をあえて有効化しない、または制限ポリシーから除外したアカウント。
- 非常に強力で長いパスワードを設定し、オフラインで安全に保管する。
- Conditional Access のルールから除外し、緊急時にだけ使えるようにする。
- 日常ではサインインせず、利用履歴があれば「何かあった」と気づけるように監査する。
このアカウントがあるだけで、今回のような「唯一の管理者が締め出される」事故からの復旧が大幅に簡単になります。
複数の MFA 手段を登録しておく
Authenticator だけに依存すると、スマホの故障やアプリの再インストールで簡単に詰んでしまいます。次のように、複数種類の MFA を組み合わせておくと安全です。
- Authenticator アプリ（プッシュ通知 + パスワードレス）。
- Authenticator アプリの 6 桁 TOTP（ワンタイム パスコード）。
- FIDO2 セキュリティ キー。
- 電話番号（SMS または音声通話）による確認コード。
- 別端末・別ブラウザーによるサインイン方法。
特にグローバル管理者やブレークグラス以外の重要アカウントでは、最低 2 種類は登録しておくことをおすすめします。
おすすめの設定パターン例
| 対象アカウント | MFA 設定 | 備考 |
|---|---|---|
| 通常のグローバル管理者 | Authenticator（プッシュ + 6 桁 TOTP）+ FIDO2 キー + 電話番号 | 少なくとも 2 種類以上の認証方法を登録 |
| バックアップ管理者 | Authenticator（6 桁 TOTP）+ FIDO2 キー | 普段はサインインせず、緊急時に使用 |
| ブレークグラス アカウント | MFA 無効 or ポリシー除外 + 強力パスワード | 厳格な運用ルールと監査が必須 |
Authenticator アプリ再登録時の注意点
復旧後に Authenticator を再登録する際は、次のポイントを必ず確認してください。
- テナント上の「サインイン方法」画面から、古い Authenticator の登録を削除してから新規登録する。
- スマホの日時設定が「自動」に設定されていることを確認し、数分単位の時刻ズレもない状態にする（TOTP 失敗の原因になる）。
- 同じアカウントを複数端末の Authenticator に登録する場合、それぞれ正しく認識されているかサインイン テストを行う。
Error Code 500121 でサインインできない場合
今回の現象に関連してよく報告されるのが、次のエラーです。
Error finding an account to complete multi-factor authentication (エラー コード 500121)
このエラーは、主に以下のような状況で発生します。
- MFA が必須のサインイン フローなのに、MFA に利用できる有効な認証方法が見つからない。
- Authenticator アプリ側に登録されているデータが壊れている、またはテナント側情報と紐付いていない。
- 「このアカウントは MFA 登録済み」とテナントが認識しているにもかかわらず、実際には登録が存在しない。
ユーザー自身で試せる対処手順
まだ別の管理者が存在する、あるいは自身が完全にロックアウトされていない場合、次の手順を試すことで解消するケースがあります。
- Authenticator から該当アカウントを削除する。
- Microsoft アカウント / 職場または学校アカウントをアプリからいったん削除。
- テナント側の「サインイン方法」画面でも、Authenticator の登録を削除してもらう。
- Authenticator にアカウントを再追加する。
- ポータル上の MFA 設定画面から QR コードを再表示し、Authenticator で読み取る。
- 6 桁 TOTP とプッシュ通知の両方が正しく動作するかテストする。
- 複数の認証方法を事前登録する。
- Authenticator だけでなく、電話番号や FIDO2 キーも追加する。
- ブラウザーからのサインイン → MFA 再登録 → サインイン テストという流れで確認する。
それでも解決しない場合は、本記事前半と同様に 管理者、もしくは Microsoft サポートに MFA のリセットを依頼する必要があります。
唯一の管理者で 500121 が出る場合
もし 500121 エラーが出ているユーザーが 唯一のグローバル管理者であれば、つまり今回のケースそのものです。この場合はやはり自力復旧が難しく、テナント ロックアウトとしてサポートにエスカレーションすることが重要です。
運用者のためのチェックリスト
最後に、今回のようなトラブルを避けるために、日常運用でチェックしておきたいポイントをチェックリスト形式でまとめます。
テナント設計・アカウント設計のチェック
- グローバル管理者は 2 アカウント以上存在するか。
- ブレークグラス アカウントが作成されており、強力なパスワード・監査設定が行われているか。
- グローバル管理者が日常業務で使うアカウントと、バックアップ用アカウントが分離されているか。
MFA / パスワードレス設定のチェック
- 管理者アカウントは、Authenticator だけに依存していないか。
- 少なくとも 2 種類以上の認証方法（例：Authenticator + FIDO2）が登録されているか。
- Authenticator アプリを再インストール・機種変更した際の手順を、運用ドキュメントとして残しているか。
運用ルール・監査のチェック
- ブレークグラス アカウントのパスワード管理方法（保管場所・アクセス権限）が明確になっているか。
- ブレークグラス アカウントにサインインがあった場合に通知や確認が行われる仕組みがあるか。
- 少なくとも年に 1 回は、「もし管理者がサインインできなくなったらどうするか」の訓練や棚卸しを行っているか。
まとめ：テナント ロックアウトは「設計」と「備え」で防ぐ
Azure Portal に突然サインインできなくなり、6 桁コードと 8 桁コードが噛み合わず、挙げ句の果てに Error Code 500121 まで出る――この状況は、多くの場合 テナント ロックアウト が背景にあります。唯一のグローバル管理者がロックアウトされてしまうと、自力ではほぼ復旧不可能であり、Microsoft サポートによる MFA/Passwordless リセットが必須です。
復旧後に重要なのは、
- グローバル管理者を複数用意すること。
- ブレークグラス アカウントを設計・運用すること。
- Authenticator だけに頼らず、複数の MFA 手段を登録しておくこと。
これらを事前に整えておけば、同じようなトラブルが発生しても 「復旧の道筋が見えている状態」 になります。Azure 環境のセキュリティはもちろん重要ですが、過度な複雑さや単一手段への依存は、かえって運用リスクを高めます。適切な冗長性と緊急時のルールを設計し、「安全に、かつ復旧可能な」テナント運用を目指しましょう。
コメント