ある日突然、Microsoft Entra ID（旧Azure AD）の管理センターから「MFA のユーザーのブロック／解除」が消えてしまい、ヘルプデスクや管理者の運用が止まってしまう――この記事では、この現象の背景（UI不具合＋仕様変更）と、今すぐ取るべきワークアラウンド、そして中長期的に目指すべき「不審なアクティビティの報告」＋ Identity Protection 前提の運用設計までを、具体的な手順付きで整理します。
Entra ID の MFA「ユーザーのブロック／解除」が見つからないのはなぜか
現象の概要：今朝まであったメニューが消えた
ここ数ヶ月、日本・海外問わず Microsoft Q&A やフォーラムで、次のような相談が相次いでいます。
- Entra 管理センターで Multi-Factor Authentication（MFA） の設定画面を開いても、「ユーザーのブロック／ブロック解除（Blocked users）」メニューが表示されない
- グローバル管理者（またはセキュリティ管理者）でも同じ事象が発生
- しばらくすると表示されることもあるが、また消えてしまう
- しかし、ポータル上部の検索や直接 URL からであれば「Blocked users」ブレードに到達できる
Microsoft の Q&A でも「Block/unblock users がグローバル管理者から見えない」という質問があり、UI 側の一時的な不具合と、後述する レガシー MFA 機能のリタイア の両方が関係していると回答されています。
一時的な UI 不具合としての側面
まず、純粋に UI 側の問題として、次のような挙動が報告されています。
- 管理センターの左ナビやサブメニューに「Blocked users」が表示されたり、されなかったりする
- しかし、ポータル検索バーで「Blocked users」や「ブロックされたユーザー」と検索するとブレードが開く
- 直接 URL
https://entra.microsoft.com/#view/Microsoft_AAD_IAM/BlockedUsersBladeをブックマークしておけば、そこからは安定してアクセスできる
このため、「メニューから消えた＝機能が完全に削除された」ではないケースが多く、まずは UI 側の一時的な読み込み不具合（キャッシュ・ロールアウト途中・A/B テスト等）を疑うのが現実的です。
本質的には「レガシー MFA 機能のリタイア」が進行中
とはいえ、単なる不具合だけでは説明しきれない事情もあります。Microsoft は 2024〜2025 年にかけて、いわゆる 「レガシー MFA 設定」 を段階的に廃止し、新しい仕組みに置き換える方針を明言しています。
公式ドキュメントおよび Entra リリースノートでは、おおむね次のように案内されています。
- MFA Fraud Alert（MFA 詐欺アラート） 機能は 2025 年 3 月 1 日 をもってリタイア予定
- これと一緒に提供されていた 「ユーザーのブロック／解除（block/unblock users）」 も同じ枠で廃止対象
- 代替として、Microsoft Authenticator などから利用できる 「不審なアクティビティの報告（Report suspicious activity）」 が推奨されている
- 「不審なアクティビティの報告」でユーザーが「自分ではない」と報告すると、そのユーザーは 「高リスクユーザー」 として Identity Protection に連携される
Q&A の回答でも、Block/unblock users の代わりに Report suspicious activity を有効化するよう案内されており、運用の重心を徐々にそちらへ移すのが Microsoft の意図だと読み取れます。
運用を止めないための短期的なワークアラウンド
Blocked users ブレードに直接アクセスする
「今まさにブロックされて困っているユーザーがいる」「とりあえず今日の問い合わせをさばきたい」という状況では、次のワークアラウンドが現実的です。
方法 1：ポータルの検索バーから開く
- https://entra.microsoft.com にアクセスし、管理者でサインインします。
- 画面上部の検索ボックスに 「Blocked users」 または 「ブロック」 と入力します。
- 候補に表示される 「Multi-Factor Authentication > Blocked users」 を選択します。
メニューに表示されていなくても、検索からであればアクセスできるケースが多く報告されています。
方法 2：BlockedUsersBlade の URL をブックマークする
より確実なのは、次の URL をブックマークしておき、そこから直接開く方法です。
https://entra.microsoft.com/#view/Microsoft_AAD_IAM/BlockedUsersBlade
このブレードに到達できれば、従来どおり ブロックされたユーザーの一覧表示・ブロック解除 が行えます。
ポータル表示まわりの基本的な切り分け
UI 不具合か、自分の環境特有の問題かを切り分けるために、最低限次のポイントを確認しておきましょう。
| 確認項目 | ポイント |
|---|---|
| ブラウザのキャッシュ | Ctrl＋F5 での再読み込み、キャッシュ削除、シークレットウィンドウでの再アクセスを試す |
| 別ブラウザ | Edge / Chrome / Firefox など、別ブラウザで表示されるか確認する |
| テナント | 複数テナントを扱っている場合、右上のアカウントメニューからテナント切り替えを確認 |
| ロール | 対象アカウントに グローバル管理者 または セキュリティ管理者 等の必要ロールが付与されているか確認 |
| ポータル URL | portal.azure.com ではなく、entra.microsoft.com を利用しているか確認 |
| 組織内の他管理者 | 別の管理者アカウントで同じ事象が発生するか確認（自アカウント固有の問題か切り分け） |
上記を試してもメニューに表示されず、検索や直接 URL からならアクセスできる場合は、UI のロールアウト・キャッシュ・一時的な読み込み不具合である可能性が高いと考えて良いでしょう。
中長期的に必要なこと：レガシー MFA からの脱却
なぜ「ユーザーのブロック／解除」が廃止方向なのか
従来の MFA Fraud Alert ＋ ユーザーのブロック／解除の組み合わせは、次のような特徴を持っていました。
- ユーザーが「これは自分ではない」と報告すると、アカウントを自動的にブロックリストに追加できる
- ブロックしたユーザーの解除は、管理者が手動で実施する必要がある
セキュリティ的には有効ですが、「誤タップ」や「軽微なリスク」でも容赦なくブロックされ、毎回ヘルプデスク行きになるため生産性を下げやすいという課題もありました。
一方で、Entra ID では Identity Protection ＋ 条件付きアクセス による リスクベースの自動ブロック・自動復旧 を重視する方向に舵が切られました。これに伴い、シンプルだが粗い制御だった「ブロック／解除」から、よりきめ細かいリスクベース制御へ移行しようというのが、今回のリタイア方針の背景です。
新方式：「不審なアクティビティの報告（Report suspicious activity）」とは
Report suspicious activity（不審なアクティビティの報告） は、Microsoft Authenticator や電話認証で、ユーザーが「この MFA 要求は自分ではない」と報告するための機能です。
主な特徴は次のとおりです。
- ユーザーは、MFA プロンプトを単に拒否するだけでなく、「不審」として報告できる
- 報告されたユーザーは 「高リスクユーザー（High user risk）」 として記録される
- このリスク情報が Identity Protection と 条件付きアクセス に連携され、リスクベースのポリシーによる自動ブロック・自動復旧が可能になる
Microsoft のドキュメントでは、Report suspicious activity は MFA Fraud Alert の後継機能と明記されており、現在は Fraud Alert と並行して動作していても、最終的にはこちらに移行することが推奨されています。
旧方式と新方式の違いを表で整理
| 項目 | 旧方式：MFA Fraud Alert＋ ユーザーのブロック／解除 | 新方式：不審なアクティビティの報告＋ Identity Protection |
|---|---|---|
| ユーザー操作 | 電話・アプリで「詐欺コード」を入力／ Fraud Alert を報告 | 認証アプリや電話で 「これは自分ではない」 を選択 |
| ブロックの仕組み | （オプション設定により） 報告と同時にユーザーを ブロックリストに追加 | 報告したユーザーの ユーザーリスクを高に設定し、 条件付きアクセスのリスクポリシーで ブロックまたは追加検証 |
| 復旧フロー | 管理者が Blocked users ブレードから手動で解除 | リスクベース CA により ユーザー自身の MFA 成功や 安全なパスワード変更で自動復旧＋必要に応じて管理者が手動でリスク解除 |
| レポート・可視化 | サインインログに Fraud Alert イベントが表示 | リスク検出／リスキーサインイン／高リスクユーザー レポートとして一元管理 |
| ライセンス依存 | 主に MFA ライセンスで利用可能 | リスクベース CA や ID Protection のレポート活用には Entra ID P2 が必要 |
| 位置付け | レガシー（廃止予定） | 今後の標準（推奨） |
ライセンス別の推奨運用パターン
「不審なアクティビティの報告」は広いプランで利用できますが、Identity Protection とリスクベース条件付きアクセスをフル活用できるのは Entra ID P2 です。
Entra ID P2 を持っている場合：リスクベース運用が本命
Entra ID P2 ライセンスがある場合は、次のような構成が理想的です。
- 「不審なアクティビティの報告」を有効化
Entra 管理センター > セキュリティ > 認証方法 > 設定 から Report suspicious activity を Enabled にします。 - ユーザーリスク・サインインリスクのポリシーを作成
Identity Protection の ユーザーリスクポリシー／サインインリスクポリシー を設定し、リスクが高い場合に MFA や安全なパスワード変更を強制します。 - 高リスク時の自動ブロック＋自己復旧
例えば以下のようなシンプルな方針がよく採用されます。- ユーザーリスク＝高 の場合：パスワード変更を強制し、完了したら自動的にリスクを「解消」
- サインインリスク＝中以上 の場合：MFA を要求し、成功すればリスクを「解消」
- ヘルプデスクは「リスクが解消できないときのバックアップ」として動く
原則はユーザー自身の自己復旧で完結させ、例外時のみ管理者がリスク解除・一時的なサインイン許可などを行う運用とします。
この構成に移行すると、従来の「ブロックされたユーザー」画面に頻繁にアクセスする必要自体が薄くなり、ブレードが見えたり見えなかったりする UI 問題の影響をほとんど受けなくなります。
Entra ID Free / P1 の場合：手動運用＋ログ活用が中心
Entra ID Free や P1 の場合は リスクベース条件付きアクセスの部分が使えないため、次のような運用が現実的です。
- Report suspicious activity は有効化しておく（ユーザーの報告はログに残る）
- サインインログ／監査ログで 「ユーザーが不審なアクティビティを報告した」イベントを確認する
- 対応方針としては、
- 一時的にアカウントを無効化（サインインをブロック）
- パスワードリセット（ユーザーへの連絡を伴う）
- MFA の再登録を案内
この場合でも、「ブロックされたユーザー」ブレードは当面は利用できますが、将来的には廃止される前提で「Report suspicious activity ＋ サインインログ」を軸にした手順書へ差し替えておくことをおすすめします。
「不審なアクティビティの報告」を有効化する具体的な手順
ここでは、実際に設定を変える手順を、管理者目線でまとめます。
設定画面への入り方
- 管理者アカウントで Entra 管理センター にサインインします。
- 左側ナビで 「セキュリティ（Security）」 をクリックします。
- 「認証方法（Authentication methods）」 > 「設定（Settings）」 を選択します。
- 設定項目の一覧の中に 「Report suspicious activity」 セクションが表示されます。
有効化とスコープ設定
- State を Enabled に変更します。
- 対象ユーザー を「All users」または特定グループに限定して設定します。
- 最初は IT 部門やパワーユーザーのみを対象にパイロット運用する案もあります。
- 安定運用できることを確認したら、全ユーザーへ拡大するのがおすすめです。
- [保存] をクリックして設定を反映します。
なお、Microsoft が推奨する 「セキュリティ構成のベースライン」でも、Microsoft Authenticator の 「report suspicious activity が有効になっていること」がチェック項目として含まれており、今後は標準的に有効化される方向性であることがうかがえます。
ブロックから復旧までの標準フローを設計する
従来フロー：Blocked users だけに依存していた例
古い手順書の多くは、だいたい次のような流れになっているはずです。
- ユーザー「MFA が通らなくなった」とヘルプデスクに連絡
- ヘルプデスクが 「ブロックされたユーザー」画面を開く
- 該当ユーザーがブロックされていれば、ブロック解除
- 必要に応じてパスワードリセット／MFA 再登録を案内
このフローはシンプルですが、「なぜブロックされたのか」や「本当に解除してよいのか」を考慮しないという弱点があります。
今後の標準フロー：リスクベース視点を組み込む
今後は、少なくとも次のような分岐を取り入れることをおすすめします。
| ステップ | P2 ライセンスありの場合 | P2 ライセンスなしの場合 |
|---|---|---|
| 1. 問い合わせ受付 | ヘルプデスクが、ユーザーからの「MFA に失敗する／不審な通知が来た」などの連絡を受ける | |
| 2. 状況確認 | Identity Protection の 高リスクユーザー・リスキーサインイン レポートを確認 | サインインログで 異常なサインインや「不審なアクティビティ報告」イベント を確認 |
| 3. リスク評価 | ユーザーリスク・サインインリスクのレベルを確認し、既存ポリシーでブロックされているか確認 | ログから、地理的におかしなサインインや大量の試行など、攻撃の兆候がないかチェック |
| 4. 復旧方法の決定 | 可能なら ユーザー自身のパスワード変更／MFA 成功による自己復旧 を案内。必要があれば管理者がリスク解除・一時的な除外を実施 | 管理者がパスワードリセット＋一時的なサインイン制限でリスクを抑えつつ、再登録を案内 |
| 5. ブロックされたユーザーの扱い | 原則として新たに「ブロックされたユーザー」に追加しない（リスクベース制御を優先） | 暫定的には「ブロックされたユーザー」を利用しても良いが、将来的に廃止されることを前提に、徐々に依存度を下げる |
ポイントは、「とにかく Blocked users でブロック解除」から、「まずリスクを確認して適切な復旧アクションを選ぶ」流れに頭を切り替えることです。
ヘルプデスク向けの具体的なシナリオと対応例
シナリオ 1：ユーザーが誤って「これは自分ではない」を押してしまった
もっともありがちな問い合わせのひとつが、「うっかり『これは自分ではない』を押してしまった」パターンです。
P2 ライセンスありの場合
- Identity Protection の 高リスクユーザー レポートで該当ユーザーを確認
- サインイン履歴や端末情報を見て、本当に本人のサインインであることを確認
- 問題なければ、そのイベントに紐づく ユーザーリスクを「解除／解消（Dismiss）」します。
- 必要に応じて、念のためユーザーにパスワード変更を案内します。
このとき、単に「ブロックされたユーザー」から解除するだけでなく、リスクイベント側もきちんとクローズすることで、監査上も「誤報だった」と説明しやすくなります。
P2 ライセンスなしの場合
- サインインログで、該当ユーザーの直近サインインを確認
- 不審な地理・IP・クライアントが無いか確認し、問題なさそうであれば通常どおりサインインを許可
- 念のためパスワード変更と MFA 再登録（Authenticator 再追加）を促す
- 必要であれば、一時的に Blocked users から解除するが、今後はなるべく利用しないよう運用を見直す
シナリオ 2：本当に不審な MFA 通知が来ている（攻撃の可能性）
共通の初動
- ユーザーには「MFA 通知はすべて拒否」「メールや Teams 上の怪しいリンクはクリックしない」よう伝える
- 管理者は、直近のサインインログで不審なサインインが無いかを優先的に確認
P2 ライセンスありの場合
- 高リスクユーザー／リスキーサインインとして検出されている場合、既存のリスクポリシーがブロックや追加検証を行っているかを確認
- 必要に応じて、該当ユーザーを一時的にポリシーから除外し、安全な端末からの パスワードリセット＋MFA 再登録 を実施
- 攻撃と判断した場合は、「ユーザーが侵害された」として扱い、端末・メールボックス・他サービスの被害調査も行う
P2 ライセンスなしの場合
- サインインログと監査ログで、明らかに不審なサインイン（海外からの連続試行など）があれば、すぐにユーザーのサインインをブロック
- 管理者がパスワードリセット（必要に応じて UPN 変更やメールアドレスエイリアス見直し）を実施
- 安全な端末からのサインインと MFA 再登録を行わせたうえで、ブロック解除
シナリオ 3：既存の「ブロックされたユーザー」依存運用からの脱却
すでに「不審な MFA があればとりあえずブロック」「ブロック解除はヘルプデスク経由」という運用が定着している環境では、いきなり全部を捨てるのは現実的ではありません。次のようなステップで段階的に移行するのがスムーズです。
- 現状運用の見える化
過去 3〜6 ヶ月分の「ブロックされたユーザー」一覧をエクスポートし、どんな理由でブロックしているのか、どのくらいの頻度で解除されているのかを確認します。 - 「本当にブロックすべきケース」と「リスク低ケース」を切り分け
例えば、「明らかな攻撃」「再発を繰り返す」「重要システムへのアクセス」など、本当にブロックが必要な条件を洗い出します。 - 軽微なケースはリスクベース運用に移行
P2 環境では条件付きアクセス、P1 環境ではサインインログ＋パスワード変更で対応するよう手順書を更新します。 - Blocked users の新規利用を原則禁止にする
新たにユーザーをブロックリストへ追加するルールを廃止し、「既存のブロック解除のみ」に用途を絞ります。 - 一定期間経過後に Blocked users への依存を完全撤廃
すべてのブロックがリスクベースまたはサインインブロックで代替できるようになったタイミングで、旧手順を破棄します。
よくある質問（FAQ）
Q. 今、「ブロックされたユーザー」はどこから見ればいいですか？
A. メニューから見えない場合でも、Entra 管理センター上部の検索で 「Blocked users」 と検索するか、https://entra.microsoft.com/#view/Microsoft_AAD_IAM/BlockedUsersBlade に直接アクセスすれば、多くのテナントでまだブレードに到達できます。長期的には、Identity Protection の「高リスクユーザー」ビューをメインの確認場所とすることをおすすめします。
Q. 「ブロック／解除」機能そのものは、もう使えないのでしょうか？
A. 現時点（2025 年）では、多くのテナントでまだ利用可能ですが、Microsoft のリリースノートには Fraud Alert や block/unblock users を 2025 年 3 月 1 日に廃止する方針が明記されています。そのため、「今あるうちは使うが、依存は徐々に減らす」というスタンスが現実的です。
Q. 誤タップでブロックされたときの最短ルートは？
A. 短期的には、従来どおり Blocked users ブレードから解除するのがもっとも早いです。ただし、なぜブロックされたか（本当に誤タップか）をサインインログで確認することを忘れないでください。中長期的には、「不審なアクティビティの報告」＋ Identity Protection のリスク解除／パスワード変更を標準フローとして整備するのがおすすめです。
Q. Entra ID P2 がないと、新方式は使えないのですか？
A. いいえ、Report suspicious activity 自体は P2 でなくても有効化できます。ただし、ユーザーリスクを軸にした自動ブロック・自動復旧、リスクレポートのフル活用などは P2 の機能です。P2 が無い場合でも、サインインログと監査ログを活用した手動運用＋パスワード変更／MFA 再登録で多くのケースに対応できます。
Q. すでに条件付きアクセスを使っています。何か設定を変える必要はありますか？
A. すでに条件付きアクセスを利用している場合は、次の 2 点を確認するとよいでしょう。
- 1. リスクベース条件付きアクセスを使っているか
Entra ID P2 があるなら、「ユーザーリスク」「サインインリスク」を条件としたポリシーを作成し、不審なアクティビティの報告や他のリスク検出によって自動的にブロック・復旧できるようにします。 - 2. ブロックが過剰になっていないか
すべてのリスクで即ブロックするのではなく、「サインインリスク＝中以上なら MFA」「ユーザーリスク＝高ならパスワード変更」など、業務影響とセキュリティのバランスをとることが重要です。
まとめ：短期ワークアラウンド＋中長期の運用刷新の二段構えで
今すぐやるべきこと
- 「ブロックされたユーザー」が見えなくなっても慌てず、検索バーまたは直接 URL からブレードを開くワークアラウンドを用意する
- ヘルプデスク・管理者向けに、Blocked users へのアクセス手順を社内ポータルや手順書に明記しておく
- ブラウザキャッシュ・別ブラウザ・テナント切替など、UI 不具合時の基本的な切り分け手順を共有する
今月中に手を付けたいこと
- Report suspicious activity（不審なアクティビティの報告）を有効化し、パイロットユーザーで動作確認を行う
- ヘルプデスク向け手順書を、旧「ブロック／解除」依存フローから、リスク確認＋復旧フローに更新する
- Entra ID P2 がある場合は、ユーザーリスク・サインインリスクを利用した条件付きアクセスを設計し、「誤タップ時のリスク解除手順」もあわせて整備する
- P2 が無い場合は、サインインログを前提としたチェックリスト（見るべきカラム・イベント種別など）を整備する
今期（数ヶ月〜半年）で取り組むべきこと
- Identity Protection やサインインログの ダッシュボード／レポートを整備し、定期的に確認するサイクルを作る
- 旧 MFA Fraud Alert／ブロックされたユーザーへの依存度を段階的に下げ、最終的にはリスクベース制御＋サインインブロックに統一する
- 管理者・ヘルプデスク向けに、「誤タップ」「本物の攻撃」「誤検知」それぞれのケースでどう判断・対応するかを教育する
- 万一すべての管理者がロックアウトされた際のために、ブレイクグラス（緊急用）アカウントを準備し、リスクベースポリシーの対象外としておく
「Entra ID の MFA 画面から、突然『ユーザーのブロック／解除』が消えた」という現象は、一時的な UI 不具合と、レガシー MFA 機能の計画的なリタイアが折り重なって起きています。短期的にはワークアラウンドで運用を止めずにしのぎつつ、同時並行で 「不審なアクティビティの報告」＋ Identity Protection ベースの運用へ移行していくことが、これからの Entra ID 管理に求められる現実的なアプローチと言えるでしょう。
コメント