Azure ポータルにサインインしようとしても、Microsoft Authenticator に承認通知やワンタイムコードが届かず、MFA が突破できない――しかも自分しかグローバル管理者がいない。この状況はまさに「テナント ロックアウト」で、業務が完全に止まる重大インシデントです。本記事では、シナリオ別の復旧手順と、二度と同じ事態を起こさないための設計・運用のポイントを具体的に解説します。
Azure ポータルにサインインできない状況の整理
今回の前提となる質問内容は次のようなものです。
- Azure ポータルにサインインしようとすると、Microsoft Entra ID（旧 Azure AD）の MFA が求められる。
- しかし Microsoft Authenticator アプリに承認通知やコードが届かないため、MFA を完了できない。
- テナント内にグローバル管理者が自分一人しかおらず、他の管理者に MFA をリセットしてもらうこともできない。
このようなケースは、次の 2 パターンに分類できます。
| シナリオ | 概要 |
|---|---|
| シナリオ A | 自分以外にもグローバル管理者が存在し、その人はサインイン可能 |
| シナリオ B | 自分が唯一のグローバル管理者で、その自分が MFA でロックアウト（テナント ロックアウト） |
以降では、この 2 パターンに分けて復旧手順と注意点を詳しく解説していきます。
Microsoft Authenticator に通知やコードが届かない主な原因
復旧を進める前に、「なぜ Authenticator に通知やコードが届かなくなったのか」という原因を整理しておくと、再発防止策を考えやすくなります。
| 原因の例 | よくある具体的な状況 |
|---|---|
| スマートフォンの機種変更・紛失 | 旧端末でバックアップやアカウント移行をせずに端末を初期化／廃棄してしまい、新端末には Microsoft Authenticator のアカウントが登録されていない。 |
| Authenticator アプリの再インストール | トラブルシューティングの一環で一度アプリを削除してしまい、MFA 情報ごと消えてしまった。 |
| 通知のブロック・OS 設定 | スマホ側でプッシュ通知をオフにしている、または省電力モード・フォーカスモードにより通知が届かない。 |
| 時刻のずれ | 端末の時刻設定が自動でなく、数分以上ずれており、OTP コードが常に無効になる。 |
| ネットワーク制限 | 社内 Wi-Fi で通知のバックエンド通信がブロックされている、もしくはモバイルデータ通信が無効。 |
| ポリシー変更 | 別の管理者が条件付きアクセスやセキュリティ既定値を変更し、これまでと異なる MFA 方法を要求している。 |
今回のように「そもそもポータルに入れない」状態では詳細な原因調査は後回しになりますが、復旧後に上記をひとつひとつ潰していくことで、次のロックアウトを防ぐことができます。
シナリオ別：Azure ポータルにサインインできない時の復旧手順
ここからは、シナリオ A / B に分けて実際の操作手順を整理します。
| シナリオ | 手順概要 |
|---|---|
| A. 別のグローバル管理者が存在する場合 | 他の管理者に Azure ポータルへサインインしてもらう。 Microsoft Entra ID から対象ユーザーの「多要素認証の再登録」を要求する。 本人が再サインインして MFA の再登録ウィザードを完了する。 |
| B. 唯一のグローバル管理者でテナント ロックアウトの場合 | まず Microsoft 365 管理センター（管理センター）にサインインできるか試す。 入れる場合は新しい管理者アカウントを作成し、そこから自分の MFA をリセット。 どこにもサインインできない場合は、Microsoft サポートへ Tenant Lockout としてエスカレーションを依頼する。 |
シナリオ A：別のグローバル管理者が存在する場合の復旧手順
他にグローバル管理者が 1 名以上いる場合、復旧は比較的シンプルです。別の管理者に Azure ポータルへサインインしてもらい、次の手順で対象ユーザーの MFA 再登録を要求します。
- 別の管理者が Azure ポータルにサインインする。
- 「Microsoft Entra ID」（旧 Azure Active Directory）を開く。
- 左メニューから「ユーザー」を選択し、MFA が使えなくなっているユーザー（質問者本人）を検索して選択する。
- ユーザー画面で「認証方法」（または「Authentication methods」）を開く。
- 「多要素認証の再登録を要求」ボタンをクリックする。
- 対象ユーザーは再度 Azure ポータルへのサインインを試みる。
- サインイン時に、MFA の再登録ウィザードが自動的に起動するので、新しい端末の Microsoft Authenticator や SMS などを登録する。
この操作により、旧端末や古い Authenticator 設定は無効化され、新しい MFA 情報のみが有効になります。なお、再登録ウィザードでは複数の認証方法（アプリ通知・コード、SMS、電話、FIDO2 キーなど）を同時に設定しておくと、後述のようにロックアウトのリスクを大きく減らせます。
シナリオ B：唯一のグローバル管理者でテナント ロックアウトしている場合
もっとも深刻なのがこのパターンです。自分が唯一のグローバル管理者で、その自分が MFA 認証できず Azure ポータルに入れないケースです。この場合は、次の 2 段階で復旧を試みます。
ステップ 1：管理センター（Microsoft 365 管理センター）にサインインできるか確認
まずは Azure ポータル以外でサインインできる管理プレーンがないか確認します。代表的なのは Microsoft 365 管理センター（admin.cloud.microsoft.com）です。
- ブラウザで管理センターにアクセスする。
- 問題のグローバル管理者アカウントでサインインを試みる。
- ここでサインインが通る場合、MFA 要求の条件（条件付きアクセスなど）が Azure ポータルと異なっている可能性があります。
もし管理センターに入れた場合は、そこで新しい管理者アカウントを作成し、グローバル管理者ロールを付与します。そのうえで新しい管理者アカウントで Azure ポータルへサインインし、先ほどの「シナリオ A」と同じ手順で元のアカウントの MFA 再登録を要求します。
| 操作場所 | 目的 | ポイント |
|---|---|---|
| Microsoft 365 管理センター | 新しい管理者アカウントを作成 | 一時的な「救済用管理者」と割り切って作成し、復旧完了後に権限を見直す。 |
| Azure ポータル（新管理者） | 元のアカウントの MFA 再登録を要求 | 復旧後は、救済用アカウントを残すかブレークグラスアカウントに転用するかを検討。 |
ステップ 2：どこにもサインインできない場合は Microsoft サポートへ Tenant Lockout として依頼
Azure ポータルにも管理センターにもサインインできず、テナントにアクセスできる手段が完全に失われた場合は、セルフサービスでの復旧は困難です。この場合は Microsoft サポートに「Tenant Lockout（テナント ロックアウト）」としてエスカレーションし、データ保護チームにロック解除を依頼します。
サポートチケット作成時には、本人確認とテナント所有者を証明するため、次のような情報の提出を求められます。これらは必ず電話やサポートポータルなどのプライベートチャネルで提出し、SNS や公開された場には決して記載しないよう注意してください。
| 項目 | 内容例 |
|---|---|
| 連絡先電話番号 | +81 90-xxxx-xxxx など（国番号を含めた形式） |
| 連絡先メールアドレス | 個人の業務用メールアドレス（ロックアウト中のテナントとは別のメールもあるとベター） |
| 影響を受けた管理者アカウント | [email protected] などの UPN |
| テナント名 / テナント ID | contoso.onmicrosoft.com、もしくはテナント GUID |
| サブスクリプション ID | Azure サブスクリプションの GUID。請求書や過去のメールに記載されていることが多い。 |
| 国 / タイムゾーン | Japan / Tokyo Standard Time など |
サポート側では、これらの情報をもとに本人確認・テナントの所有者確認を行い、必要に応じて MFA 条件の緩和や一時的なアクセス手段を提供します。ロックアウト解除には一定の時間がかかる場合があるため、日頃から上記情報をまとめた「インシデント対応シート」をオフラインで保管しておくとスムーズです。
ベストプラクティス：テナント ロックアウトを防ぐための設計と運用
一度ロックアウトを経験するとよく分かりますが、もっとも重要なのは「起こってからどう復旧するか」だけでなく、「そもそもロックアウトを起こさない設計」をしておくことです。ここでは実運用で強くおすすめしたいベストプラクティスを整理します。
グローバル管理者は最低 2 名＋ブレークグラスアカウント
まず大前提として、グローバル管理者は最低 2 名用意することが推奨されています。さらに、通常の条件付きアクセスや MFA ポリシーの対象外とするブレークグラス（緊急用）アカウントを 1～2 個用意しておくと安心です。
| 種別 | 用途 | ポイント |
|---|---|---|
| 通常のグローバル管理者 A / B | 日常運用・構成変更・ユーザー管理 | MFA 必須。できれば個人名義ではなく、役職・役割に紐づくアカウント名にすると引き継ぎしやすい。 |
| ブレークグラスアカウント | 条件付きアクセスや MFA によるロックアウト時の緊急ログイン用 | 強力なパスワードを設定し、原則ログインしない。MFA ポリシーから一時的に除外し、オフラインで厳重に保管。 |
ブレークグラスアカウントのパスワードは紙に印刷して金庫に入れる、別システムのパスワードマネージャーに保管するなど、オンライン攻撃と物理リスクの両方を考慮して管理しましょう。また、定期的にログインテストを行い、「いざというときに本当に使えるか」を検証しておくと安心です。
複数の MFA 方法を事前登録しておく
Authenticator アプリだけに頼ると、端末紛失・故障のインパクトが非常に大きくなります。できる限り複数の MFA 方法を組み合わせて登録しておきましょう。
| MFA 方法 | メリット | 注意点 |
|---|---|---|
| Microsoft Authenticator（通知・コード） | 最も使い勝手が良く、セキュリティも高い。 | 端末依存度が高い。機種変更時は必ず事前にバックアップや移行を行う。 |
| SMS（テキストメッセージ） | スマホの機種が変わっても電話番号が同じなら継続利用しやすい。 | SMS 受信が不安定な国・地域もあるため、メインではなくバックアップ用途に。 |
| 音声通話 | データ通信が使えない場合のバックアップとして有効。 | 自動音声が聞き取りづらい環境では注意。 |
| FIDO2 セキュリティキー | フィッシング耐性が高く、物理キーとして管理しやすい。 | 鍵の紛失や破損に備え、複数本用意するのがベスト。 |
セキュリティ情報の登録画面では、複数の認証方法を追加できます。最低でも「Authenticator + SMS」または「Authenticator + FIDO2 キー」のように 2 系統以上を登録しておくと、1 つが使えなくなってもログイン不能にはなりません。
セキュリティ情報の一括登録（Combined registration）の活用
Microsoft Entra ID では、MFA とパスワードリセット（SSPR）のセキュリティ情報を一括で登録する「統合登録（Combined registration）」が利用できます。これを有効化しておくと、ユーザーは 1 つの画面で MFA と SSPR の両方に必要な情報を設定でき、結果としてロックアウト耐性が高まります。
- ユーザーにとっての利便性が高く、登録漏れが減る。
- 管理者側も「どのユーザーがどの認証方法を持っているか」を把握しやすい。
- パスワード忘れ＋MFA デバイス紛失のような複合的な事故のリスクが下がる。
ロールアウト時には、社内ポータルやメールで「なぜ今 MFA の登録画面が表示されているのか」「どのような情報を登録すべきか」を丁寧に説明すると、ユーザーの混乱を防げます。
PowerShell での MFA リセット例（補足）
グローバル管理者が複数いる環境では、GUI ではなく PowerShell で MFA をリセットしたいケースもあります。たとえば、多数のアカウントの MFA をまとめてリセットしたい場合や、自動化スクリプトに組み込みたい場合などです。
Azure AD / MSOnline モジュールを利用した代表的な例を以下に示します。
# MSOnline モジュールのインポート
Import-Module MSOnline
# 管理者としてサインイン
Connect-MsolService
# 対象 UPN の MFA 設定をリセット
Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName [email protected]
このコマンドを実行すると、指定したユーザーに紐づく強力な認証方法（strong authentication methods）がリセットされ、次回サインイン時に MFA の再登録ウィザードが起動します。実行には十分な権限（グローバル管理者など）が必要な点に注意してください。
なお、将来的には Microsoft Graph PowerShell への移行が推奨されているため、新規で自動化を組む場合は Graph ベースの API やコマンドレットの利用も検討するとよいでしょう。
復旧後に必ず確認しておきたいログと設定
MFA ロックアウトから復旧できたら、「なぜそのタイミングでロックアウトが起きたのか」「悪意あるアクセスではなかったか」を確認することが重要です。少なくとも次のポイントは確認しておきましょう。
サインインログの確認
Azure ポータルの Microsoft Entra ID > サインインログを開き、該当ユーザーの最近のサインイン履歴を確認します。
- ロックアウト直前に、海外 IP や未知のデバイスからのサインイン試行がないか。
- MFA が失敗した理由（例：接続タイムアウト、ユーザーが拒否など）。
- 短時間に多数のサインイン失敗が続いていないか。
不審な挙動が見られた場合は、パスワード変更、セッションの失効、条件付きアクセスの見直しなど、追加の対策を検討してください。
監査ログ・アラートの確認
監査ログでは、管理者ロールの変更やセキュリティ設定の変更履歴を確認できます。ロックアウト直前に誰かが条件付きアクセスや MFA ポリシーを変更していないかを確認しましょう。
- グローバル管理者ロールの付与・削除。
- 条件付きアクセスの新規作成、変更、削除。
- セキュリティ既定値の有効化・無効化。
また、セキュリティアラートを発報する仕組み（Defender for Cloud Apps や SIEM）を導入している場合は、今回のインシデントに関連するアラートが出ていないかも確認します。
現場でよくある疑問と運用のコツ
Q1. 管理者のスマホを個人所有にしているが、端末管理はどうすべき？
管理者の MFA 端末は、事実上テナント全体の「鍵」を握る存在です。可能であれば会社支給端末を割り当て、モバイルデバイス管理（MDM）で最低限のセキュリティポリシーを適用することをおすすめします。
- PIN / 生体認証の必須化。
- 紛失時のリモートワイプ。
- アプリのインストール制御や OS バージョン管理。
どうしても個人端末を使わざるを得ない場合は、利用規程やインシデント時の連絡フローを明文化し、端末紛失時にすぐ連絡が来るような文化づくりも重要です。
Q2. ブレークグラスアカウントに MFA をかけないのは危険では？
ブレークグラスアカウントは原則として条件付きアクセスや MFA の対象外にし、「最後の砦」として残しておくのが一般的なベストプラクティスです。ただし、その分パスワードの強度と保管方法、監視が極めて重要になります。
- 非常に長く推測困難なパスワード（例：ランダムな 30 文字以上）を設定する。
- 日常的に使用しない（ログイン履歴があれば要調査）。
- サインインログやアラートでブレークグラスアカウントの利用を監視する。
どうしても不安な場合は、「通常は MFA を要求するが、条件付きアクセスの誤設定であっても必ずログインできる例外条件（特定ネットワーク、特定端末など）を組み合わせる」など、自組織のリスク許容度に応じた設計を検討するとよいでしょう。
Q3. ロックアウト発生時の社内連絡はどう設計すべき？
テナント ロックアウトは、社内の多くのクラウドサービスに影響する重大インシデントです。次のような観点で、あらかじめ「ロックアウト時対応マニュアル」を用意しておくと、慌てずに対応できます。
- 誰がインシデントマネージャーを務めるか（代理の責任者も含めて明記）。
- Microsoft サポートへの連絡手順と、必要な情報一覧。
- 業務影響と暫定対応策（オンプレミスへの切り戻し、ローカルキャッシュの活用など）。
- ユーザー向けの一次連絡テンプレート（メール・チャット・社内ポータル）。
こうした事前準備があるだけで、実際にロックアウトが起きたときの心理的な負担は大きく軽減されます。
まとめ：Azure ポータルの MFA ロックアウトは「事前の設計」と「複線化」で防ぐ
Azure ポータルにサインインできず、Microsoft Authenticator の通知やコードが届かない問題は、単なる「スマホのトラブル」ではなく、テナント全体の可用性に直結する重大なリスクです。
- 別のグローバル管理者がいれば、その管理者に「多要素認証の再登録を要求」してもらうことで、比較的容易に復旧できる。
- 唯一の管理者がロックアウトした場合は、管理センターから救済用管理者を作成するか、それもできない場合は Microsoft サポートに Tenant Lockout としてエスカレーションが必要。
- 日頃から「グローバル管理者 2 名以上＋ブレークグラスアカウント」「複数の MFA 方法の登録」「インシデント対応手順の明文化」といった対策をしておけば、ロックアウトの発生確率も影響範囲も大きく減らせる。
今回紹介した手順とベストプラクティスを、自社テナントの運用設計やドキュメントに落とし込み、「管理者が倒れても Azure 環境は止まらない」状態を目指していきましょう。
コメント