Defender for Identity センサー v3.xのアクティブ化は、単に「ドメイン コントローラーで有効化ボタンを押す」作業ではありません。結論から言うと、Windows Server 2019以降のドメイン コントローラーで、Microsoft Defender for Endpointのオンボード、2026年3月以降の累積更新プログラム、権限、ネットワーク接続、監査設定まで確認したうえで進める必要があります。特にv2.xセンサーとの混在、gMSA/DSAの扱い、VPN統合やsyslog通知の非対応は、移行後の検知・応答運用に影響しやすいポイントです。Microsoft Learnの2026年6月2日更新情報では、v3.xの前提条件、アクティブ化後の監査設定、RPC監査、LocalSystem利用などが整理されています。(Microsoft Learn)
この記事では、Microsoft Defender for Identity センサー v3.xをドメイン コントローラーでアクティブ化する際に、管理者が何を確認し、どの順番で展開すべきかを実務目線で整理します。既存のv2.x環境から移行する場合の注意点も含めて解説するため、Active Directory基盤を守る担当者は、作業前チェックリストとして活用してください。
Defender for Identity センサー v3.xとは何が変わるのか
Microsoft Defender for Identityは、オンプレミスActive Directory環境の認証、アカウント、横展開、権限昇格の兆候などを監視するためのMicrosoft Defender系サービスです。今回のポイントは、ドメイン コントローラー向けにDefender for Identity センサー v3.xをアクティブ化する流れが、Microsoft Defenderポータル上の「Activation」ページを中心に整理されたことです。
従来のv2.xセンサーでは、専用インストーラーやサービス アカウント、センサー単位の更新運用を意識する場面が多くありました。一方、v3.xではMicrosoft Defender for Endpointとの連携が前提になり、対象サーバーの状態に応じて、アクティブ化、クラシック センサーの利用、OSアップグレードが判断しやすくなっています。Activationページではデバイス インベントリからサーバーが表示され、対象となるドメイン コントローラーを自動または手動でアクティブ化できます。(Microsoft Learn)
ただし、v3.xがすべての環境を置き換えるわけではありません。古いOSのドメイン コントローラーや、ドメイン コントローラーではないAD FS、AD CS、Microsoft Entra Connectサーバーでは、引き続きDefender for Identity センサー v2.xを使う前提で整理されています。(Microsoft Learn)
まず押さえるべき影響範囲
Defender for Identity センサー v3.xのアクティブ化で影響を受けるのは、セキュリティ管理者だけではありません。Active Directoryを運用するインフラ担当、Microsoft Defender for Endpointの管理者、監査ログを利用するSOC、AD FSやAD CSを扱うID基盤担当、社内認証と連携するアプリケーション管理者にも関係します。
| 確認対象 | 主な影響 | 実務で見るポイント |
|---|---|---|
| ドメイン コントローラー | v3.xセンサーの主な展開対象 | OS、累積更新プログラム、MDEオンボード状況 |
| 既存v2.xセンサー | 移行可否の判断が必要 | 純粋なDCか、追加IDロールがあるか |
| AD FS / AD CS / Entra Connect | サーバー種別で対応が分かれる | DC上のロールか、非DCサーバーか |
| gMSA / DSA | v3.xではLocalSystemが前提 | 混在時の正常性アラート、応答アクション |
| SOC / SIEM連携 | syslog通知などの制限に注意 | 既存の通知・転送設計を棚卸し |
| 開発・業務アプリ | 認証基盤の監視・監査設定変更の影響 | AD連携アプリの認証失敗やログ量変化を確認 |
特に注意したいのは、v3.xでVPN統合とsyslog通知がサポートされない点です。また、Azure ExpressRoute利用環境には制限があり、Windows Server 2025上のドメイン コントローラーをv2.xからv3.xへ移行することも現時点ではサポートされていません。(Microsoft Learn)
v3.xを使えるサーバーと使えないサーバー
Defender for Identity センサー v3.xの対象を考えるときは、「新規アクティブ化」と「既存v2.xからの移行」を分けて判断します。この2つを混同すると、移行画面で「準備ができていない」と表示されたり、v2.xを残すべきサーバーまでv3.x化しようとして作業が止まったりします。
| サーバーの状態 | 推奨される対応 | 注意点 |
|---|---|---|
| Windows Server 2019以降のドメイン コントローラー | v3.xセンサーのアクティブ化対象 | MDEオンボードと2026年3月以降の累積更新が必要 |
| AD FS / AD CS / Entra Connectも実行するドメイン コントローラー | 新規展開ではv3.x対象 | 既存v2.xからのインプレース移行とは分けて判断 |
| 古いOSのドメイン コントローラー | OSアップグレードまたはv2.x継続を検討 | v3.xの対象外になる可能性がある |
| ドメイン コントローラーではないAD FS / AD CS / Entra Connectサーバー | v2.xセンサーを使用 | v3.xへ一律移行しない |
| 追加IDロールのない既存v2.xドメイン コントローラー | 条件を満たせばv3.xへ移行可能 | v2.x 2.254.19112.470以降などの条件あり |
| Windows Server 2025のv2.xドメイン コントローラー | v3.x移行は未サポート | 新規展開可否と移行可否を混同しない |
Microsoftの移行ドキュメントでは、v2.xからv3.xへ移行できる条件として、追加のIDロールを持たないドメイン コントローラー、Defender for Identity センサー v2.x 2.254.19112.470以降、Windows Server 2019以降、Microsoft Defender for Endpoint展開済み、2026年3月以降の累積更新プログラムが示されています。(Microsoft Learn)
アクティブ化前に確認すべき前提条件
Defender for Identity センサー v3.xの展開で失敗しやすいのは、Microsoft Defenderポータルの操作そのものではなく、事前条件の不足です。特に「MDEは別の管理者が見ている」「ドメイン コントローラーのWindows Updateは別運用」「gMSAは昔の構成のまま」といった分業環境では、前提条件の抜け漏れが起きやすくなります。
| 項目 | 確認内容 | 不足している場合の影響 |
|---|---|---|
| OS | Windows Server 2019以降 | v3.xの対象外または移行不可 |
| 更新プログラム | 2026年3月以降の累積更新プログラム | アクティブ化・移行条件を満たせない |
| Microsoft Defender for Endpoint | センサーを実行するサーバー自体がMDEにオンボード済み | Endpointのみの別展開では不十分 |
| 既存v2.xセンサー | 新規v3.xアクティブ化対象にv2.xが残っていないか | 新規展開か移行かの判断が必要 |
| ライセンス | 対象のMicrosoft 365 / EMS E5系ライセンス | サービス利用条件を満たせない |
| 権限 | Security Administrator、または必要なUnified RBAC権限 | ポータル操作や設定変更ができない |
| ネットワーク | MDEと同じサービス エンドポイントへの接続 | センサーがクラウドと通信できない |
| 仮想化メモリ | VMにメモリを完全割り当て | DCのパフォーマンス低下や不安定化 |
| 時刻同期 | サーバーとDCの時刻差を5分以内にする | 認証・検知・イベント相関に影響 |
| 電源設定 | 高パフォーマンス設定 | 負荷時の遅延や監視品質に影響 |
v3.xセンサーは、Microsoft Defender for Endpointのコンポーネントとして配信され、Windows Updates経由で自動更新されます。v3.xセンサーについては、v2.xのような手動センサー更新プロセスは不要です。(Microsoft Learn)
Microsoft Defender for Endpointのオンボード確認は最優先
v3.xでは、対象ドメイン コントローラーにMicrosoft Defender for Endpointが展開されていることが重要です。Microsoft Defender Antivirusのコンポーネントはアクティブモードでもパッシブモードでもよいとされていますが、Defender for Endpointはセンサーが実行されるサーバー自体にオンボードされている必要があります。(Microsoft Learn)
ここで見落としやすいのは、「MDEのポリシーを配っている」ことと「そのドメイン コントローラーが正しくオンボードされ、デバイスIDを持ち、Senseサービスが動いている」ことは別だという点です。移行時に「準備ができていない」と表示される場合、Defender for Endpoint Client AnalyzerでSenseサービス、オンボード情報、デバイスIDを確認する流れが案内されています。(Microsoft Learn)
実務では、対象DC一覧をCSVで作成し、次の列を持たせると確認が進めやすくなります。
| 管理用の列 | 記入例 | 用途 |
|---|---|---|
| サーバー名 | DC01 | 対象識別 |
| OSバージョン | Windows Server 2019 | v3.x対象判定 |
| 累積更新 | 2026年3月以降適用済み | 前提条件確認 |
| MDE状態 | オンボード済み / 未確認 | アクティブ化可否確認 |
| 既存MDIセンサー | v2.x / なし | 新規か移行か判断 |
| 追加ロール | なし / AD CSあり | 移行可否判断 |
| 対応方針 | v3.x新規 / v3.x移行 / v2.x継続 | 作業計画 |
| 作業後ステータス | Running / Not healthy | 完了確認 |
アクティブ化の基本手順
前提条件を満たしたら、Microsoft DefenderポータルからDefender for Identity センサー v3.xをアクティブ化します。公式手順では、Microsoft Defenderポータルの「System > Settings > Identities > Activation」へ移動し、対象のドメイン コントローラーを選択して「アクティブ化」を実行します。完了後は成功バナーからオンボード済みサーバーを確認し、Sensorsページで正常性を確認する流れです。(Microsoft Learn)
| 手順 | 作業 | 確認ポイント |
| -: | ————————- | ——————————————- |
| 1 | 対象DCの棚卸し | OS、MDE、v2.x有無、追加ロールを確認 |
| 2 | 前提条件チェック | 必要に応じてTest-MdiReadiness.ps1を実行 |
| 3 | Microsoft Defenderポータルを開く | System > Settings > Identities > Activation |
| 4 | 対象DCを選択 | 「Activate new sensor」相当の状態か確認 |
| 5 | Activateを実行 | 確認プロンプトで対象を再確認 |
| 6 | Sensorsページへ移動 | System > Settings > Identities > Sensors |
| 7 | 状態確認 | Running、Health issues、Sensor statusを確認 |
初回アクティブ化では、最初のセンサーがSensorsページでRunningと表示されるまで最大1時間かかる場合があります。2台目以降のアクティブ化は5分以内に表示されるとされています。また、アクティブ化自体にサーバーの再起動は不要です。(Microsoft Learn)
Activationページの表示をどう判断するか
Activationページでは、サーバーの状態に応じて次に行うべき操作が分かるようになっています。管理者は、表示された状態をそのまま作業指示に使うのではなく、なぜその状態になっているかを確認することが重要です。
| 表示される状態 | 意味 | 管理者の対応 |
|---|---|---|
| Activate new sensor | ドメイン コントローラーがDefender for Endpointにオンボード済み | 前提条件を再確認してアクティブ化 |
| Install classic sensor | v3.xではなくクラシック センサー展開が必要 | v2.x展開対象として扱う |
| OS upgrade is required | 新しいセンサーでサポートされないOS | OSアップグレード計画を作る |
この画面で「Activate new sensor」と見えた場合でも、監査設定、gMSA/DSA、SOC連携、性能確認まで完了したとは限りません。アクティブ化は入口であり、運用に載せるには後続設定が必要です。
アクティブ化後に必ず見るべきSensorsページ
アクティブ化後は、Sensorsページで状態を確認します。Sensorsタブでは、種類、ドメイン、遅延更新、サービス状態、センサー状態、移行状態、正常性状態などでフィルターでき、センサー一覧をCSVエクスポートすることもできます。センサー行を選択すると詳細ウィンドウで正常性の問題を確認できます。(Microsoft Learn)
運用上は、以下の3つを優先して確認してください。
| 確認項目 | 見るべき状態 | 異常時の考え方 |
|---|---|---|
| Service status | Running | サービス停止、切断、通信不可を疑う |
| Sensor status | Up to date / Syncingなど | 更新失敗、構成取得失敗を確認 |
| Health status | Healthy | 重大度の高い正常性問題を優先対応 |
センサー状態には、最新、古い、更新中、更新失敗、開始失敗、同期中、Disconnected、到達不能などがあります。たとえばDisconnectedは10分間通信がない状態を示し、到達不能はActive Directoryからドメイン コントローラーが削除されたが、廃止前にセンサーがアンインストールされていないケースとして説明されています。(Microsoft Learn)
v3.xで重要になるLocalSystemとgMSA/DSAの扱い
v3.xの大きな変更点の一つが、サービス アカウントの扱いです。v2.xでは、ADデータの読み取りにDirectory Service Account、応答アクションにアクション アカウントを使う構成がありました。v3.xでは、ADデータの読み取りと修復アクションの両方で、サーバーのLocalSystemを使用します。v3.xでサポートされるIDはLocalSystemのみで、DSAやgMSAは使用しません。(Microsoft Learn)
既存環境でgMSAを使っていた場合は、Microsoft Defenderポータルで「センサーのローカル システム アカウントを自動的に使用する」設定を確認します。いずれかのセンサーがv3.xの場合、すべてのセンサーに対してこの設定を選択することが重要です。(Microsoft Learn)
混在環境では少し複雑です。ワークスペースにv2.xセンサー向けのDSAやgMSAが残っている場合、v3.xセンサー自体はそれらを監査や応答アクションに使いません。それでも、ワークスペース レベルではDSA/gMSAの資格情報検証が続くため、資格情報が不正な場合は正常性アラートが出ることがあります。すべてのセンサーがv3.xへ移行し、v2.xセンサーが不要になった段階で、ワークスペース レベルのDSA/gMSA削除を検討します。(Microsoft Learn)
Windowsイベント監査とRPC監査は後回しにしない
Defender for Identityは、多くの検出でWindowsイベントログに依存します。v3.xセンサーをドメイン コントローラーで利用する場合、手動構成なしで監査設定を処理するために、自動監査を有効にすることが推奨されています。自動監査を使えない、またはオプトアウトした場合は、手動またはPowerShellで監査設定を構成します。(Microsoft Learn)
また、セキュリティの可視性を高め、追加のID検出を有効にするために、Unified Sensor RPC Auditタグをデバイスへ適用する手順も示されています。この機能はDefender for Identity センサー バージョン3.0.4以降が前提で、Asset Rule Managementからルールを作成し、対象のドメイン コントローラーへタグを適用します。ルールの反映には最大1時間かかる場合があります。(Microsoft Learn)
実務では、アクティブ化作業を「センサーがRunningになったら完了」としないことが大切です。次のように、アクティブ化後の設定確認まで完了条件に含めてください。
| 完了条件 | 確認方法 |
|---|---|
| センサーがRunning | SensorsページのService status |
| 正常性問題がない | Health statusとHealth issues |
| Windowsイベント監査が構成済み | 自動監査または手動設定の確認 |
| RPC監査タグが適用済み | Asset Rule ManagementとDevice inventory |
| LocalSystem利用設定が適切 | action accounts設定 |
| SOC連携への影響確認済み | syslog非対応などの代替設計確認 |
既存v2.xからv3.xへ移行する場合の注意点
v2.xからv3.xへの移行は、Microsoft Defenderポータルから直接実行でき、切り替え中もv2.xセンサーがv3.xセンサーの準備完了まで動作し続けます。公式情報では、移行は通常最大20分で、ダウンタイムやデータ重複なしにサーバー構成とセキュリティ監視を維持するとされています。(Microsoft Learn)
ただし、移行対象は限定されています。追加のIDロールを持たないドメイン コントローラーであること、v2.xセンサーが2.254.19112.470以降であること、Windows Server 2019以降であること、Defender for Endpointと2026年3月以降の累積更新プログラムが必要です。(Microsoft Learn)
移行後にも作業は残ります。移行によりv2.xセンサー サービスは無効になりますが、v2.xセンサー ソフトウェアはサーバーに残ります。完全にクリーンアップするには、v2.xセンサーのアンインストールと、他のアプリケーションで使っていない場合のNpcap削除を検討します。v2.xセンサーのアンインストールではサーバー再起動が必要になる場合があります。(Microsoft Learn)
「移行の準備ができていない」と表示されたときの見方
移行対象のサーバーが「移行の準備ができていない」と表示される場合、闇雲に再実行するのではなく、失敗している条件を切り分けます。Microsoftのトラブルシューティングでは、Defender for Endpoint Client Analyzerを使って、MDEセンサー、オンボード情報、デバイスIDなどを確認する流れが示されています。(Microsoft Learn)
| 失敗しやすい条件 | 確認方法 | 対応 |
|---|---|---|
| MDEセンサーが動作していない | Senseサービスの状態 | MDEオンボードを修正 |
| MDEオンボード情報がない | Client Analyzerの結果ZIP | サーバーをMDEへ再オンボード |
| Defender for EndpointデバイスIDがない | SenseMachineIdやデバイスID | オンボード完了を再確認 |
| v2.xセンサー サービスが動作していない | Sensorsページまたはsc query AATPSensorUpdater | サービス起動、必要なら再インストール |
| v2.xセンサーが古い | Programs and Features、Sensorsページ | 2.254.19112.470以降へ更新 |
| MDEセンサーが古い | Client AnalyzerのSense version | 最新版へ更新 |
| OSまたは累積更新が不足 | winver | Windows Server 2019以降、2026年3月以降の更新を適用 |
| 追加IDロールがある | AD FS / AD CS / Entra Connectの有無 | 純粋なDCのみ移行対象として扱う |
ここで重要なのは、「新規展開ではv3.xをサポートするDC上の追加IDロール」と、「既存v2.xからのインプレース移行対象」は同じではないことです。AD FS、AD CS、Entra Connectなどの追加ロールが同居するドメイン コントローラーでは、移行対象として扱えるかを慎重に確認してください。
v3.x展開で起きやすい運用上の失敗
Defender for Identity センサー v3.xの導入で起きやすい失敗は、技術的なエラーだけではありません。多くは「作業範囲の見誤り」です。
センサーを有効化しただけで完了にしてしまう
アクティブ化は必要条件ですが、十分条件ではありません。SensorsページでRunningになっていても、Windowsイベント監査、RPC監査、LocalSystem設定、正常性アラートの確認が残っている場合があります。特に攻撃の中断などの応答アクションを使う環境では、gMSAが残ったままになっていないか確認してください。移行ドキュメントでは、gMSAが有効のままだと、攻撃の中断を含む応答アクションが機能しないと説明されています。(Microsoft Learn)
v2.xとv3.xを同じ考え方で更新管理する
v3.xはMicrosoft Defender for Endpointのコンポーネントとして配信され、Windows Updates経由で自動更新されます。一方、v2.xには遅延更新リングなどv2.x向けの更新運用があります。両者を混同すると、「v3.xでも手動更新が必要なのか」「遅延更新が効くのか」といった誤解につながります。(Microsoft Learn)
非対応機能を確認せずに切り替える
VPN統合やsyslog通知を使っていた環境では、v3.xの非対応が運用設計に影響します。たとえば、SIEM側でsyslog通知を前提にしたアラート処理やチケット連携を組んでいる場合、切り替え前に代替経路を確認する必要があります。(Microsoft Learn)
仮想DCのリソース割り当てを見落とす
v3.xセンサーはCPU使用率を30%、メモリ使用量を1.5GBに制限して過剰使用を防ぐとされています。ただし、他のサービスが大量のリソースを使っている場合、ドメイン コントローラー側でパフォーマンス低下が発生する可能性があります。仮想マシンではメモリを完全に割り当て、Hyper-Vでは動的メモリを無効化し、VMwareでは予約メモリを構成するなどの確認が必要です。(Microsoft Learn)
開発者・アプリ担当者が確認すべきこと
Defender for Identity センサー v3.xはインフラ・セキュリティ寄りの変更ですが、Active DirectoryやAD FS、証明書サービス、認証ログを使うアプリケーション担当者にも影響します。
特に確認したいのは、次の4点です。
| 観点 | 確認内容 |
|---|---|
| 認証連携 | AD FSやEntra Connectが稼働するサーバーの扱いが変わらないか |
| ログ連携 | 既存のSIEM、監査基盤、通知処理がsyslog前提になっていないか |
| 権限・応答 | アカウント無効化やパスワードリセットなどの応答アクションがLocalSystem前提で動くか |
| 変更タイミング | 認証基盤の保守時間帯、業務アプリのピーク時間帯を避けられるか |
業務アプリの開発者が直接センサーを操作することは少なくても、認証失敗、ログ量増加、監査イベントの追加、SOC側の検知ルール変更はアプリ運用に波及します。センサーのアクティブ化日、監査設定の変更日、RPC監査タグの適用日を変更管理チケットに残しておくと、後日のトラブルシューティングが楽になります。
展開順序は「小さく検証してから広げる」が安全
全ドメイン コントローラーを一括でv3.x化するより、代表的な1台または小規模なサイトから始める方が安全です。特に拠点ごとにネットワーク経路やプロキシ、Windows Update運用が異なる環境では、一部のDCだけMDE通信に失敗することがあります。
おすすめの展開順序は次の通りです。
| フェーズ | 作業内容 | 完了条件 |
|---|---|---|
| 棚卸し | DC、OS、ロール、v2.x有無、MDE状態を一覧化 | 方針がv3.x新規、v3.x移行、v2.x継続に分類済み |
| 前提条件整備 | MDE、累積更新、権限、ネットワーク、時刻同期を確認 | Test-MdiReadiness.ps1などで問題を洗い出し済み |
| パイロット | 影響の少ないDCでアクティブ化 | Running、Healthy、ログ収集を確認 |
| 監査設定 | Windowsイベント監査とRPC監査を構成 | 必要な検出が有効化され、正常性アラートがない |
| 段階展開 | サイトまたはOU単位で拡大 | 作業ログと状態一覧を更新 |
| クリーンアップ | v2.x移行後の残存ソフトやNpcapを整理 | 不要コンポーネントを撤去し、再起動要否を管理 |
管理者向けチェックリスト
作業前後の確認を簡単にするため、以下のチェックリストを使ってください。
| タイミング | チェック項目 |
|---|---|
| 作業前 | 対象がWindows Server 2019以降のドメイン コントローラーか |
| 作業前 | 2026年3月以降の累積更新プログラムが適用されているか |
| 作業前 | Microsoft Defender for Endpointが対象サーバーにオンボードされているか |
| 作業前 | v2.x新規展開、v3.x新規展開、v2.xからの移行を分類したか |
| 作業前 | VPN統合、syslog通知、ExpressRoute制限の影響を確認したか |
| 作業前 | gMSA/DSAの利用状況と混在期間を整理したか |
| 作業中 | Activationページで対象DCと状態を確認したか |
| 作業後 | SensorsページでRunningとHealthyを確認したか |
| 作業後 | Windowsイベント監査、自動監査、RPC監査タグを確認したか |
| 作業後 | SOC、SIEM、運用監視への影響を確認したか |
| 移行後 | v2.xセンサー ソフトウェアとNpcapの扱いを決めたか |
まとめ：v3.xアクティブ化は「対象判定」と「後続設定」まで含めて計画する
Defender for Identity センサー v3.xのアクティブ化は、Microsoft Defenderポータルから比較的シンプルに実行できます。しかし、実務上の成否は、事前の対象判定とアクティブ化後の設定確認で決まります。
まず、ドメイン コントローラーを棚卸しし、Windows Server 2019以降、2026年3月以降の累積更新、Microsoft Defender for Endpointオンボード、既存v2.xセンサー、追加IDロールの有無を確認してください。次に、Activationページで対象DCをアクティブ化し、SensorsページでRunningと正常性を確認します。その後、Windowsイベント監査、RPC監査、LocalSystem利用、gMSA/DSA混在時の正常性アラートまで見て、初めて運用に載せられる状態になります。
既存v2.xからの移行では、純粋なドメイン コントローラーかどうか、v2.xのバージョン、MDE状態、Windows Server 2025の制限を必ず確認しましょう。v3.xは更新運用やサービス アカウントの考え方が変わるため、単なるセンサー更新ではなく、Active Directory監視基盤の設計変更として扱うのが安全です。
コメント