「Azure ポータルにサインインできない」「Microsoft Entra ID の多要素認証(MFA)が進まずループする」――管理者自身がロックアウトされると、業務が一瞬で止まります。本記事では、MFA が原因で Azure（Microsoft Entra ID）に入れなくなったときの復旧手順と、二度と同じ事態を起こさないための運用設計を、管理者目線で具体的に整理します。
この記事で解決できること
- Azure / Microsoft Entra ID で「MFA 登録・認証が完了できずにサインインできない」状態の切り分け方
- 他に管理者がいる場合に実施すべき「Require re-register multifactor authentication（MFA 再登録の要求）」手順
- 自分が唯一のグローバル管理者（全体管理者）の場合に、Microsoft サポート（データ保護チーム）へ依頼して復旧する流れ
- ブレークグラス（緊急用）アカウントや SSPR・Temporary Access Pass（TAP）を使った再発防止策
- PIM（Privileged Identity Management）を活用した「普段は一般ユーザー、必要時だけ昇格」運用のポイント
前提：どのような状態が「MFA ロックアウト」なのか
まずは、いま起きている事象が「MFA ロックアウト」なのか、それとも別のサインイン問題なのかを切り分けます。Microsoft Entra ID（旧 Azure AD）は、Microsoft 365 / Azure / SaaS などの認証を一元管理するクラウド ID サービスであり、そのサインイン経路は複数あります。
| 画面上の症状 | 典型的な原因 | この記事の対象か |
|---|---|---|
| ユーザー名・パスワード入力後に 「追加の情報が必要です」と表示されるが、 Authenticator の通知やコード入力で先に進めない | Authenticator アプリを機種変更で失った / 電話番号が変わった / 登録済み MFA が利用不能 | 対象（MFA ロックアウト） |
| 「電話番号に SMS を送信しました」と出るが、 その番号はすでに使っていない | 古い電話番号が唯一の MFA として登録されている | 対象 |
| パスワード入力時点で 「パスワードが間違っています」と表示される | シンプルなパスワード誤り、もしくは アカウントロックアウト／ID 自体が無効化 | この記事の前に、パスワードリセットや アカウント状態の確認が必要 |
| 「このリソースにアクセスする権限がありません」 「このテナントにはアクセスできません」 | 別テナントのアカウントでサインインしている / 招待ゲストの権限不足 | この記事の主題ではない（権限設計の問題） |
この記事で扱うのは、「ID とパスワードは通るが、その先の MFA 認証・登録が完了できず、最終的に Azure ポータルなどに入れない」状況です。
最初にやるべき切り分けステップ
- 自分以外に「全体管理者（グローバル管理者）」や「認証管理者」が存在するかを確認
・管理ポータルに入れる同僚管理者がいるか
・CSP / SIer / MSP など外部パートナーが管理者になっていないか - 別のサインイン方法が残っていないか確認
・「別の方法でサインイン」リンクが使えるか
・セキュリティ情報ページ（https://aka.ms/mysecurityinfo）にアクセスできるか - ブラウザや端末起因ではないか確認
・別ブラウザ / プライベートウィンドウ / 別端末で再試行
・Authenticator の時刻同期や機内モード解除
これらを確認しても解消せず、かつ他の管理者が存在するかどうかで、以降の対応が 「ケースA：他管理者あり」 と 「ケースB：自分しか管理者がいない」 に分かれます。
ケースA：他に管理者がいる場合の復旧方法
自分以外に、全体管理者（Global Administrator） または Authentication Administrator（認証管理者） ロールを持ったユーザーがいれば、その人の操作で MFA ロックアウトはかなり高い確率で解消できます。
管理者側の操作：MFA 再登録を要求する
管理者に、Microsoft Entra 管理センターで Require re-register multifactor authentication（MFA の再登録を要求） を実行してもらいます。
- 管理者が Microsoft Entra 管理センター にサインイン
- 左側メニューで 「ID」 > 「ユーザー」 > 「すべてのユーザー」 を開く
- MFA ロックアウトしているユーザー（あなた）のアカウントをクリック
- ユーザー詳細のメニューから 「認証方法」(Authentication methods) を開く
- 画面上部のボタンから
「Require re-register multifactor authentication」
（MFA の再登録を要求） をクリックして確定する
この操作により、そのユーザーに紐づく 電話番号・Microsoft Authenticator・ソフトウェア OATH トークンなどの既存 MFA 情報がクリアされ、次回サインイン時に新しい MFA 登録が必須 になります。
| ボタン | 動作 | いつ使うか |
|---|---|---|
| Require re-register multifactor authentication | 登録済みの MFA 情報を削除し、 次回サインイン時に新規登録を強制 | 端末紛失、電話番号変更、Authenticator 削除など、 「MFA 手段が使えなくなった」とき |
| Revoke multifactor authentication sessions | 記憶された MFA セッションを無効化し、 再度 MFA を実行させる | 端末盗難・情報漏えいが疑われる場合に、 強制的に再認証させたいとき |
ポイント： この操作は「MFA の登録情報をリセットする」だけであり、MFA 要求そのもの（条件付きアクセスやセキュリティ既定）は無効化しません。ポリシーで MFA が必須なら、次回サインイン時も必ず MFA 登録フローが走ります。
どのロールを持っていれば実行できるか
| ロール | 「Require re-register MFA」実行可否 | 補足 |
|---|---|---|
| 全体管理者（Global Administrator） | ○ | 最も権限が強い。数は最小限に抑えるのがベストプラクティス。 |
| Authentication Administrator | ○ | ユーザーの MFA / パスワードリセットなど認証関連の管理に特化。 |
| Helpdesk Administrator など一般的な管理ロール | ×（既定では不可） | 必要ならロール設計を見直し、認証管理者ロールを別途付与する。 |
ユーザー側の操作：新しい MFA を登録する
管理者に再登録要求を行ってもらったら、次はロックアウトしていたユーザー自身の操作です。
- 通常どおり、Azure ポータルや Office アプリにサインイン
- 「追加の情報が必要です」などの画面が表示されたら、案内に従って 新しい MFA 方法を登録
（Microsoft Authenticator / SMS / 音声通話 / FIDO2 セキュリティキーなど） - 登録完了後、再度サインインを実行して問題なくポータルに入れるか確認
ここまで完了すれば、「端末紛失／機種変更で Authenticator が使えなくなっただけ」などのケースはほぼ解消します。
それでもダメな場合に確認したいポイント
- 条件付きアクセスで「特定のネットワーク / デバイス」しか許可していない など、MFA 以外の制限でブロックされていないか
- ユーザーが一時的に「サインイン不可」に設定されていないか
- パスワードの有効期限切れ・アカウントロックアウトが発生していないか
これらが原因だった場合は、MFA ではなく アカウント状態や条件付きアクセスの見直し が必要になります。
ケースB：自分が唯一のグローバル管理者（テナント ロックアウト）の場合
もっとも厄介なのが、自分が唯一の全体管理者で、その自分が MFA ロックアウトしてしまったパターンです。Microsoft 公式フォーラムでも、同様の相談が頻繁に寄せられています。
この場合、Entra 管理センターに入れないため、自分で「Require re-register MFA」を実行することができません。また、セキュリティ上の理由から、一般ユーザーと同じような自己回復手段も用意されていません。
復旧の基本方針：Microsoft サポート（データ保護チーム）に頼る
テナントの唯一の管理者がロックアウトしている場合、Microsoft 側で 「テナント所有者であること」 を確認したうえで、データ保護チーム（Data Protection Team）による MFA リセットやアクセス復旧 を行う必要があります。
大まかな流れは次のとおりです。
- 別の個人 Microsoft アカウント（例：outlook.com）や電話から、Microsoft 365 / Azure のサポート窓口に連絡
- 「自分が唯一のグローバル管理者であり、MFA の問題でポータルにサインインできない」ことを明確に伝える
- 「テナント ロックアウト」である旨を強調し、データ保護チームへのエスカレーションを依頼
- 連絡先情報・テナント情報・課金情報・ドメイン所有の証明などを求められるので順次回答
- 本人確認・テナント所有確認が完了すると、サインインを復旧するための手段（MFA リセット、Temporary Access Pass など）が案内される
重要なのは、公開フォーラムや SNS にテナント名・ドメイン・連絡先・スクリーンショットなど個人情報（PII）を書かないことです。これらの情報は、必ず Microsoft サポートとの 非公開チャネルでのみ共有してください。
サポート依頼前に準備しておきたい情報
問い合わせをスムーズにするため、次のような情報を事前に整理しておくとよいでしょう。
- 連絡先電話番号（+81 から始まる 国番号付きの形式）
- 連絡用メールアドレス（ロックアウトしている管理者アカウントとは別のアドレス）
- 影響を受けている管理者アカウントのユーザー名（UPN）
例：[email protected] - テナント ID または プライマリドメイン名
例：contoso.onmicrosoft.com - 利用中のサブスクリプション情報
例：Microsoft 365 Business Premium、Azure Pay-as-you-go など - 契約・支払い情報の一部
・請求先住所の国 / 地域
・請求書番号や支払いに使用しているクレジットカードの下 4 桁など（求められた範囲で） - 国 / タイムゾーン
例：Japan / UTC+9
これらは一例であり、実際にはサポート担当者の指示に従って追加情報を求められる場合があります。
パートナー経由の契約なら、まずはパートナーにも連絡
テナントが CSP（Cloud Solution Provider）や SIer 経由で契約されている場合、そのパートナーがテナントに対する管理権限を持っていることが多く、パートナー経由でサポートをエスカレーションしてもらうのが近道です。
| 契約形態 | 最初に連絡すべき窓口 | 理由 |
|---|---|---|
| CSP / パートナー経由 | 販売パートナーのサポート窓口 | パートナーが管理者権限を持ち、Microsoft サポートへのエスカレーションルートも確立されているため。 |
| 直接契約（クレジットカード払いなど） | Microsoft 365 / Azure の公式サポート | 直接 Microsoft に対してサポート依頼を行う。 |
失敗しやすいポイントと対処のコツ
「MFA の再登録要求」をすれば MFA が無効化される、と誤解しない
前述の通り、「Require re-register multifactor authentication」は登録済み情報のリセットであり、MFA ポリシーを解除するものではありません。条件付きアクセスやセキュリティ既定で MFA を必須にしている場合は、次回サインインでも必ず MFA 登録フローが走ります。
「管理者がいるのに、該当メニューが見つからない」場合
- そのユーザーに 全体管理者 または Authentication Administrator ロールが付与されているか確認
- 古い Azure ポータル（
portal.azure.com）ではなく、Entra 管理センター（entra.microsoft.com）を利用しているか確認 - ライセンスやプランによっては、認証ポリシーの一部機能が利用できないこともある
ロックアウト中にむやみに設定を変えない
焦って 条件付きアクセスをすべて無効化したり、「すべてのユーザーに対して MFA 無効」などの大きな変更を行うと、セキュリティリスクを一気に高めてしまいます。特に、他の管理者が作業している場合は、作業内容を事前に合意し、記録を残すことが重要です。
再発防止のベストプラクティス
一度テナント ロックアウトを経験した組織ほど、「二度と起こさないための仕組み」を整える価値があります。ここでは実践的な運用案を紹介します。
緊急用（ブレークグラス）管理者アカウントを最低 2 つ用意する
Microsoft は、通常の管理者アカウントとは別に「緊急用（Emergency / Break-glass）アカウント」を作成し、MFA や条件付きアクセスの誤設定によるロックアウトに備えることを推奨しています。
| 設計ポイント | 推奨設定例 |
|---|---|
| アカウント数 | 最低 2 アカウント（別部署・別担当者に割り当て） |
| ロール | 全体管理者（Global Administrator） |
| 利用用途 | テナント ロックアウト時などの「本当に緊急の場面」のみ |
| サインイン制御 | 条件付きアクセスから 明示的に除外 （少なくとも 1 アカウントはすべての CA ポリシーから除外） |
| 認証強度 | 非常に長く複雑なパスワード / FIDO2 キーなど |
| 監視 | サインインが発生したら必ずアラート通知し、 運用プロセスに記録 |
| 保存方法 | パスワード管理ツールや金庫など、 物理・論理ともに厳重な保管 |
「ブレークグラスアカウントを作っただけで満足してしまい、誰もパスワードを覚えていない／保管場所が不明」というのもよくある失敗です。定期的なテストサインインと、台帳の棚卸しを必ず行いましょう。
SSPR（セルフサービス パスワード リセット）と Temporary Access Pass（TAP）を有効化する
ユーザー自身がパスワードや MFA をある程度復旧できるように、SSPR と Temporary Access Pass（TAP） の併用を検討しましょう。
- SSPR（セルフサービス パスワード リセット）
・ユーザーが自分でパスワードをリセットできる機能
・電話 / メール / セキュリティ質問 / Authenticator などを第二要素として利用
・管理者も SSPR 対象に含めておくと、パスワード忘れの事故を減らせる - Temporary Access Pass（TAP：一時アクセスパス）
・有効期限付き・一時的なパスコードでサインインできる仕組み
・ユーザーは TAP でサインインし、Authenticator や FIDO2 キーなどの 強力な認証方法を再登録 できる
・端末紛失時の MFA 回復にも有効
TAP の有効化イメージは次のとおりです。
- 管理者が Entra 管理センターで 「保護」 > 「認証方法」 > 「Temporary Access Pass」 を有効化
- 対象ユーザーやグループをスコープに含め、TAP の有効期限・長さ・一回きり使用かどうかを設定
- ユーザーが MFA を失った場合、管理者が 「ユーザー」 > 対象ユーザー > 「認証方法」 > 「追加」 > TAP を発行
- ユーザーに TAP を安全な経路で伝え（電話など）、TAP でサインイン → Authenticator や FIDO2 を再登録
こうすることで、単に MFA をリセットするだけでなく、より強い認証方法への乗り換え を促すことができます。
PIM（Privileged Identity Management）で「普段は一般ユーザー」運用にする
管理者アカウントが日常的に高権限を持ち続けると、フィッシングやマルウェアで 1 回でも乗っ取られたときの被害が甚大です。Microsoft は、Privileged Identity Management（PIM）を使って「必要なときだけ管理者ロールを有効化する」運用を推奨しています。
代表的な設計例：
- 普段は管理者ロールを「Eligible（対象）」にしておき、作業前に PIM でロールをアクティブ化
- ロール有効化時には必ず MFA を要求し、理由やチケット番号の入力を必須にする
- 有効化時間を 1〜2 時間など短めにし、時間が来たら自動的に権限が剥奪されるようにする
- グローバル管理者ロールには 承認者 を設定し、別の管理者が承認しないと有効化できないようにする
- 定期的なアクセスレビューで、「もはや管理者ロールが不要なユーザー」を洗い出して削除
これにより、「ロックアウトした管理者の数」自体を減らし、かつ「万が一乗っ取られてもダメージを最小化」できます。
連絡先・手順を社内ドキュメントとして残す
最後に、「誰が・どこに連絡すればよいか」「どの手順で復旧するか」を、社内のナレッジとして文書化しておきましょう。
- 社内ポータルや Wiki に、次のようなページを用意
- 緊急用ブレークグラスアカウントの存在と、利用時のフロー（※パスワードそのものは記載しない）
- 「ケースA：他管理者がいる場合」「ケースB：唯一の管理者の場合」のフローチャート
- Microsoft サポートやパートナーの連絡先一覧
- テンプレート：サポートに連絡するときの説明文・英語フレーズ
- インシデントを経験したら、その内容と改善策を追記し、生きたドキュメントとして維持
よくある質問（Q&A）
Q. 「Require re-register MFA」と「ユーザーを削除して作り直す」の違いは？
A. ユーザーを削除すると、メールボックスや OneDrive、Teams などに紐づくデータが消えてしまうリスクがあります。一方、「Require re-register MFA」は認証情報だけをリセットするため、ユーザーデータへの影響なしに MFA をやり直せる点で安全です。
Q. グローバル管理者は何人まで作ってよい？
A. Microsoft は、グローバル管理者は 5 人未満に抑えることを推奨しています。
あまり多いと権限管理が雑になり、誰か 1 人が乗っ取られただけで大きな被害につながります。ブレークグラスアカウントを含めた全体設計を考えましょう。
Q. ブレークグラスアカウントにも MFA を必須にすべき？
A. ベストプラクティスとしては、少なくとも 1 アカウントは条件付きアクセスの影響を完全に受けない状態にしておくことが推奨されています。
一方で、パスワードは非常に強固にし、利用時の手続き（上長承認・記録など）とサインイン監視を徹底することで、セキュリティと可用性のバランスを取ります。
最短で復旧したい人向け・実践フローまとめ
最後に、ここまでの内容を「チェックリスト」的にまとめます。
- 他に全体管理者 or 認証管理者がいるか確認
・いれば「ケースA」、いなければ「ケースB」へ - ケースA（他管理者あり）のとき
- 管理者に Entra 管理センターで
「ユーザー > 対象ユーザー > 認証方法」を開いてもらう - 画面上部の 「Require re-register multifactor authentication」 を実行してもらう
- 自分は再度サインインし、新しい MFA（Authenticator / SMS / FIDO2 など）を登録
- 管理者に Entra 管理センターで
- ケースB（自分が唯一の全体管理者）のとき
- 別アカウントや電話から Microsoft 365 / Azure のサポートに連絡
- 「唯一の全体管理者が MFA の問題でサインインできず、テナント ロックアウトしている」ことを明示
- データ保護チームへのエスカレーションと、MFA リセットや一時アクセス手段の提供を依頼
- 連絡先電話番号・テナント ID・契約情報など、求められた情報を非公開チャネルで提供
- 復旧後に必ず行うこと
- ブレークグラスアカウント（少なくとも 2 アカウント）の作成とテスト
- SSPR / Temporary Access Pass の有効化とポリシー設計
- PIM による「必要時だけ管理者昇格」運用への移行
- 今回のインシデント内容と対処を、社内ドキュメントに反映
これらを実践しておけば、次に同じトラブルが起きても、「誰が・どう動けばよいか」が明確で、復旧までの時間とストレスを大きく減らすことができます。Azure / Microsoft Entra ID は組織全体の入り口となる重要な基盤だからこそ、「壊れたときにどう直すか」「壊れないようにどう設計するか」をあらかじめ決めておきましょう。
コメント