Microsoft Entra ID（旧Azure AD）やMicrosoft 365を本格運用していると、「WindowsログオンをMFAにしたい」「管理者がMFAでロックされた」「Purviewの操作ログを取りたい」など、同じような悩みが何度も出てきます。本記事では、Microsoft Learn のQ&Aに実際に寄せられた10個の代表的な質問をベースに、問題のポイントと実務的な解決策をまとめて解説します。
Microsoft Entra ID／MFAで頻出する10の課題と全体像
まずは、本記事で扱う10のケースと、その要点をざっくり俯瞰しておきます。
| ケース | 主なテーマ | 解決の方向性（要約） |
|---|---|---|
| 1 | WindowsログオンにMFAを付けたい | ログオン画面にクラウドMFAを直接挟むことは不可。Windows Hello for Business＋Cloud Kerberos trustやRD Gateway＋MFAで実現する。 |
| 2 | 管理者のMFAがエラーでロック | Phone Reputationにより電話番号がブロックされる場合あり。Microsoftサポートでバックエンド解除＋管理者のブレークグラス運用を整備。 |
| 3 | 個人アカウントでOTPが届かない | 個人利用でもPhone ReputationでMFAがブロックされることがある。サポートに個別情報を共有し解除依頼。今後はAuthenticatorやパスキー優先。 |
| 4 | 電話／SMSのMFAは今後も使えるのか | 機能としては継続。Per-user MFAや旧SSPR設定から「認証方法ポリシー」への移行がテーマ。 |
| 5 | Windows Defender Firewallの設定 | 既定ルールを消さないのが大前提。既定の「受信ブロック／送信許可」をベースに、必要最小限の追加ルールでハードニング。 |
| 6 | Entra Registered → Hybridへの切替 | いったん登録解除してから、Azure AD参加／ハイブリッド参加としてクリーンに再参加させる。 |
| 7 | iadispatcher（ブラウザハイジャッカー）除去 | Defenderの最新定義でフルスキャン＋Microsoft Safety Scanner。ブラウザ拡張やポリシーも含めてクリーンアップ。 |
| 8 | Azure AD B2Cエラーの翻訳 | 一部のMFAサービス起因エラーは現時点で翻訳不可。UI側でメッセージを補完し、フィードバックで要望を出す。 |
| 9 | 管理者MFAロックアウトとDPT対応 | データ保護チーム（DPT）の調査で1週間以上かかることも。電話サポート＋別アカウントでのチケット起票・ブレークグラス必須。 |
| 10 | Microsoft Purviewのアクセス／API監査 | 統合監査ログ＋Purview監査を有効化し、Microsoft GraphのAudit Logs APIやOffice 365 Management APIで収集、SIEMに連携。 |
ここからは、各ケースごとに「よくある勘違い」「実際に取るべきアクション」「設計としてどう落とし込むか」を掘り下げます。
ケース1：WindowsワークステーションのログオンにMFAを付けたい
Ctrl+Alt+Del画面にクラウドMFAは挟めない
よくある相談が「Ctrl+Alt+DelでログオンするときにMicrosoft Authenticatorの承認やOTP入力を必須にできないか？」というものです。
結論として、Microsoft Entra ID（旧Azure AD）の標準機能だけで、Windowsの対話型ログオン画面にクラウドMFAを直接挿し込むことはできません。Windowsログオンはローカル／ドメイン認証の仕組み（Credential Provider）で動作しており、そこにEntra MFAをそのまま差し込むAPIは提供されていないためです。
そのため、Microsoftの推奨は次のような構成になります。
- 端末の対話型ログオン：Windows Hello for Business（WHfB）によるパスワードレス（顔＋PIN、指紋＋PINなど）
- リモートアクセス（RDP/VPNなど）：RD Gateway＋NPS拡張、またはVPN＋MFAでクラウド側MFAを要求
- 社内SaaSアクセス：条件付きアクセス（CA）で、重要アプリに対してMFA必須や準拠デバイス必須を要求
Windows Hello for BusinessとCloud Kerberos trust
オンプレミスのActive DirectoryとEntra IDを併用しているハイブリッド環境では、Windows Hello for Businessを「Cloud Kerberos trust」モデルで展開するのが最新の推奨です。
- PKIやユーザー証明書なしに、クラウド側のEntra Kerberosオブジェクトを使ってオンプレ資源へKerberos認証を届けられる
- パスワードレス（PIN＋生体認証）でサインインしつつ、社内ファイルサーバーやプリンターなどへのSSOが可能
- 従来の「Key trust」「Certificate trust」より構成が簡単で、将来的なパスワードレス戦略と整合しやすい
実務的には、次のようなステップで検討すると整理しやすくなります。
- Entra ID Connect（旧Azure AD Connect）やEntra Connect Syncでユーザー／デバイス同期を確認
- WHfBをテナント全体またはグループ単位で有効化し、Cloud Kerberos trust用のポリシーを配布（Intune または GPO）
- パイロットユーザーで登録・サインイン体験を検証（PIN／生体→オンプレ共有フォルダなどがシームレスに使えるか）
- 段階的に対象ユーザーを拡大し、最終的にパスワード入力を例外ケース（トラブル時など）に限定
リモートデスクトップにMFAをかける設計
一方、RDPを使ったリモート接続にはMFAを強くかけたいところです。ここでは、Windowsログオン画面ではなく、その手前の「接続ゲートウェイ」にMFAを挟むイメージで設計します。
| 要件 | 推奨構成 | ポイント |
|---|---|---|
| インターネット越しRDPにMFA必須 | RD Gateway＋NPS拡張（Azure MFA Extension） | RDPポートは直接公開せず、RD Gatewayのみを公開し、そこでMFAを要求する。 |
| VPN経由でRDP | VPN接続時にMFA必須＋社内からのRDPは社内ネットワーク限定 | VPNクライアントには条件付きアクセスでMFAを要求。RDP自体は内部利用に絞る。 |
| 社内のみ利用だが重要サーバー | ジャンプサーバー＋MFA（RD Gateway） | 重要サーバーには直接RDPせず、MFA付きジャンプホスト経由で運用。 |
まとめると、「Windowsログオン画面そのものにクラウドMFAは入らないので、端末側はWHfBでパスワードレス化し、リモート系はゲートウェイ側でMFAを挟む」という二段構えで考えるのが現実的です。
ケース2：管理者アカウントのMFAがエラーになり解除できない
Phone Reputation によるSMS／音声MFAブロック
管理者アカウントでMFA再登録をしようとしたところ、SMSや音声通話の認証がエラーになり、本人確認が進まないケースがあります。最近は、Microsoft側で電話番号に対して「Phone Reputation」が導入されており、不審な通話／SMSパターンが検知されると、その番号をブロックする仕組みがあります。
この「悪評（Bad reputation）」状態になると、本人は何度やり直しても SMS／音声によるMFAが通らず、管理ポータルにも入れなくなります。特に管理者が1人だけのテナントでは致命的です。
Microsoftによるバックエンド解除＋Authenticatorへの移行
Q&Aで共有されている事例では、Microsoftサポートに詳細情報（テナントID、エラーコード、電話番号など）を伝え、バックエンドで「ブロック解除＋Phone Reputationのクリア」を行ってもらうことで復旧しています。
復旧後は再発防止のため、次のような対策が推奨されます。
- 管理者は必ずMicrosoft Authenticatorアプリを登録し、プッシュ通知＋番号マッチングをメインにする
- SMS／音声通話はあくまで予備手段（通信障害などのバックアップ）として扱う
- 複数の認証方法（Authenticator、FIDO2セキュリティキー、電話など）を管理者ごとに2～3種類登録しておく
ブレークグラス（緊急用）アカウント運用の必須化
MFA関連のロックアウトに対して、最も重要なのは「普段は使わない緊急用アカウント」を用意しておくことです。ブレークグラスアカウントの基本要件は以下のようになります。
- テナント内に少なくとも2つ用意（冗長化）
- Global Administrator を付与しつつ、条件付きアクセスの対象外にしておく
- MFAはあえて要求しない（代わりに、極端に長いランダムパスワードを設定）
- 日常利用禁止、サインインログは定期的に監査し、不審な利用がないか確認
- パスワードはオフラインで厳重に保管し、年に1回程度はテストログオンを実施
| 観点 | 通常管理者 | ブレークグラス管理者 |
|---|---|---|
| MFA | 必須（Authenticator＋FIDO2） | 原則なし（利用頻度が低く攻撃面も限定的） |
| 利用頻度 | 日常の運用に使用 | 非常時のみ。ログイン履歴は毎月確認 |
| 保護方法 | 条件付きアクセス、RA（特権 ID 管理） | 超長パスワード＋オフライン保管 |
ケース3：個人アカウントでOTPが届かない（エラー 399287）
Azure ポータルに個人アカウントでサインインしている場合でも、MFAで利用している電話番号がPhone Reputationによりブロックされ、「SMSが送れません」「エラー399287」などのエラーで先に進めない事例が報告されています。
個人利用ゆえの難しさと、サポートへの情報提供
企業テナントであれば、管理者が別アカウントからサインインし、対象ユーザーのMFAをリセットすることができます。しかし、個人アカウント（例：@outlook.com、@hotmail.comなど）でAzureを使っている場合、自分自身が管理者でもありエンドユーザーでもあるため、セルフ救済がほぼ不可能になります。
このようなケースでは、Microsoftのサポートに対して次のような情報を私信（公開されないチャネル）で伝え、電話番号のブロック解除を依頼するアプローチになります。
- 問題が起きているサインインID（メールアドレス）
- エラー画面のスクリーンショット／エラーコード（399287 など）
- 電話番号（国コード付き）、国／地域、タイムスタンプ
- 可能であれば、テナントIDやサブスクリプションID
個人アカウントでもやっておきたい対策
個人利用でも、次のような対策をしておくとロックアウトリスクをかなり下げられます。
- Microsoft Authenticatorアプリを必ず登録し、プッシュ通知をメインにする
- Authenticator内でも、クラウドバックアップを有効化し、端末紛失時の復元を容易にしておく
- 電話番号に加えて、別メールアドレス（予備メール）もセキュリティ情報として登録
- 重要なリソースを扱う場合は、FIDO2 セキュリティキーやパスキーも検討する
ケース4：電話／テキストのMFAは今後も使えるのか？
「廃止」ではなく「設定場所が変わる」話
「古いMFA方式が廃止される」といった表現を見て、「SMSや電話でのMFAが使えなくなるのでは？」と心配されることがあります。しかし現時点では、電話／SMSによるMFAそのものがサポート終了するという話ではなく、
- Per-user MFA（ユーザーごとのMFA有効／無効設定）
- 旧SSPR（セルフサービスパスワードリセット）の認証方法設定
といったレガシーな設定場所から、「認証方法ポリシー」へ統合・移行していくという位置付けです。
認証方法ポリシーで電話／SMSを有効化する
今後も電話／SMSのMFAを使い続けたい場合は、Entra 管理センターの次のパスを確認しておきましょう。
- Entra ID > セキュリティ > 認証方法 > ポリシー
ここで「SMS」「音声通話」などのメソッドを有効化し、対象ユーザーやグループを指定します。これにより、将来Per-user MFAが段階的にフェードアウトしても、認証方法ポリシー側で継続利用できます。
| 認証方法 | 主な用途 | 優先度の目安 |
|---|---|---|
| Microsoft Authenticator（プッシュ＋番号マッチング） | 管理者／一般ユーザーのメインMFA | 最優先 |
| FIDO2 セキュリティキー／パスキー | 高セキュリティユーザー、パスワードレス | 最優先（対応可能な場合） |
| SMS／音声電話 | スマホアプリが使えない場合のバックアップ | 補助的に利用 |
ゼロトラストの観点では、フィッシング耐性が高いAuthenticatorの番号マッチングやFIDO2／パスキーをメインに据え、電話／SMSは「最後の砦」として温存するような方針が現実的です。
ケース5：Windows Defender ファイアウォールの既定設定とハードニング
既定ルールは削除しないのが大原則
強化端末（ハードニング済みラップトップなど）の設計で、「Windows Defender ファイアウォールの既定ルールは全部消して、ホワイトリストだけにするべきか？」という質問もよくあります。
Microsoftのセキュリティベースラインでは、基本方針として次のようなスタンスが取られています。
- ファイアウォールはすべてのプロファイル（ドメイン／プライベート／パブリック）で有効
- 受信は既定でブロック／送信は既定で許可がベース
- OSやWindows Updateなどのコア機能を動かすためのビルトイン規則は削除・無効化しない
- 必要に応じて、追加の受信許可ルールや送信制限ルールを足していく
| 項目 | 既定値（推奨） | コメント |
|---|---|---|
| 受信接続 | ブロック（明示的な許可のみ通す） | サーバー用途以外では基本的にこのままで問題なし。 |
| 送信接続 | 許可 | 一律ブロックは運用負荷が高く、アプリケーションが壊れやすい。 |
| 既定ルール | 維持 | 削除するとWindows Updateやドメイン参加などに影響する。 |
高機密端末での追加ハードニング
ただし、機密度の高い端末や特定用途のサーバーでは、送信方向も厳しく制御したくなるケースがあります。その場合は、いきなり「送信すべてブロック」ではなく、以下のような段階的アプローチが現実的です。
- ファイアウォールログを有効化し、一定期間どのプロセスがどこに通信しているかを可視化
- 業務上必要な通信を洗い出し、アプリケーションごとの許可ルールを作成
- 監査モード的に送信ブロックルールを少しずつ追加し、影響を検証
- ASR（攻撃面の縮小）ルールやWDAC（Windows Defender Application Control）でアプリ側の制御も併用
エンドポイント防御は、ファイアウォール単体よりも、Defenderのエンドポイント保護＋ASR＋WDAC＋セキュリティベースラインを組み合わせることで、運用とセキュリティのバランスを取りやすくなります。
ケース6：Entra「Registered」デバイスをハイブリッド参加に切り替える
Registered と Joined の違いを整理
Entra IDにはデバイス状態として大きく次の3種類があります。
- Registered（登録済み）：BYODなど、個人所有デバイスに職場／学校アカウントを追加した状態
- Azure AD joined（Entra ID参加）：クラウド専用端末（ドメインに参加していない）
- Hybrid joined（ハイブリッド参加）：オンプレADのドメイン参加かつEntra IDにも登録された状態
「Registered になっている端末を、後からHybrid joinedにしたい」という場合、基本的な考え方は登録状態を一度きれいに解除してから、狙った参加方式でやり直すことです。
切り替えの実務手順（典型例）
- 対象端末で
- [設定] > [アカウント] > [職場または学校にアクセスする] から、登録されているアカウントを切断
- Entra 管理センターのデバイス一覧から、該当端末の「Registered デバイス」を削除
- オンプレADに参加させる場合は、通常通りドメイン参加を実施
- ハイブリッド参加用に構成された GPO または Intune ポリシーを適用し、デバイスが Entra ID に Hybrid joined として登録されるのを待つ
dsregcmd /statusコマンドで、AzureAdJoined / DomainJoined / DeviceIdなどの状態を確認- 必要に応じて、Intune／MDMポリシーを再適用し、コンプライアンス状態を確認
途中で「Registered と Hybrid joined が混在して二重登録」のような状態になると、条件付きアクセスやアプリ配布が想定通りに効かない場合があります。クリーンブレイクしてから再参加させる、という方針を守るとトラブルを避けやすくなります。
ケース7：ブラウザハイジャッカー「iadispatcher」を削除したい
症状：Chromeだけ検索が ext.iadispatcher.com 経由になる
「ext.iadispatcher.com がURLの前後に挟まれて、検索結果が表示されない」「Chromeだけおかしいが、Edgeは正常」といった症状は、典型的なブラウザハイジャッカー／アドウェアの挙動です。
この種のマルウェアは、ブラウザの拡張、スタートページ、検索エンジン設定、さらにはグループポリシーやレジストリを通じて、継続的に設定を乗っ取ろうとします。
推奨される除去手順
Microsoftの回答では、まずMicrosoft DefenderとMicrosoft Safety Scannerの利用が推奨されています。実務上は、次のような手順を順番に実行するとよいでしょう。
- Windows Updateで最新状態にし、Defenderのウイルス定義も最新に更新
- Defenderでフルスキャンを実行し、検出された脅威をすべて隔離・削除
- それでも症状が残る場合は、Microsoft Safety Scanner（msert.exe）をダウンロードしてオフラインスキャン
- 「アプリと機能」から、見覚えのないツールバーや検索ツール、フリーソフトなどをアンインストール
- Chrome／Edgeなどブラウザごとに
- 不審な拡張機能をすべて削除
- 検索エンジン・スタートページを既定値にリセット
- 必要に応じて「設定のリセット」を実行
- 企業環境では、Defender for Endpoint や他のEDRで他端末への横展開がないかを確認し、必要ならインシデントとしてSOCにエスカレーション
| 環境 | 対応レベル | 推奨アクション |
|---|---|---|
| 個人PC | 端末単体のクリーンアップ | Defender＋Safety Scanner＋ブラウザリセット。必要ならOS再インストールも検討。 |
| 企業端末 | インシデント対応 | EDRアラート確認、IOCで全端末をスキャン、ポリシーや管理者アカウントの不正変更有無も確認。 |
ケース8：Azure AD B2C カスタムポリシーでも翻訳できないエラーメッセージがある
すべてのエラー文言はコントロールできるわけではない
Azure AD B2C（今後はEntra External IDへの移行が推奨されつつあります）では、カスタムポリシーを使うことで大半のエラーメッセージやUI文言をローカライズできます。しかし、Q&Aでも指摘されている通り、
- MFAサービス側が動的に生成する一部のエラーメッセージ
- バックエンドの技術的エラー（トランザクションIDや内部コードを含むもの）
など、現時点ではローカライズや置換ができないメッセージも存在します。
UXを損ねないための現実的な工夫
完全に書き換えられない以上、実務的には次のような方向で「ダメージコントロール」するのが現実的です。
- サインイン画面・サインアップ画面に「よくあるトラブルと対処」を目立つ位置に記載
- エラー発生時に遷移させる「カスタムエラーページ」を用意し、
- 汎用的な説明（「認証に失敗しました」など）
- サポート問い合わせへのリンク
- トランザクションIDや時間をコピーできるUI
- よく出るエラーコードについては、FAQやヘルプセンターで日本語の解説ページを用意
また、「すべてのエラーメッセージを翻訳したい」といった要望は、Microsoftのフィードバックポータルやサポートを通じて継続的に投げておくとよいでしょう。将来のEntra External IDへの移行を検討する際にも、必要なローカライズ要件を一覧化しておくと比較がしやすくなります。
ケース9：管理者がMFAロックアウトした場合のDPT対応と待ち時間
DPT（Data Protection Team）の調査は時間がかかる
MFAで完全にロックアウトし、もはや誰もテナントにサインインできない状態になると、Microsoftの「データ保護チーム（DPT）」の介入が必要になる場合があります。これはユーザーデータやセキュリティに関わるデリケートな操作であるため、簡単に解除されるものではありません。
Q&Aの報告では、DPTによる調査と対応に8～10日程度かかったケースもあり、「急ぎで何とかしてほしい」という声が多く上がっています。
緊急時に取れるアクション
完全ロックアウト時でも、できることはあります。
- 国別のサポート窓口へ電話し、状況を詳しく説明する
- もし別のアカウント（パートナーや別テナントの管理者など）でサインインできるなら、そのアカウントでサポートチケットを起票
- テナントID、ドメイン名、課金情報、エラー画面のスクリーンショットなど、本人確認に必要な情報をあらかじめまとめておく
- ケース番号を控え、進捗を定期的に確認する
根本対策：ブレークグラス運用とMFA設計の見直し
このケースも、結局はケース2と同様に「ブレークグラスアカウントが事前にあれば致命的なロックアウトは避けられた」という話に行き着きます。
- ブレークグラスアカウントを2つ以上
- 普段は使わない・サインインログを監査する
- 通常管理者アカウントのMFA方法を多重化し、SMSのような脆弱な手段に依存しない
特にゼロトラストの観点では、「誰か一人のスマホにすべてを託す」設計は避けるべきです。組織として、IDセキュリティの冗長化を意識した設計を行いましょう。
ケース10：Microsoft Purviewへのアクセス／API呼び出しを監査したい
Unified Audit Logging と Purview 監査
「誰がPurviewポータルにアクセスしたか」「データマップのAPIを叩いたのはどのアプリか」といった情報は、統合監査ログ（Unified Audit Log）とPurview監査で取得します。Microsoft 365 E5 や一部のSKUでは、長期保持や詳細なログ（Audit Premium）が利用可能です。
まず確認すべきポイントは次のとおりです。
- Purview コンプライアンスポータルの [監査] で「監査が有効」になっているか
- 必要なライセンス（Audit Standard / Premium）が付与されているか
- 監査ログの保持期間が要件を満たしているか（90日、180日、1年、10年など）
API でログを取得する方法
取得した監査ログは、次のようなAPIでプログラムから取得できます。
- Microsoft Graph Audit Logs API
/auditLogs/directoryAuditsや/auditLogs/signInsなどで、ユーザー／サービスプリンシパルの操作やサインインを取得 - Office 365 Management Activity API
Audit.General などのサブスクリプションを開始し、HTTPで監査データをポーリング
Purview のAPI呼び出しは、Unified Audit Log上では一般にPurviewDataMapOperationなどのアクティビティとして記録されます。これをフィルタリングすることで、「どのユーザー／アプリ（サービスプリンシパル）が、どのIPから、どんな操作を行ったか」を追跡できます。
| ログ種別 | 主な用途 | 例 |
|---|---|---|
| DirectoryAudits | 設定変更やロール付与などの管理操作 | Purviewロールの割り当て、ポリシー変更など |
| SignIns | ユーザー／アプリのサインイン | Purviewポータルへのサインイン、サービスプリンシパルのトークン取得 |
| PurviewDataMapOperation | PurviewデータマップへのAPI操作 | スキャン設定の変更、スキーマの更新など |
SIEM連携と運用設計
監査ログは、「取れるようにしただけ」では意味がありません。実務では、次のような運用設計が重要になります。
- Microsoft Sentinel や他社SIEMへ監査ログを継続的に送信
- 「Purviewの管理者ロール追加」「大量のラベル変更」「短時間での多数のAPI操作」などに対する検出ルール・アラートを定義
- 重大インシデント時に参照するための「監査ログの保全・エクスポート手順」を文書化
横断的に見直したいセキュリティ運用チェックリスト
ここまでの10ケースは、一見バラバラですが、背後にあるテーマはかなり共通しています。最後に、すぐにでも見直しておきたい横断的なチェックポイントをまとめます。
認証まわり（MFA・パスワードレス）
- 重要アカウント（管理者・経理・情報システム）は、Authenticator（プッシュ＋番号マッチング）やFIDO2／パスキーを主手段にしているか
- SMS／音声MFAは「バックアップ用」に位置付けられているか
- ブレークグラスアカウントが2つ以上用意され、定期的にテストされているか
- Per-user MFA 依存から、認証方法ポリシー＋条件付きアクセスの構成へ移行が進んでいるか
エンドポイント・OSセキュリティ
- Windows Hello for Business（Cloud Kerberos trust 等）を使ったパスワードレス化を計画・展開しているか
- Windows Defender ファイアウォールは既定設定を維持しつつ、必要最小限の追加ルールで運用しているか
- Defender、ASR、WDACなどの機能を活用し、マルウェアやブラウザハイジャッカーに対する防御が多層化されているか
ログ・監査・可視化
- 統合監査ログ（Unified Audit Log）が有効化されているか、保持期間は要件を満たしているか
- Microsoft Graph／Management APIなどで監査ログを取得し、SIEMに集約する仕組みがあるか
- PurviewやEntra管理者の操作に対する検知ルールが定義されているか
インシデントレスポンス体制
- 管理者のMFAロックアウトやテナントアクセス不能時に実行する標準手順書（Runbook）があるか
- Microsoftサポート・パートナー・社内SOCなど、誰にどうエスカレーションするかが定義されているか
- インシデント後に、再発防止策（認証方法の追加、ブレークグラス整備、ログ保全強化など）を必ず実施しているか
これらのチェックポイントを1つずつ潰していくことで、本記事で紹介したような「よくある10のつまずき」を、事前にかなりの割合で回避できるようになります。Entra IDやMicrosoft 365は機能が多い分、設計と運用の差がそのままセキュリティレベルの差になります。自組織の状況にあわせて、優先順位を付けて改善を進めていきましょう。
コメント