Microsoft Defender for Identity センサー v2.x のインストールで最初に確認すべき結論は、展開先のサーバー役割とOSによって、v2.xを入れるべきか、v3.xへ寄せるべきかを分けることです。特に、Windows Server 2019以降のドメインコントローラーではv3.xが推奨される一方、Windows Server 2016のドメインコントローラーや、ドメインコントローラーではないAD FS、AD CS、Microsoft Entra Connectサーバーではv2.xが引き続き重要な選択肢になります。(Microsoft Learn)
この記事では、2026年5月18日時点で確認すべきMicrosoft Defender for Identity センサー v2.xのインストール要点を、管理者向けに整理します。単にセットアップウィザードを実行するだけでなく、前提条件、ネットワーク、プロキシ、サイレントインストール、v3.xへの移行可否、運用後のバージョン確認まで押さえることで、導入後の検知漏れや再起動トラブルを避けやすくなります。
Microsoft Defender for Identity センサー v2.xとは何か
Microsoft Defender for Identity センサーは、オンプレミスのID基盤から信号を収集し、特権昇格、横展開、Kerberos委任の不適切な構成など、IDを起点にした攻撃やリスクを検出するためのコンポーネントです。Microsoftは、ドメインコントローラーにはセンサーを展開し、AD FS、AD CS、Microsoft Entra Connectサーバーがドメインコントローラーではない場合は、それらのサーバーにもv2.xセンサーをインストールする方針を示しています。(Microsoft Learn)
ここで注意したいのは、「Microsoft Defender」と聞いてWindows標準のウイルス対策だけを想定しないことです。この記事の対象は、企業のActive DirectoryやID基盤を監視するMicrosoft Defender for Identityのセンサーです。個人向けのMicrosoft DefenderアプリやMicrosoft Defender Antivirusとは、導入対象も管理画面も異なります。
今回の公式情報で管理者が押さえるべき変更点
今回の「Install the sensor v2.x – Microsoft Defender for Identity」で重要なのは、v2.xのインストール手順そのものだけではありません。v3.xとの使い分け、クラシックセンサーのダウンロード方法、Npcap、アクセスキー、サイレントインストール時の再起動リスクなど、展開判断に関わる実務的な注意点が含まれています。(Microsoft Learn)
| 確認ポイント | 管理者への影響 | 実務での対応 |
|---|---|---|
| Windows Server 2019以降のドメインコントローラーではv3.xを推奨 | すべてのDCにv2.xを新規展開する方針は見直しが必要 | サーバー一覧をOSと役割で分類し、v3.x対象を切り分ける |
| v2.xは「classic sensor」として追加 | Defenderポータルから従来型センサーのパッケージを取得する流れになる | Add sensorから「Continue with classic sensor」を選択する |
| アクセスキーは初期登録用のワンタイムパスワード | キー漏えい時のリスク管理が必要 | 取得後は安全に保管し、定期的に再生成する |
| Npcap OEM 1.0がインストール対象 | 既存Npcapとの競合や設定不備に注意 | 既存Npcapがある場合はバージョン1.0以上と必要設定を確認する |
| サイレントインストールは再起動の可能性あり | DCの予期しない再起動につながる可能性 | 必ずメンテナンス時間帯に実行する |
| v2.xのバージョン表示が詳細化 | トラブルシュート時に正確なバージョン確認がしやすくなる | DefenderポータルのSensors画面やファイルバージョンで確認する |
v2.xを入れるべきサーバー、v3.xを検討すべきサーバー
展開方針は、サーバーの役割とOSで決めます。特に2026年時点では、v2.xとv3.xを混在させる構成も前提に入れて考えるべきです。Microsoftは、Windows Server 2019以降のドメインコントローラーにはv3.x、Windows Server 2016以降の古いDCや、DCではないAD FS、AD CS、Microsoft Entra Connectサーバーにはv2.xを使う構成を示しています。両方のセンサーは同じDefender for Identityワークスペースへレポートできます。(Microsoft Learn)
| サーバー構成 | 推奨される方向性 | 判断のポイント |
|---|---|---|
| Windows Server 2019以降のドメインコントローラー | v3.xを優先検討 | Defender for Endpointの導入、2026年3月以降の累積更新プログラムなどv3.x要件を確認 |
| Windows Server 2016のドメインコントローラー | v2.x | v3.x対象外のため、v2.x前提で容量・ネットワーク・監査設定を確認 |
| DCではないAD FSサーバー | v2.x | Web Application Proxyではなくフェデレーションサーバーが対象 |
| DCではないAD CSサーバー | v2.x | Certification Authority Role Serviceを持つAD CSサーバーが対象 |
| DCではないMicrosoft Entra Connectサーバー | v2.x | アクティブサーバーとステージングサーバーの両方を確認 |
| 専用サーバーでトラフィックを監視する構成 | スタンドアロンセンサー | ポートミラーリングやWindows Event Forwardingなど追加設定が必要 |
v3.xは新しい選択肢ですが、万能ではありません。v3.xはVPN連携やsyslog通知をサポートせず、ExpressRouteに制限があり、Windows Server 2025のドメインコントローラーをv2.xからv3.xへ移行することも現時点ではサポートされていません。v3.xを前提にする場合も、既存機能への影響を確認してから切り替える必要があります。(Microsoft Learn)
インストール前に確認すべき前提条件
Microsoft Defender for Identity センサー v2.xは、ドメインコントローラーやID関連サーバーに直接関わるため、「インストーラーが起動するか」だけで判断してはいけません。ライセンス、権限、.NET Framework、ネットワーク、証明書、サーバー性能を事前に確認しておくことが重要です。
ライセンスと権限
Defender for Identityの展開には、Microsoft 365 E5、Enterprise Mobility + Security E5、Microsoft 365 E5 Security系ライセンス、またはスタンドアロンのDefender for Identityライセンスなどが必要です。また、ワークスペース作成にはMicrosoft Entra IDテナントが必要で、管理者にはSecurity administratorロールが求められます。(Microsoft Learn)
実務では、インストール作業者がローカル管理者権限を持っていても、Defenderポータル側の権限が不足していると、センサーパッケージの取得や状態確認で詰まります。導入前に、ポータル操作を行うアカウントと、サーバー上でセットアップを実行するアカウントを分けて確認しておくと安全です。
サーバー要件
v2.xセンサーは、Windows Server 2016以降のドメインコントローラー、またはAD FS、AD CS、Microsoft Entra Connectサーバーを対象にできます。最小要件として、2コア、6GB RAM、6GBのディスク領域が示されており、ディスクは10GBが推奨されています。RODCもサポート対象です。(Microsoft Learn)
| 項目 | 確認内容 | 注意点 |
|---|---|---|
| OS | Windows Server 2016、2019、2022、2025 | Server 2019は必要な累積更新プログラムを確認 |
| CPU | 最小2コア | 認証負荷が高いDCでは余裕を持つ |
| メモリ | 最小6GB | 仮想環境ではメモリを固定割り当てにする |
| ディスク | 6GB必須、10GB推奨 | ログ領域も含めて監視する |
| 電源設定 | High Performance推奨 | 省電力設定は性能低下の原因になる |
| 時刻同期 | センサー導入先とDC間で5分以内 | 認証・検知の整合性に影響する |
ドメインコントローラーは認証基盤そのものです。CPUやメモリに余裕がない環境では、センサー導入後にログオン遅延やサービス負荷が目立つことがあります。導入前に容量計画を行い、本番DCで警告が出た場合は「警告が出ても進められるから問題ない」と判断しないことが大切です。
.NET Frameworkと再起動
v2.xセンサーのセットアップにはMicrosoft .NET Framework 4.7以降が必要です。未導入の場合、センサーのセットアップパッケージが.NET Frameworkをインストールしますが、その際にサーバー再起動が必要になる可能性があります。(Microsoft Learn)
特にドメインコントローラーでは、再起動のタイミングが業務影響に直結します。サイレントインストールであっても、必要に応じてインストール後に自動再起動される可能性があるため、業務時間中の一括配布は避けるべきです。(Microsoft Learn)
ネットワークとプロキシ
v2.xセンサーはDefender for Identityクラウドサービスと通信するため、外向きのHTTPS通信が必要です。代表的には、ワークスペースのセンサーAPI URLへのTCP 443通信を許可します。複数フォレスト環境では、LDAP、LDAPS、Global Catalog向けの通信も確認が必要です。(Microsoft Learn)
| 用途 | 主な確認項目 |
|---|---|
| クラウド通信 | TCP 443でDefender for Identityクラウドサービスへ接続できるか |
| DNS | TCP/UDP 53で名前解決できるか |
| センサー更新 | ローカルホスト間のTCP 444がブロックされていないか |
| 複数フォレスト | LDAP 389、LDAPS 636、GC 3268、LDAPS to GC 3269の到達性 |
| プロキシ環境 | インストール時にプロキシ設定を同時に指定できるか |
| SSLインスペクション | Defender for Identity通信に対してSSL inspectionが有効になっていないか |
プロキシ環境では、あとから設定変更するより、インストール時点でコマンドラインからプロキシ設定を渡す方法が推奨されています。後日プロキシを変更する場合は、PowerShellまたはAzure CLIを使う流れになります。(Microsoft Learn)
v2.xセンサーのダウンロード手順
v2.xセンサーは、Microsoft Defender XDRポータルから取得します。作業は、センサーを実際にインストールするサーバーではなく、管理端末でパッケージをダウンロードしてから対象サーバーへコピーする形でも構いません。
| 手順 | 操作 | 補足 |
|---|---|---|
| 1 | Microsoft Defender XDRで「System」→「Settings」→「Identities」へ移動 | Identitiesの設定画面を開く |
| 2 | 「Sensors」タブを開く | 既存センサー一覧も確認できる |
| 3 | 「Add sensor」を選択 | 新規センサー追加ペインを開く |
| 4 | 「Continue with classic sensor」を選択 | v2.x用のクラシックセンサーを取得する |
| 5 | ZIPパッケージを保存 | インストーラー、構成ファイル、Npcap OEM 1.0が含まれる |
| 6 | Access keyをコピーして安全に保管 | 初期登録用のワンタイムパスワードとして扱う |
| 7 | 対象サーバーへパッケージをコピー | DCやAD FS、AD CS、Entra Connectサーバーへ配置 |
アクセスキーは、センサーの初期登録に使われます。登録後の通信は証明書による認証とTLS暗号化で行われるため、既存センサーに影響を与えずにキーを再生成できます。運用では、アクセスキーを共有チャットや平文メモに残さず、作業完了後に再生成するルールを設けると安全です。(Microsoft Learn)
ウィザードでv2.xセンサーをインストールする手順
対象サーバー上でインストールを行う前に、ZIPファイルを必ず展開します。ZIPファイル内から直接インストーラーを実行すると失敗します。(Microsoft Learn)
基本手順
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | 対象サーバーがDefender for Identityクラウドエンドポイントへ接続できるか確認 | プロキシ、Firewall、名前解決を確認 |
| 2 | ZIPファイルを展開 | ZIP内から直接実行しない |
| 3 | Azure ATP sensor Setup.exeを管理者として実行 | UAC昇格が必要 |
| 4 | 言語を選択して次へ進む | セットアップウィザードを開始 |
| 5 | 自動判定されたセンサー種別を確認 | DC、AD FS、AD CS、専用サーバーなど |
| 6 | ハードウェア警告が出た場合は内容を確認 | 本番環境では容量不足を軽視しない |
| 7 | インストールパスとAccess keyを入力 | 原則として既定パスを使う |
| 8 | Installを実行 | センサーサービス、Updaterサービス、Npcapなどが構成される |
セットアップウィザードは、対象サーバーがドメインコントローラー、AD FS、AD CS、専用サーバーのいずれかを自動確認し、サーバー種別に応じたセンサーをインストールします。ドメインコントローラー、AD FS、AD CSではDefender for Identityセンサー、専用サーバーではスタンドアロンセンサーがインストールされます。(Microsoft Learn)
Npcapの注意点
v2.xセンサーのインストール時、Npcapが未導入であればNpcap OEM version 1.0が自動的にインストールされます。すでに別のソフトウェア要件などでNpcapを入れている場合は、バージョン1.0以上であることと、Defender for Identityに必要な設定になっていることを確認する必要があります。(Microsoft Learn)
よくある失敗は、ネットワーク調査ツールやパケットキャプチャ用途で古いNpcapを入れていたサーバーに、そのままセンサーを展開するケースです。事前棚卸しでは「Npcapの有無」だけでなく、「バージョン」と「インストールオプション」まで確認してください。
サイレントインストールで一括展開する場合の注意点
Windows Server Coreやソフトウェア配布システムを使う環境では、サイレントインストールが現実的です。ただし、Defender for Identity センサー v2.xのサイレントインストールは、必要に応じて最後にサーバーを自動再起動する構成です。Windows Installerの制約により、norestartフラグで確実に再起動を止めることはできないとされています。(Microsoft Learn)
そのため、サイレントインストールは必ずメンテナンス時間帯に実行します。特にドメインコントローラーへ一括展開する場合は、同一サイト内の複数DCを同時に再起動させないよう、配布リングを分けるべきです。
基本のサイレントインストールコマンド
cmd.exeでは、次の形式で実行します。
"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"PowerShellでは、カレントディレクトリの実行を明示するために .\ を付けます。これを省略すると、サイレントインストールを妨げるエラーになります。(Microsoft Learn)
.\"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"アクセスキーをファイルで渡す場合は、次のように指定できます。
"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKeyFile="C:\Path\myAccessKeyFile.txt"配布システムを使う場合は、.NET Framework 4.7以降の展開パッケージと、Defender for Identityセンサーの展開パッケージを分け、センサー側を.NET Frameworkの展開後に実行する依存関係にしておくと、再起動や失敗時の切り分けがしやすくなります。(Microsoft Learn)
プロキシ環境でのサイレントインストール
プロキシを使う環境では、インストールと同時にプロキシ設定を渡します。
"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>" ProxyUrl="http://proxy.internal.com:8080" ProxyUserName="domain\proxyuser" ProxyUserPassword="ProxyPassword"プロキシ認証情報はセンサー側で暗号化され、ローカルに保存されます。ただし、コマンド履歴、配布システムのログ、タスク定義に資格情報が残る可能性があります。実務では、配布後にログの取り扱いを確認し、プロキシ認証に個人アカウントではなく管理された専用アカウントを使うことを推奨します。(Microsoft Learn)
インストール後に必ず確認する項目
センサーのインストールが完了しても、それだけで運用開始と判断するのは危険です。Defenderポータル上の状態、サービス状態、バージョン、ヘルスアラートを確認し、必要な追加設定を済ませます。
Microsoft Defenderポータルでは、Settings → Identities → On-premises → Sensorsから、センサー一覧を確認できます。Sensorsタブでは、センサー種別、ドメイン、移行状態、サービス状態、センサー状態、バージョン、遅延更新、ヘルス状態などを確認できます。(Microsoft Learn)
| 確認項目 | 正常時の目安 | 異常時の見方 |
|---|---|---|
| Service status | Running | Stopped、Disabled、Unknownならサービスや通信を確認 |
| Sensor status | Up to date | Outdated、Update failed、Not Configuredは追加対応が必要 |
| Health status | Healthy | 黄・橙・赤のヘルス問題を開いて原因を確認 |
| Version | 想定したバージョンが表示 | Programs and Featuresだけでなくポータル側も確認 |
| Migration state | 対象外またはReady/Up to dateなど | v3.x移行対象かどうかの判断材料になる |
v2.xセンサーでは、バージョン2.176以降、新しいパッケージからインストールした場合に「プログラムの追加と削除」で 2.176.x.y のような完全な番号が表示されます。以前のように静的な 2.0.0.0 と表示されるだけではありません。実際のバージョンは、Microsoft Defender XDRのセンサー設定ページ、実行ファイルのパス、ファイルバージョンでも確認できます。(Microsoft Learn)
v2.xからv3.xへ移行できるか確認する
既存環境ですでにv2.xセンサーを運用している場合、Windows Server 2019以降のドメインコントローラーではv3.xへの移行も検討対象になります。Microsoft Defenderポータルからv2.xからv3.xへ移行でき、移行中もv2.xセンサーはv3.xの準備が整うまで稼働し続けるため、ダウンタイムやデータ重複を避けた移行が可能とされています。(Microsoft Learn)
ただし、移行には条件があります。対象サーバーは追加のIDロールを持たないドメインコントローラーであること、v2.xセンサーが一定バージョン以上であること、Windows Server 2019以降であること、Microsoft Defender for Endpointが展開済みであること、2026年3月以降の累積更新プログラムが入っていることなどが必要です。(Microsoft Learn)
| 移行条件 | 確認方法 |
|---|---|
| 追加IDロールのないドメインコントローラー | AD FS、AD CS、Microsoft Entra Connectを同居させていないか確認 |
| v2.xセンサーが稼働中 | Sensors画面または sc query AATPSensorUpdater で確認 |
| v2.xセンサーが必要バージョン以上 | Programs and FeaturesまたはSensors画面で確認 |
| Windows Server 2019以降 | winver やサーバー台帳で確認 |
| 2026年3月以降の累積更新プログラム | 更新履歴やビルド番号で確認 |
| Defender for Endpointが展開済み | Client AnalyzerやDefenderポータルで確認 |
移行後はv2.xセンサーサービスが無効化されますが、v2.xソフトウェア自体はサーバーに残ります。完全にクリーンアップするには、v2.xセンサーのアンインストールと、他アプリで使っていない場合のNpcap削除を検討します。Npcapはv3.xでは不要ですが、残っていてもv3.xセンサーには影響しないとされています。(Microsoft Learn)
展開時に失敗しやすいポイント
Microsoft Defender for Identity センサー v2.xの導入で失敗しやすいのは、インストールコマンドそのものより、事前確認と展開設計です。以下のポイントは、導入計画書や変更申請に入れておくとトラブルを減らせます。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| ZIP内から直接セットアップを実行して失敗 | インストールファイルを展開していない | 必ずローカルフォルダーへ展開してから実行 |
| 業務時間中にDCが再起動 | .NET Framework導入やセットアップ後再起動 | メンテナンス時間帯に実行し、DCごとに展開順を分ける |
| プロキシ環境でクラウドへ接続できない | 必要なFQDNやTCP 443が許可されていない | 事前に通信テストとプロキシ例外を確認 |
| Npcap競合でセンサーが正常動作しない | 既存Npcapのバージョンや設定が不適切 | 既存Npcapの棚卸しを行う |
| v3.x対象サーバーにv2.xを新規導入 | OSと役割の分類が不十分 | サーバー台帳でDC、非DC、IDロール、OSを分類 |
| ポータルではNot Configuredのまま | AD FS、AD CS、スタンドアロンなどで追加構成が未完了 | インストール後の追加手順をチェックリスト化 |
| バージョン確認をローカル表示だけで判断 | 自動更新後の実バージョンを見落とす | Sensors画面、実行ファイル、ファイルバージョンも確認 |
管理者向けの導入チェックリスト
実際に作業する前に、次の順番で確認すると抜け漏れを防げます。
| フェーズ | 確認すること |
|---|---|
| 計画 | 対象サーバーをDC、AD FS、AD CS、Microsoft Entra Connect、専用サーバーに分類する |
| 方針決定 | Windows Server 2019以降のDCはv3.x、v2.x継続対象はv2.xとして整理する |
| 権限確認 | Defenderポータル操作権限、サーバー管理者権限、変更承認を確認する |
| 前提条件 | .NET Framework、OS、CPU、メモリ、ディスク、時刻同期を確認する |
| 通信確認 | TCP 443、プロキシ、DNS、複数フォレスト時のLDAP/LDAPSを確認する |
| パッケージ取得 | Defenderポータルからclassic sensorをダウンロードし、Access keyを安全に保管する |
| 展開 | ZIPを展開し、管理者権限でセットアップまたはサイレントインストールを実行する |
| 検証 | Sensors画面でService status、Sensor status、Health status、Versionを確認する |
| 運用 | 遅延更新、ヘルスアラート、v3.x移行対象を定期的に確認する |
次に取るべき対応
Microsoft Defender for Identity センサー v2.xの公式情報を受けて、管理者が最初に行うべきことは、インストーラーの取得ではなく対象サーバーの棚卸しです。ドメインコントローラー、AD FS、AD CS、Microsoft Entra Connect、スタンドアロンセンサー候補を一覧化し、OS、既存センサー、Defender for Endpointの有無、プロキシ経路、再起動可能時間を整理してください。
そのうえで、Windows Server 2019以降のドメインコントローラーはv3.xの要件を確認し、v2.xが必要なサーバーには前提条件とメンテナンス時間帯を確保して展開します。インストール後は、Microsoft DefenderポータルのSensors画面で状態とバージョンを確認し、ヘルスアラートが残っていないことを確認してから本番運用に入るのが安全です。
コメント