1. はじめに
Microsoft Defender for Identity（以下 MDI）のセンサーは、ドメイン コントローラー（DC）に v2.x センサーを MSI で導入する方式から、Microsoft Defender for Endpoint（MDE）と連携する v3.x センサーへ移行できるようになりました。
本記事は、実際の Active Directory 環境（Azure 上の Windows Server 2022 DC × 2 台）で v2.x → v3.x のインプレース移行を行った検証結果をブログとして公開しました。
公式手順をなぞるだけでなく、次の点を「やってみて分かった事実」として残しています。
- v3 へ上げると何が良くなるのか
- 事前に何を確認しないと詰まるのか（OS 更新、MDE、アクション アカウントなど）
- 移行中・移行後に AD や MDE がどうなったか（所要時間と観測結果）
- v2 の後片付け（アンインストール、Npcap、gMSA）で何をして、何をしなかったか
- 移行後に v3 で本当に検知できているか（安全な攻撃シミュレーション）
検証日は 2026 年 10 月 26 日です。時刻は特記がなければ日本時間（JST, UTC+9）で記載します。MDI・Windows の仕様は更新が続くため、実施前に最新の公式ドキュメントも確認してください。
本文中の 「実測」 は今回の環境で自分が確認した事実、「公式」 は Microsoft Learn の記載です。両者は区別して書いています。
1.1 検証結果
検証した結果をまとめると以下のようになりました。
| 項目 | 結果 |
|---|---|
| 移行対象 | vmWinADDC01 / vmWinADDC02 （Windows Server 2022 Datacenter Azure Edition） |
| 移行結果 | 両台とも MDI センサー 3.0.10.445 で実行中・正常 |
| 移行前に必要だった追加作業 |
2026 年 10 月の累積更新 KB5126655 の適用と再起動 （ポータルは「移行の準備完了」と表示していたが、OS は 6 月の更新止まりだったため） |
| v2 の後片付け | 標準のアンインストーラーで v2 と Npcap を削除。 終了コード 0、再起動不要。MDE と AV は維持 |
| 移行後の検知 | v2 と Npcap を削除した後に、ハニートークンへの認証を MDI が検知（アラート 1 件、ケース作成） |
| 移行後の対応 | Defender から専用テストユーザーを無効化し、両 DC で新規認証が拒否された（LDAP エラー 49 / data 533） |
2. v3 へ移行するメリット
v3 に上げる価値は大きいと感じました。
特に「DC に残る MDI 関連の部品が減る」「資格情報の管理が減る」「監査設定を製品側に寄せられる」点が効きます。以下、公式の仕様と、今回実測できた裏付けを分けて整理します。
| # | メリット | v3 で変わること | 本環境での裏付け |
|---|---|---|---|
| 1 | 移行がポータルから 1 操作 | センサーを選んで「移行」。MSI の再インストールや DC での手作業は不要。移行中も v2 が動き続ける仕様（公式） | DC02 / DC01 とも確認ダイアログで「移行」を押しただけ。ポータルの完了確認は 32 分 / 18 分後（実測） |
| 2 | DSA / gMSA が不要 | AD の読み取りと修復アクションはサーバーの LocalSystem で実行。v3 は gMSA を使わない（公式） | アクション アカウントは「センサーのローカル システム アカウントを自動的に使用する」。DSA の登録は 0 件だった（実測） |
| 3 | Npcap が不要 | v3 は Npcap を必要としない（公式） | v2 と Npcap を削除したあとも、v3 単独でハニートークンを検知できた（実測） |
| 4 | 監査設定を製品側で自動構成 | 「Windows 監査の自動構成」で必要な監査設定を確認・補完。24 時間ごとに実行（公式） | 設定は On。既存の 60 監査項目の値は最終的に差分 0、ドメインルートの SACL は 6→11 ACE（元の ACE は削除なし）（実測） |
| 5 | RPC 監査が自動 | センサー 3.0.8 以降は DC の RPC 監査が自動で有効化され、タグ適用が不要（公式） | 今回のバージョンは 3.0.10.445。旧来のタグ操作は行っていない（実測。個別の RPC イベント取り込みは未確認） |
| 6 | 更新が OS 更新と一体 | v3 は Windows Update 経由で更新。v2 の「遅延更新」は v3 に適用されない（公式） | 詳細画面の遅延更新は v2 が「無効」、v3 が「N/A」（実測） |
| 7 | リソース上限が明確 | CPU 30%、メモリ 1.5 GB を上限とする（公式） | (本検証では性能比較はしていません) |
| 8 | DC 以外にも広がる | 条件を満たす AD FS / AD CS / Entra Connect サーバーにも導入可能（プレビュー）（公式） | 本検証の対象外 |
2.1 MDI v3 の運用イメージ
v3 を運用する全体像を、Azure / Microsoft のアイコンで描きました。DC には v3 センサーだけが入り、調査から対応までを Defender ポータル 1 か所で行います。
- 左（AD 環境）は今回の検証環境です。DC 側で必要な作業が減ることと、その根拠が「実測」か「公式」かを、バッジで区別しています
- 中央（Defender ポータル）の枠内の操作は、すべて今回の検証で実行して確認しました
- 右（Azure 側の運用）は、Microsoft Sentinel などと連携する場合の想定図です。今回の検証の対象外で、構成や動作は確認していません
2.2 DC 上の構成の違い（v2 と v3）
DC に残る部品の違いを並べると、MDI v3 の良さが分かります。
- v2 の DC では、
AATPSensor、AATPSensorUpdater、Npcap の 3 つを確認しました - v3 へ移行した DC では、ゲストのサービス一覧に Sense だけが見え、
AATP*とMdi*は見当たりませんでした - v3 では DSA / gMSA の管理や、RPC 監査のタグ操作が不要になります（公式）
2.3 画面で見る v2 と v3 の違い
v2.255 のときの詳細画面です。バージョンは 2.255.19347.63719、遅延更新は「無効」でした。
移行後の詳細画面です。バージョンは 3.0.10.445、サービスは実行中、状態は「正常」、遅延更新は「N/A」です。
3. 移行前の確認
3.1 公式の移行要件
公式の移行ガイドでは、次を満たすサーバーがインプレース移行の対象です。
- ドメイン コントローラーであること（AD FS / AD CS / Entra Connect も兼ねる DC を含む）
- MDI センサー v2.x が
2.254.19112.470以降であること - Windows Server 2019 以降であること
- MDE が展開済みで、2026 年 9 月以降の Windows Server 累積更新が適用済みであること
- 移行前に、アクション アカウントで「センサーのローカル システム アカウントを自動的に使用する」を選ぶこと（移行は自動で切り替えない）
また、v3 は VPN 連携と syslog 通知をサポートしません。ExpressRoute にも制限があります。
3.2 本環境の移行前の状態（実測）
| 項目 | vmWinADDC01 | vmWinADDC02 |
|---|---|---|
| OS | Windows Server 2022 Datacenter Azure Edition | 同左 |
| OS build | 20348.5256（最新の更新は 2026 年 6 月） | 同左 |
| MDI センサー | 2.255.19347.63719 | 同左 |
| MDE（Sense サービス） | 実行中 / OnboardingState=1 | 同左 |
| AD 複製 | 失敗 0 | 同左 |
| ポータルの移行状態 | 移行の準備完了 | 移行の準備完了 |
| 2026 年 9 月以降の累積更新 | 未適用 | 未適用 |
検証メモ上は DC02 のセンサーが古いバージョンでしたが、検証開始時のポータルでは両台とも
2.255.19347.63719でした。
「移行の準備完了」と表示されていても、OS 更新要件を満たしているとは限りません。 今回は 2 台とも OS が 6 月の更新止まりでした。この状態のまま移行を試した場合にどうなるかは検証していません。要件を満たすために、移行前に累積更新を適用しました。
3.3 公式の Test-MdiReadiness.ps1
Microsoft が公開している Test-MdiReadiness.ps1 を、各 DC で -SkipCA を付けて実行し、HTML と JSON のレポートを保存しました（スクリプトの SHA-256 を固定してから実行）。2 台とも同じ結果でした。
| チェック | 結果（実測） |
|---|---|
| Advanced Audit Policy / NTLM Auditing | true / true |
| 電源プラン（高パフォーマンス） / ルート証明書 | true / true |
| ドメイン オブジェクト監査 | false |
| ServerRequirements | false（2 論理 CPU・約 3.95 GiB のメモリ） |
| AD FS / Exchange 監査 | N/A（該当コンテナーなし） |
このスクリプトの判定が false でも、結果的に v3 への移行は成功しました。スクリプトは v2 時代からのチェック項目を含むため、v3 の移行可否そのものとは区別して読む必要があります。ドメイン オブジェクト監査の不足は、後述する自動監査構成で補完される対象です。
4. 移行手順（実施した順番）
DC を 2 台とも同時に触らず、1 台ずつ進めました。
- 2026 年 10 月の累積更新 KB5126655 を適用し、再起動（DC02 → DC01）
- Defender ポータルから DC02 を v3 へ移行
- DC02 の正常性を確認してから DC01 を移行
- 両台が v3 で正常なことを確認後、v2 のソフトを削除
4.1 累積更新（KB5126655）の適用
Windows Update の検索では KB5126655 のほかに .NET の累積更新と MSRT も候補に出ましたが、対象の KB5126655 だけを明示的に選んで適用しました。自動再起動は行わず、結果を保存してから 1 台ずつ再起動しました。
| 項目 | DC02 | DC01 |
|---|---|---|
| インストール | 09:58:47 → 10:41:35（42 分 48 秒） | 11:17:47 → 12:14:13（56 分 26 秒） |
| 再起動の予約 | 10:57:16 | 12:37:51 |
| 実際の新しい起動 | 11:06:25 | 12:44:55 |
| 更新後の build | 20348.5761 | 20348.5761 |
| 更新後の確認 | KB あり・再起動待ちなし・主要サービス Running・AD 複製失敗 0 | 同左 |
再起動を予約した時点の最初の確認では、まだ旧 build・旧起動時刻が返りました（Servicing が完了していなかったため）。「再起動を予約できた」ことと「更新と再起動が完了した」ことは別なので、起動時刻・build・KB を確認してから次へ進めました。
確認に使った基本的なコマンドは次のとおりです。
Get-HotFix -Id KB5126655
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR
Get-Service NTDS, DNS, Kdc, Netlogon, DFSR, Sense
Get-ADReplicationPartnerMetadata -Target $env:COMPUTERNAME
4.2 ポータルから移行する
Defender ポータルの 設定 > ID > オンプレミス > センサー管理 で、「移行の準備完了」のサーバーを1 台だけ選び、「移行」を実行します。確認ダイアログは次のとおりです（背景に v2 のバージョンが見えています）。
4.3 移行の経過と完了確認（実測）
| 項目 | DC02 | DC01 |
|---|---|---|
| 移行を実行 | 11:39:37 | 13:05:40 |
| 旧 v2 検知サービスの停止（SCM イベント） | 11:58:20 | 13:12:32 |
| ポータルが「移行中」を最後に確認 | 11:57:57 | 13:19:07 |
| ポータルで v3 の稼働を最初に確認 | 12:11:44 | 13:23:57 |
| 開始から最初の確認まで | 32 分 6 秒 | 18 分 17 秒 |
| バージョン / 状態 | 3.0.10.445 / 実行中・正常 | 3.0.10.445 / 実行中・正常 |
公式の案内は「通常最大 20 分」「v3 の準備ができるまで v2 が動き続ける」です。DC01 は 20 分以内、DC02 は確認できたのが 32 分後でした。ポータルで完了を確認できた時刻であり、実際の切替時刻とは別です（確認間隔が空いているため上限側の観測値です）。
移行後のセンサー一覧で気づいた点です。
- センサー名が 小文字になった（
vmWinADDC01→vmwinaddc01、VMWINADDC02→vmwinaddc02） - 作成日時が移行した時刻に変わった（旧: 2024/12/11 → 新: 2026/10/26 11:44 と 13:07）
- 未処理の正常性の問題は 0 件
センサー名や作成日時をキーにした運用スクリプト、タグ付け、管理表がある場合は影響を確認してください。
4.4 DC01 でだけ起きた「移行の準備ができていません」
DC01 は累積更新の再起動後、ゲスト OS 上では Sense サービスが Running でオンボード済みなのに、ポータルの移行状態が一時的に **「移行の準備ができていません」**になりました。ツールチップの理由は「Microsoft Defender for Endpoint (Sense) サービスが実行されていません」でした。
Sense を再起動したり、MDE を再オンボードしたりせず、ログで実状態を確認しながら待ったところ、約 8 分後に「移行の準備完了」へ戻りました。ポータルの状態表示とゲストの実状態には反映のずれがあるため、慌てて修復操作をしないほうが安全でした。
5. v3 を使いこなす設定
5.1 アクション アカウントは LocalSystem
「アクション アカウントの管理」で 「センサーのローカル システム アカウントを自動的に使用する」 が選択されていることを確認します。この環境では移行前から選択済みで、変更していません。移行がこの設定を自動で切り替えることはありません（公式）。
公式では、v3 が 1 台でもあるなら、gMSA を選んだままだと修復アクション（攻撃の中断を含む）が動作しないと案内されています。
5.2 Windows 監査の自動構成
「高度な機能」で Windows 監査の自動構成を確認します。この環境ではもともと On でした。センサー v3.x の自動アクティブ化は Off のままにしています（今回は対象 2 台を明示的に移行するため）。
画面の通知によれば、2026 年 11 月 15 日以降、Defender for Identity はテナントの自動アクティブ化を段階的に有効にします。今すぐ有効にするか、期日前にオプトアウトできます。運用方針に合わせて、告知の期間中に判断してください。
自動監査の前後で既存の監査設定はどうなったか（実測）
公式の説明では、自動監査は現状を確認して不足を補い、ローカルの監査ポリシー、NTLM 設定、ドメインルートや Configuration の SACL などに設定を適用します。実際に、移行前と最終状態の auditpol と SACL を比較しました。
| 比較 | 結果 |
|---|---|
| 検証開始前 → 最終状態の 60 監査サブカテゴリ | 両 DC とも差分 0 件（有効だった監査ビットはすべて保持） |
| ドメインルートの SACL | 6 → 11 ACE（追加 5、元の ACE の削除 0） |
| Configuration パーティションの SACL | 4 → 4 ACE（追加・削除 0） |
ただし途中経過では注意が必要でした。DC01 では、OS 更新後・自身の v3 移行前のスナップショットに、12 の監査サブカテゴリが「成功と失敗」で有効になっている区間がありました（Logon、RPC Events、Audit Policy Change、Certification Services など）。その後、v3 移行後・旧ソフト削除前のスナップショットでは元の「監査なし」に戻っていました。OS 更新、DC02 の先行 v3 移行、自動監査の周期実行が重なっており、原因は特定していません。
つまり「既存設定は何も変わらない」とも「追加だけ」とも一般化できません。移行の前後で auditpol /get /category:* /r の出力と SACL を保存して比較するのが確実と思われます。
auditpol /get /category:* /r
5.3 RPC 監査
公式では、センサー 3.0.8 以降は DC の RPC 監査が自動で有効化され、タグ適用が不要です。今回は 3.0.10.445 なので、旧来のタグ操作は行っていません。
一方で、最終状態でも auditpol の「RPC Events」は「監査なし」でした。これだけで RPC 監査の成否は判断できません（今回は製品側の自動構成を前提にしています）。また、専用ユーザーに対する RPC の単発読み取り（NetUserGetInfo level 0）は成功しましたが、Advanced Hunting の IdentityQueryEvents では該当行を確認できませんでした。RPC 個別イベントの取り込み・検知までは実証できていません。
5.4 DSA / gMSA の扱い
- DSA の登録は行っていなかったため、本検証の対象外としました
- AD には gMSA が 1 つ（プロビジョニング用途を示す名前）あり、別のサーバーにパスワード取得権限があり、こちらも対象外としました
公式は「すべてのセンサーが v3 に移行し、v2 がアカウントを必要としなくなってから、ワークスペースの DSA / gMSA 設定を手動で削除し、未使用の gMSA の廃止前に他のサービスで使っていないか確認する」としています。「MDI 設定の削除」と「AD の gMSA オブジェクトの削除」は別操作です。
5.5 v3 で使えない機能の確認
VPN 連携（RADIUS アカウンティング）は Off、Syslog サービスも Off でした。v3 非対応の機能に依存していないことを事前に確認できました。
6. v2 のクリーンアップ
移行で v2 の検知サービスは停止・無効化されます。ただしソフトウェア自体は残ります（公式）。実際にも、移行後の DC には次の状態が残っていました。
-
AATPSensor（v2 の検知サービス）: Stopped / Disabled -
AATPSensorUpdater: Running / Automatic のまま - Npcap OEM とそのドライバー
- 「Azure Advanced Threat Protection Sensor」のアンインストール エントリが2 つ（MSI とブートストラッパー）。表示バージョンは
2.239.18075.31594で、実行中のバイナリ2.255.19347.63719とは違いました
登録バージョンの表示だけで実センサーのバージョンを判断しないでください。サービスの実行ファイルのパスとバージョンで確認しました。
6.1 実施内容
両台のポータル表示が v3 で正常、DC の AD / MDE が正常、複製失敗 0 であることを確認したうえで、DC02 → DC01 の順に実施しました。
- 登録されている Microsoft 署名のブートストラッパーで
/quiet /uninstall /norestart - Wireshark や Nmap など他のキャプチャ ツールの有無を確認してから、Npcap を
uninstall.exe /Sで削除
| 項目 | DC02（13:25 頃） | DC01（13:28 頃） |
|---|---|---|
| v2 アンインストール終了コード | 0 | 0 |
| Npcap アンインストール終了コード | 0 | 0 |
| 再起動要求 | なし | なし |
| 旧サービス / 旧製品 / Npcap ドライバーの残り | 0 / 0 / 0 | 0 / 0 / 0 |
| MDE Sense / AV | Running / Normal・リアルタイム保護有効 | 同左 |
移行済みの v3 センサーの行を、ポータルから「削除」してはいけません。 一般的なセンサー廃止手順（「センサーを削除」）は、移行後の v3 の行には適用しません。
7. 移行中の「保護が途切れる時間」をどう測ったか
「v2 から v3 に切り替える間、DC は無防備になるのか」は気になる点です。公式は、v3 の準備ができるまで v2 が実行を続けるため、ダウンタイムやデータの重複はないとしています。これを自分の環境で測ってみました。
ただし、測れたのは次の 3 つの別の指標です。どれも「検知保護の空白が 0 秒」の証明にはなりません。
7.1 センサー切替中の AD / MDE サービス（実測）
移行中、ゲスト側で AD 関連サービスと Sense を約 1 秒間隔で記録しました（スケジュール タスクで実行し、終了後にタスクを削除）。
| 項目 | DC02 | DC01 |
|---|---|---|
| サンプル数 | 2,124 | 1,825 |
| 平均 / 最大のサンプル間隔 | 1.529 秒 / 85.328 秒 | 1.057 秒 / 9.344 秒 |
| NTDS / DNS / Kdc / Netlogon / DFSR / Sense が Running でない | 0 | 0 |
| 旧 v2 検知サービスが Stopped になった時刻（SCM） | 11:58:20 | 13:12:32 |
DC02 では、v2 が StopPending から Stopped になる前後（1.84 秒の間隔）でも、Sense と NTDS は Running でした。
注意点: 要求は 1 秒間隔でしたが、実際には最大で約 85 秒の欠測があります。「ゼロダウンタイムを証明した」とは言えません。サービスの状態と、実際に認証トラフィックを検知できているかは別です。
7.2 前提の OS 更新による DC の到達性（実測）
累積更新の再起動は MDI の切替とは別の停止です。再起動していない側の DC から、相手の LDAP（TCP/389）への接続を約 1 秒ごとに確認しました。
| 対象 | 主な不達区間（前後の成功観測で囲んだ上限と下限） |
|---|---|
| DC02 の再起動 | 30.7〜33.4 秒、37.2〜39.9 秒の 2 区間 |
| DC01 の再起動 | 約 316〜343 秒の連続区間（ほかに数秒〜数十秒の短い不達） |
観測元の DC（再起動していない側）の AD 関連サービスは、終始 Running でした。DC が 2 台あり 1 台ずつ作業したことで、AD 自体は継続できました。
7.3 ポータルで完了を確認できるまでの時間（実測）
表 4.3 のとおり、開始から最初に v3 を確認できるまでが DC01: 18 分 17 秒、DC02: 32 分 6 秒です。これは保護停止時間ではなく、画面で完了を確認できた時刻です。
8. 移行後の確認と Advanced Hunting
8.1 v3 で動いていることを確認する
- ポータルのセンサー一覧: バージョン 3.0.10.445、実行中、正常
- ゲスト OS: MDE（Sense）が Running、旧 v2 サービスと Npcap が存在しない
- Advanced Hunting: MDE の状態と、MDI のイベント
DC 上での最終確認（実測）は、両台とも次のとおりでした。
- build 20348.5761 / KB5126655 あり
- NTDS / DNS / Kdc / Netlogon / DFSR / Sense / WinDefend が Running、複製失敗 0
- MDE OnboardingState=1、Defender ウイルス対策は Normal・リアルタイム保護有効
- v2 サービス・製品・Npcap ドライバーが 0
8.2 MDE と DC の状態を確認する KQL
let dcNames = dynamic(["vmwinaddc01", "vmwinaddc02", "vmwinaddc01.ad.azurecsa.net", "vmwinaddc02.ad.azurecsa.net"]);
DeviceInfo
| where Timestamp > ago(6h)
| where DeviceName in~ (dcNames)
| summarize arg_max(Timestamp, *) by DeviceId
| project Timestamp, DeviceName, OnboardingStatus, SensorHealthState, ClientVersion, OSVersion
| order by DeviceName asc
両台とも Onboarded / Active で、ClientVersion は 10.8837.20348.5761 でした。
9. 攻撃シミュレーション（安全な検知・対応テスト）
v3 へ移行したあとで「本当に v3 だけで検知でき、Defender から止められるのか」を確かめるため、公式の「導入後の確認」の例に沿って、影響を限定したテストを行いました。
9.1 どんな攻撃を想定したテストか
想定したのは、AD に侵入した攻撃者が、おとり（ハニートークン）のアカウントに触れてしまう場面です。
- ハニートークンは、普段は誰も使わない休眠アカウントです。攻撃者が AD を偵察して「SQL-Admin」のような魅力的な名前のアカウントを見つけ、認証を試みた時点でアラートにします。公式の説明では、ハニートークンに対する認証の動作は悪意ある行為の兆候となり得るとされています（アラート定義、エンティティ タグ）。
- このアラート（Honeytoken authentication activity）の MITRE ATT&CK 上の位置づけは、公式の定義では資格情報アクセス（TA0006）、副次的に探索、手法はアカウント探索の「ドメイン アカウント」（T1087.002）です。重大度は Medium です。
- 今回は攻撃ツールを使っていません。「おとりのアカウントに DC へ認証を試みる」という行為だけを、そのアカウントの正規の資格情報による LDAP / NTLM のバインドで再現しました。
このテストで確認できるのは、「v3 単独でハニートークンへの認証を検知し、ケースになり、Defender から AD アカウントを無効化できる」までです。実際の攻撃ツールに対する検知の網羅性や精度、自動攻撃妨害の自動作動は確認していません。
9.2 検知の結果（実測）
| 項目 | 内容 |
|---|---|
| アラート名 | Honeytoken authentication activity |
| 重大度 / 検出元 | Medium / Microsoft Defender for Identity |
| 発生時刻 | 13:32:54（最初の LDAP バインドと一致） |
| ケース | ケース ID 4297 / インシデント ID 9268（13:37 に作成）、カテゴリ Discovery |
Advanced Hunting でも、MDI のアラートを確認できました。
AlertEvidence
| where Timestamp > ago(24h)
| where AccountSid =~ "<テスト ユーザーの SID>" or AccountName =~ "<テスト ユーザー名>"
| join kind=inner (
AlertInfo
| where Timestamp > ago(24h)
| project AlertId, AlertTimestamp=Timestamp, Title, Severity, ServiceSource, DetectionSource
) on AlertId
| project AlertTimestamp, AlertId, Title, Severity, ServiceSource, DetectionSource, AccountName, AccountSid, EvidenceRole, DeviceName
| distinct *
| order by AlertTimestamp desc
v2 / Npcap の削除（13:25〜13:28）の後に起きた検知です。この検知は v3 のセンサーだけでの動作を示します。
9.3 認証イベントの確認（実測）
IdentityLogonEvents
| where Timestamp > ago(24h)
| where AccountSid =~ "<テスト ユーザーの SID>" or AccountName =~ "<テスト ユーザー名>"
| project Timestamp, ActionType, Application, Protocol, AccountName, DeviceName, DestinationDeviceName, TargetDeviceName, FailureReason
| order by Timestamp asc
確認できたのは次の 4 行です。
| 時刻 | ActionType | プロトコル | 補足 |
|---|---|---|---|
| 13:33:26 | LogonSuccess | Ldap | DC01 向け |
| 13:50:31 | LogonSuccess | Ntlm | DC01 → DC02 |
| 13:58:01 | LogonFailed | Ntlm | DC02、FailureReason=AccountDisabled |
| 13:58:33 | LogonFailed | Ntlm | DC01、FailureReason=AccountDisabled |
ユーザーとして実行した認証 5 回のうち、IdentityLogonEvents で確認できたのは 4 行です。最初の DC02 向け LDAP バインド（アラートの発生時刻と一致）は、ログオン イベントの行としては確認できませんでした。また、認証ではないカナリアの情報照会（RPC の単発読み取り）に対応する行も確認できませんでした。
また、反映には時間差がありました。
- 認証の約 8 分後（04:41 UTC 時点）には、この KQL は 0 件でした（
AccountName条件も含むクエリです） - 4 行が見えたのは約 52 分後の確認時でした（その間にこのテーブルの途中確認はしていません）
- アラートは、約 4 分後の確認では 0 件で、約 20 分後の確認で 1 件でした（SID の比較を
==から=~に変えて再実行しているため、反映遅延だけが原因かは切り分けていません。ポータルのユーザー画面ではアラートが先に見えていました）
10. v2 → v3 で注意すべき点（チェックリスト）
お客様の環境で Defender for Identity (MDI) をこれまで運用されていた方々は v2 が多いのではと思います。
以下、チェックリストをまとめてみたので、更新を検討される方は参考としてください。
| # | 注意点 | 理由・本環境での事実 |
|---|---|---|
| 1 | OS の累積更新（2026 年 9 月以降）を事前に確認 | 要件。ポータルが「移行の準備完了」でも、2 台とも OS は 6 月の更新止まりだった。更新は 43〜56 分 + 再起動が必要 |
| 2 | MDE が必須 | 移行の前提。MDE の Sense を止めたり、再オンボードしたりしない。再起動後に「Sense が実行されていない」と一時的に表示されたが、待てば Ready に戻った |
| 3 | アクション アカウントを LocalSystem に | 移行は自動で切り替えない。gMSA のままだと修復アクションが動かない（公式） |
| 4 | DSA / gMSA を急いで消さない | すべて v3 になってからワークスペースの設定を削除する。AD の gMSA は別用途を確認する。今回は別サーバーに取得権限がある gMSA を保持した |
| 5 | v3 非対応機能の確認 | VPN 連携 / syslog 通知 / ExpressRoute の制限。今回は RADIUS と Syslog が Off だった |
| 6 | 自動監査の影響を前後比較 | GPO と競合し得る。60 項目の最終値は差分 0、ドメインルート SACL は +5 ACE だが、途中で 12 項目が一時的に有効になる区間もあった。前後の auditpol と SACL を保存する |
| 7 | 自動アクティブ化の告知 | 2026 年 11 月 15 日以降の段階的な有効化。設定とオプトアウトの方針を事前に決める |
| 8 | v2 のソフトは残る | 検知サービスは Stopped / Disabled だが、Updater は動き続け、Npcap も残る。標準のアンインストーラーで削除する |
| 9 | v3 の行を削除しない | 廃止手順の「センサーを削除」は、移行済みの v3 の行には適用しない |
| 10 | アンインストール エントリの重複に注意 | 同名が 2 つあり、表示バージョンは実センサー バージョンと異なった。サービスの実行ファイルで確認する |
| 11 | センサー名・作成日時が変わる | 名前が小文字になり、作成日時が移行時刻になった。タグ付け・自動化・管理表への影響を確認する |
| 12 | ポータルの完了表示 ≠ 保護空白の長さ | 完了確認は 18〜32 分後。切替時刻とは別。サービス観測にも欠測がある |
| 13 | Hunting は反映に時間がかかる | 認証の約 8 分後は 0 件、約 52 分後に確認できた。最初の Inactive や 0 件を即断しない |
| 14 | DC は 1 台ずつ | OS 更新の再起動で DC02 は 31〜40 秒、DC01 は約 316〜343 秒の LDAP 不達があった。もう片方の DC が動いている状態で作業する |
| 15 | 検知テストは専用アカウントで | 既存ユーザー、DCSync、総当たりは使わない。テスト後はタグ、ユーザー、OU、秘密を削除する |
11. MDE はどうするのか？
v3 では MDE を残します。 公式の移行要件は「MDE が展開済み（Sense が動作）」で、MDE をアンインストールしたりオフボードしたりすると移行条件を満たせなくなります。
- 移行前後で、Sense は Running、OnboardingState=1 を維持しました
- Defender ウイルス対策は公式要件上、アクティブでもパッシブでも構いません。今回は Normal のままで、MDI の移行を理由に変更していません
- v3 の移行で削除したのは v2 センサーと、他のキャプチャ ソフトが無いことを確認した Npcap だけです
なお、MDE を展開しない新規導入（オンボード パッケージ方式）も公式にはありますが、本記事の「既存 v2 からのインプレース移行」とは別のシナリオです。
12. まとめ
2 台の DC で v2.255 から v3.0.10.445 へ移行し、両台で正常稼働することを確認しました。移行後に v2 と Npcap を削除しても、v3 単独でハニートークン認証を検知し、Defender からの無効化で新規認証が拒否されました。
v3 の価値は、次の 3 点に集約できると感じました。
- DC に残る MDI 関連の部品が減る（Npcap 不要、v2 の検知サービス不要）
- 資格情報の管理が減る（DSA / gMSA 不要、LocalSystem で動作）
- 監査まわりを製品側に寄せられる（自動監査、RPC 監査の自動化、OS 更新と一体の更新）
一方で、移行は「ボタンを押すだけ」ではありません。OS の累積更新、MDE、アクション アカウント、自動監査の前後比較、v2 の後片付けを計画に入れておくと安全と思われます。
本記事が MDI 運用を検討する方の参考になれば幸いです。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。