Microsoft は 2026年4月9日付で、Microsoft Defender for Identity センサー v3.x の前提条件ページを更新しました。結論から言うと、今回のチェックで最優先なのはインストーラーではありません。対象のドメイン コントローラーが Microsoft Defender for Endpoint にオンボード済み で、Windows Server 2019 以降、2026年3月以降の累積更新プログラム適用済み、かつ 同一サーバーに v2.x センサーが残っていない ことを先に確認するのが重要です。さらに v3.x は VPN 連携非対応、syslog 通知非対応、Azure ExpressRoute に制限あり なので、既存設計のまま置き換えられるとは限りません。 (Microsoft Learn)
重要なのは、今回の前提条件更新が単なる要件一覧の書き換えではない点です。Microsoft の現行ドキュメントを並べると、v3.x は Defender for Endpoint 前提のセンサーとして Windows Update 経由で更新され、ポータルから無停止移行でき、RPC 監査や Windows イベント監査まで含めて運用する設計に寄っています。実務目線では、Microsoft Defender for Identity の展開は「センサーを入れる作業」から「Defender プラットフォーム上で監査設定を継続管理する運用」へ進んだと捉えるのが自然です。 (Microsoft Learn)
4月9日時点の Defender for Identity センサー v3.x 前提条件
| 項目 | 4月9日時点の判断基準 | 実務上のポイント |
|---|---|---|
| 対象サーバー | v3.x の推奨対象は Windows Server 2019 以降のドメイン コントローラー | AD FS / AD CS / Microsoft Entra Connect は、現行の展開概要では v2.x 前提で見るのが安全 |
| Defender for Endpoint | 必須。Microsoft Defender Antivirus はアクティブでもパッシブでも可 | MDE 未導入なら v3.x 展開の入口に立てていない |
| パッチ基準 | 2026年3月以降の累積更新プログラムが必要 | 古い検証メモや概要ページの条件で判断しない |
| 共存可否 | 同一サーバーに v2.x センサーがある状態では v3.x を有効化できない | 「しばらく両方入れる」は不可 |
| 権限 | Microsoft Entra ID テナントと、Security Administrator もしくは対応する Unified RBAC 権限が必要 | セキュリティ担当と AD 担当の役割分担を先に決める |
| ネットワーク | MDE と同じ URIs を利用。VPN 連携と syslog 通知は非対応、ExpressRoute には制限 | 接続要件と通知設計の見直しが必要 |
| 仮想化・性能 | VM はメモリを常時確保。v3.x は CPU 30%、メモリ 1.5GB に上限を設けるが、他製品の負荷は残る | 仮想 DC や他社 ID 監視製品併用時は容量確認が必要 |
| 導入後設定 | RPC 監査、Windows イベント監査、必要に応じた gMSA 撤去までが実作業 | 「Running」表示だけで完了扱いにしない |
この整理は、4月9日更新の v3.x 前提条件ページ、展開概要、センサー管理、Windows イベント監査の各ドキュメントを基にまとめています。 (Microsoft Learn)
特に見落としやすいのが累積更新プログラムの基準です。GitHub の公開履歴では、v3.x 前提条件ページの CU 条件は 2026年3月15日に 「2025年10月以降」から「2026年3月以降」へ更新 されています。一方、展開概要ページは 2026年3月5日時点でなお 「2025年6月以降」 の表現を残しています。社内 runbook や導入手順書を作るなら、概要ページより専用の prerequisites ページを基準にした方が安全です。 (GitHub)
v3.x 前提条件が示す、アイデンティティ監視の次の段階
まずはっきりしているのは、v3.x が Defender for Endpoint を土台にした構成 へ寄っていることです。前提条件ページでは v3.x が MDE 展開済みサーバーを要求し、ネットワーク要件も MDE と同じ URIs を参照します。さらにセンサー管理ドキュメントでは、v3.x は MDE のコンポーネントとして提供され、更新は Windows Update で自動配布されるとされています。v2.x の「MDI センサー個別更新」よりも、Defender 全体の運用基盤に乗せる設計です。 (Microsoft Learn)
次に大きいのが、可視化が「インストール後の追加設定」ではなく「検知品質の前提」に変わっている点です。v3.x では Unified Sensor RPC Audit タグで可視性と追加検知を有効化でき、Microsoft は 2026年の更新情報で、Enhanced RPC auditing が一部の高度な ID 検知に必要だと明記しています。Windows イベント監査も v3.x では自動構成機能がプレビューで用意され、設定の抜けを検出して修正し、関連する health alert も出します。つまり v3.x は、「センサーが動いているか」より「必要な監査が継続適用されているか」まで見ないと本来の価値が出ません。 (Microsoft Learn)
さらに、v3.x では Network Name Resolution が Defender のデバイス インベントリとセンサー収集イベントを使って行われ、v2.x のように追加ポートを前提としない設計になっています。ここから読み取れるのは、Microsoft が ID 監視を「ポートを開けてセンサーを置く」モデルから、「Defender 側で統合的に状態管理する」モデルへ寄せているということです。 (Microsoft Learn)
もう一つ重要なのは、Microsoft が v3.x を本命ルートとして育てていることです。2026年3月の更新では、v2.x から v3.x への移行が Defender ポータルから直接実行でき、切り替え中も v2.x が稼働を続けるため無停止で進められると案内されています。Sensors ページには Ready for migration / Not ready for migration / Up to date などの状態も用意され、前提条件を満たしているかを運用画面から判断できます。 (Microsoft Learn)
Microsoft Defender for Identity 展開で先にやる実務手順
対象サーバーを「v3.x 候補」と「classic sensor 継続」に分ける
最初にやるべきは、ID 関連サーバーを一括で v3.x 化しようとしないことです。現行の展開概要では、v3.x の推奨展開先は Windows Server 2019 以降のドメイン コントローラー で、AD FS / AD CS / Microsoft Entra Connect は引き続き v2.x の枠で案内されています。Activation ページでも、条件を満たした DC には Activate new sensor、そうでない場合は Install classic sensor や OS upgrade is required が表示されます。ここで無理に v3.x に寄せるより、役割ごとに進路を分けた方が失敗しません。 (Microsoft Learn)
MDE と Windows パッチを先に揃える
v3.x は MDE 前提です。つまり、作業の順番は「MDI ポータルを見る」より先に「MDE にオンボードされているか」「必要な接続先へ出られるか」「2026年3月以降の累積更新プログラムが入っているか」をそろえる方が正解です。なお、Microsoft Defender Antivirus コンポーネントはアクティブ モードでもパッシブ モードでもよいので、他社 AV を使っている環境でも MDE 展開済みであれば前提条件は満たせます。 (Microsoft Learn)
readiness スクリプトで事前診断する
Microsoft は Test-MdiReadiness.ps1 の実行を推奨しており、このスクリプトは Identities > Tools ページからも入手できます。加えて、Windows イベント監査の抜け漏れ確認には New-MDIConfigurationReport によるレポート生成が有効です。展開前にスクリプトで差分を可視化しておくと、「有効化はできたが検知が薄い」という一番やっかいな状態を避けやすくなります。 (Microsoft Learn)
まず 1 台でアクティブ化し、表示時間を見込む
実際の有効化は Defender ポータルの System > Settings > Identities > Activation から行えます。ここで安心材料になるのは、アクティベーションに再起動は不要 だという点です。ただし、最初の 1 台は Sensors ページに Running と表示されるまで最大 1 時間かかることがあり、2 台目以降は通常 5 分以内です。変更作業の説明では「再起動の有無」だけでなく「表示反映までの待ち時間」もセットで伝えておくと、現場の混乱を減らせます。 (Microsoft Learn)
RPC 監査と Windows イベント監査をすぐに入れる
v3.x では、センサー有効化の直後に RPC 監査 と Windows イベント監査 を入れるのが実務上の本番開始ラインです。Unified Sensor RPC Audit タグは Asset Rule Management で条件に一致した既存・将来デバイスへ適用でき、反映まで最大 1 時間かかります。Windows イベント監査は v3.x 向けに自動構成機能があり、設定ギャップの検出・修正や health alert 送信まで行いますが、これはプレビューかつ段階展開です。UI がまだ見えないテナントでは、手動または PowerShell での構成を前提にしてください。さらに Microsoft は、Enhanced RPC auditing が一部の高度な ID 検知に必要だと案内しています。ここを飛ばすと、v3.x を入れても検知品質が伸びません。 (Microsoft Learn)
v2.x から移行するなら、gMSA と旧センサーの後片付けまで実施する
v2.x からの移行自体は無停止で進められますが、そこで終わりではありません。Microsoft は、v3.x が ローカル システム ID を使って Active Directory と response actions を処理すると明記しており、以前のバージョンで gMSA を使っていた場合は削除が必要です。gMSA が残ると response actions が動きません。さらに、移行後も v2.x ソフトウェアはサーバー上に残るため、アンインストールと、他用途で使っていないなら Npcap の削除までやって初めて整理完了です。 (Microsoft Learn)
失敗しやすいポイント
- 古い資料の CU 基準で判定する
社内手順書や過去の検証メモに引っ張られると、必要パッチが足りないまま進みやすいです。現行の専用 prerequisites ページは 2026年3月以降の CU を示しており、GitHub 履歴でもこの基準引き上げが確認できます。 (GitHub) - syslog 通知や VPN 連携がそのまま使える前提で移行計画を組む
v3.x は syslog 通知も VPN 連携もサポートしません。既存の通知フローや接続方式に依存している環境は、移行前に代替運用を設計しておく必要があります。Azure ExpressRoute にも制限があります。 (Microsoft Learn) - 「追加ポート不要」と「設定しなくてよい」を混同する
v3.x の NNR は追加ポートなしで動きますが、それで監査設定が不要になるわけではありません。Microsoft は Enhanced RPC auditing が一部の高度な検知に必要だと案内しており、Windows イベント監査も自動構成や health alert を前提に設計されています。さらに自動 Windows イベント監査は GPO と競合する場合があります。 (Microsoft Learn) - 仮想 DC のメモリ設定をそのままにする
Hyper-V の Dynamic Memory を有効にしたまま、あるいは VMware で予約メモリを確保しないまま進めるのは危険です。v3.x には CPU 30%、メモリ 1.5GB の上限制御がありますが、それは余裕を保証する数字ではありません。Microsoft も、Falcon Identity が既に大きなリソースを使っている場合は DC に負荷が出る可能性があると明記しています。 (Microsoft Learn) - 移行後の gMSA と v2.x の残骸を放置する
v3.x で response actions を使うなら、旧来の gMSA 前提を残したままにしないことが重要です。混在期間を作る場合も、Microsoft はローカル システム アカウントにそろえるよう案内しています。 (Microsoft Learn)
次に取るべき行動
今すぐやるべきことは、難しくありません。
- まず、現在のドメイン コントローラーを洗い出し、Windows Server 2019 以降か、MDE オンボード済みか、v2.x が残っていないか で分類します。AD FS / AD CS / Microsoft Entra Connect は別枠で管理し、現時点では v2.x 前提の扱いにしておくのが安全です。 (Microsoft Learn)
- 次に、v3.x 候補サーバーへ 2026年3月以降の累積更新プログラム をそろえ、Test-MdiReadiness.ps1 と Windows イベント監査のレポートで事前診断します。ここで赤信号が出るサーバーを先に潰す方が、後工程で詰まりません。 (Microsoft Learn)
- そのうえで代表 DC を 1 台だけパイロットで有効化し、RPC 監査 と Windows イベント監査 を適用し、Sensors ページで状態を確認してから横展開します。v2.x から移る場合は、Ready for migration のサーバーから順に進めるのが最も現実的です。 (Microsoft Learn)
今回の前提条件更新が示しているのは、Defender for Identity v3.x が「入れられるかどうか」を問う段階ではなく、「Defender プラットフォーム上で継続的に正しく監査・更新・移行できるか」を問う段階に入った、ということです。この前提で設計し直せるかどうかが、2026年以降のオンプレミス ID 監視の差になります。 (Microsoft Learn)
コメント