Microsoft Defender for IdentityでWindowsイベント監査を正しく構成するポイントは、センサーv3.xをドメインコントローラーに展開している場合は自動監査を有効化し、それ以外の環境では手動またはPowerShellで必要な監査ポリシーを確実に設定することです。監査が不足していると、NTLM認証、グループ変更、証明書サービス、AD FS関連の操作など、攻撃検知に必要なイベントをDefender for Identityが十分に解析できない可能性があります。
2026年6月時点で確認すべき中心は、「自動Windowsイベント監査」がDefender for Identityセンサーv3.x向けの推奨構成になっている点です。Microsoft Learnでは、v3.xセンサーをドメインコントローラーに展開する場合は自動監査を推奨し、v2.x、非ドメインコントローラー上のAD FS・AD CS・Microsoft Entra Connect、または自動監査を使わない環境では手動またはPowerShell構成が必要とされています。(Microsoft Learn)
Microsoft Defender for IdentityのWindowsイベント監査で何が変わったのか
今回の要点は、Windowsイベント監査の設定を「管理者がGPOで細かく作り込む前提」から、「v3.xセンサーでは可能な限り自動化する前提」へ寄せていることです。
Defender for Identityは、ドメインコントローラー、AD FSサーバー、AD CSサーバー、Microsoft Entra Connectサーバーから特定のWindowsイベントログを解析します。そのため、対象サーバーで高度な監査ポリシーが不足していると、センサー自体が稼働していても検出の材料が欠けます。(Microsoft Learn)
特に大きい変更点は次の3つです。
| 確認ポイント | 内容 | 管理者への影響 |
|---|---|---|
| 自動監査の推奨 | ドメインコントローラー上のDefender for Identityセンサーv3.xでは、自動Windows監査が推奨される | 手動GPO作成の負担を減らせる |
| 対象外サーバーの明確化 | v2.x、非DCのAD FS・AD CS・Microsoft Entra Connectには自動監査が適用されない | 従来どおり手動またはPowerShell構成が必要 |
| ヘルスアラートとの連動 | 監査構成の不足が検出されるとDefender for Identityの正常性アラートに表示される | 展開後の見落としを把握しやすい |
Microsoftの「What’s new」では、自動Windowsイベント監査構成がセンサーv3.xで一般提供され、新規センサーへの必要な監査設定の適用や既存センサーの誤構成修正を自動化すると説明されています。(Microsoft Learn)
影響を受ける環境
影響を受けるのは、主にオンプレミスActive DirectoryをMicrosoft Defender for Identityで監視している組織です。クラウドのみのMicrosoft Entra ID環境だけを使っている場合、このWindowsイベント監査設定の影響は限定的です。
| 環境 | 対応の考え方 |
|---|---|
| Windows Server 2019以降のドメインコントローラーにv3.xセンサーを展開 | 自動Windowsイベント監査を有効化するのが基本 |
| Windows Server 2016以前のドメインコントローラー | v2.xセンサーを使い、手動またはPowerShellで監査設定を確認 |
| AD FS、AD CS、Microsoft Entra Connectが非ドメインコントローラーで稼働 | 自動監査の対象外。個別に監査設定が必要 |
| v2.xとv3.xが混在する移行中環境 | 自動監査、GPO、gMSA/DSAの扱いを分けて確認 |
| スタンドアロンセンサーを使う環境 | SIEMまたはWindowsイベント転送を手動構成。ただしETWログ収集の制限に注意 |
Defender for Identityの展開ガイドでは、Windows Server 2019以降かつ2026年3月以降の累積更新プログラムが適用されたドメインコントローラーにはv3.xセンサーが推奨され、非ドメインコントローラーのAD FS・AD CS・Microsoft Entra Connectにはv2.xセンサーを使う構成が示されています。(Microsoft Learn)
管理者が最初に確認すべき設定
まず確認すべきなのは、監査設定そのものではなく、どのサーバーに、どのセンサーバージョンが入っているかです。ここを整理しないままGPOを修正すると、自動監査と手動設定が競合したり、非対象サーバーを見落としたりします。
センサーv3.xのドメインコントローラーでは自動監査を有効にする
Defender for Identityセンサーv3.xをドメインコントローラーに展開している場合、Microsoft Defenderポータルから自動監査を有効化します。
手順は次のとおりです。
| 手順 | 操作 |
|---|---|
| 1 | Microsoft Defenderポータルを開く |
| 2 | 設定 → ID に移動する |
| 3 | 全般 セクションの 高度な機能 を開く |
| 4 | Windows の自動監査構成 をオンにする |
有効化すると、センサーは現在の監査構成を確認し、不足している設定を検出し、必要な変更を適用します。対象には、ディレクトリサービスの高度な監査、NTLM監査、ドメインオブジェクト監査、AD FS監査、Windows監査ポリシーなどが含まれます。また、構成状態に関する正常性アラートを送信し、24時間に1回実行されます。(Microsoft Learn)
実務上は、いきなり全ドメインコントローラーで有効化するのではなく、代表的なサイトまたは負荷の低いドメインコントローラーから有効化し、イベントログ量、ヘルスアラート、GPOとの競合を確認してから展開範囲を広げるのが安全です。
GPOとの競合を確認する
自動Windowsイベント監査は、ドメインコントローラーのローカルシステムポリシーへ監査設定を直接適用します。一方で、既存のGPOが同じ監査ポリシーを上書きしている場合、センサーが適用した設定と競合する可能性があります。Microsoft Learnでも、GPO設定がセンサーによって設定されたローカル設定と競合する可能性があると注意されています。(Microsoft Learn)
確認すべき代表例は次のとおりです。
| 確認対象 | 見るべきポイント |
|---|---|
| Default Domain Controllers Policy | 高度な監査ポリシーが既に構成されているか |
| 専用の監査GPO | Defender for Identity用に過去作成したGPOが残っていないか |
| セキュリティベースラインGPO | NTLM監査やログオン監査を別方針で制御していないか |
| ローカルポリシー | 自動監査後にGPOで意図せず戻されていないか |
確認コマンドとしては、対象ドメインコントローラーで次を実行します。
auditpol.exe /get /category:*GPOで管理している場合は、グループポリシー管理コンソールとgpresultの結果も合わせて見ます。
gpresult /h C:\Reports\gpresult.html必要なWindowsイベントをサーバー種別ごとに確認する
Defender for Identityで必要になるイベントは、サーバーの役割によって異なります。すべてのサーバーに同じ監査設定を一律適用するのではなく、役割ごとに必要なイベントを満たすことが重要です。
| サーバー種別 | 主な必要イベント | 主な用途 |
|---|---|---|
| ドメインコントローラー | 4662、4726、4728、4729、4730、4732、4733、4741、4743、4753、4756、4757、4758、4763、4776、5136、7045、8004 | ADオブジェクト変更、グループ変更、NTLM、サービス追加など |
| AD FS | 1202、1203、4624、4625 | フェデレーション認証の成功・失敗、ログオン追跡 |
| AD CS | 4870、4882、4885、4887、4888、4890、4896 | 証明書の発行、拒否、失効、CA設定変更 |
| Microsoft Entra Connect | 4624 | 同期サーバーへのログオン追跡 |
Microsoft Learnでは、ドメインコントローラー、AD FS、AD CS、Microsoft Entra Connectごとに必要なWindowsイベントが整理されています。(Microsoft Learn)
特に見落としやすいのが、イベントID 4662と8004です。4662はディレクトリサービスオブジェクトへの操作を追跡しますが、監査ポリシーを有効にするだけでなく、ドメインオブジェクト側のSACL設定も必要です。8004はNTLM認証の監査で、NTLM利用の把握や不審な認証の検出に関わります。
手動構成が必要なケース
自動監査が便利になっても、すべての環境で使えるわけではありません。次のケースでは、手動構成またはPowerShell構成を前提にします。
| ケース | 理由 |
|---|---|
| センサーv2.xを使っている | 自動Windowsイベント監査の対象外 |
| AD FS、AD CS、Microsoft Entra Connectが非ドメインコントローラー | v3.x自動監査の対象外 |
| 自動監査をあえて無効にしている | 組織のGPO管理方針に合わせる必要がある |
| 変更管理上、GPOで監査設定を明示したい | 監査証跡や承認フローを重視する環境に向く |
| スタンドアロンセンサーを使っている | SIEMまたはWindowsイベント転送の構成が必要 |
手動構成では、ドメインコントローラーに対して「資格情報の検証」「コンピューターアカウント管理」「セキュリティグループ管理」「ユーザーアカウント管理」「ディレクトリサービス変更」「セキュリティシステム拡張機能」「ディレクトリサービスアクセス」などの高度な監査ポリシーを設定します。GPOを適用後、gpupdateを実行し、イベントビューアーのWindows ログ → セキュリティに対象イベントが出ているか確認します。(Microsoft Learn)
NTLM監査はドメインコントローラーに限定する
NTLM監査では、イベントID 8004を収集します。Microsoft Learnでは、Windowsイベント8004を収集するためのドメイングループポリシーはドメインコントローラーにのみ適用するよう注意されています。(Microsoft Learn)
設定する代表的なセキュリティポリシーは次の3つです。
| セキュリティポリシー | 推奨値 |
|---|---|
| ネットワーク セキュリティ: NTLM を制限する: リモート サーバーへの送信 NTLM トラフィック | すべて監査する |
| ネットワーク セキュリティ: NTLM を制限する: このドメインの NTLM 認証を監査する | すべて有効にする |
| ネットワーク セキュリティ: NTLM を制限する: 受信 NTLM トラフィックを監査する | すべてのアカウントの監査を有効にする |
ここで避けたい失敗は、NTLMを「監査」するつもりが、制限や拒否の設定まで進めてしまうことです。NTLM削減は重要ですが、業務アプリケーションがNTLMに依存している環境では認証障害につながる可能性があります。Defender for Identityの要件としては、まず監査イベントを収集できる状態にすることが目的です。
PowerShellで構成を確認・展開する方法
GUIでの確認が難しい大規模環境では、PowerShellを使って現状レポートを出すと効率的です。
現在のWindowsイベント監査構成を確認するには、Defender for Identity PowerShellモジュールのNew-MDIConfigurationReportを使います。
New-MDIConfigurationReport -Path "C:\Reports" -Mode Domain -Identity "DOMAIN\ServiceAccountName" -OpenHtmlReportModeには、GPOから設定を収集するDomainと、ローカルマシンから収集するLocalMachineがあります。Domainモードで実行する場合、対話型プロンプトを避けるために-Identityパラメーターを指定する運用が案内されています。(Microsoft Learn)
監査構成の取得・設定には、次のコマンドも使えます。
Get-MDIConfiguration -Mode Domain -Configuration AllSet-MDIConfiguration -Mode Domain -Configuration AllSet-MDIConfiguration -Mode Domain -Configuration Allは、ドメインのすべての設定を定義し、GPOを作成してリンクするコマンドとして示されています。(Microsoft Learn)
本番環境では、いきなりAllで適用するのではなく、まずGet-MDIConfigurationとNew-MDIConfigurationReportで差分を把握し、変更管理の承認後に段階適用するのが現実的です。
Microsoft Graph APIで自動監査設定を管理する場合
開発者や運用自動化担当者は、Microsoft Graph APIで自動監査設定を取得・更新できます。autoAuditingConfigurationリソースは、Microsoft Defender for Identityの自動監査構成を表し、Windowsイベントビューアーに重要なセキュリティイベントを自動記録する定義済み監査ポリシーを有効化するものです。(Microsoft Learn)
設定状態の取得は次のエンドポイントです。
GET https://graph.microsoft.com/v1.0/security/identities/settings/autoAuditingConfiguration自動監査を有効化する更新例は次のとおりです。
PATCH https://graph.microsoft.com/v1.0/security/identities/settings/autoAuditingConfiguration
Content-Type: application/json
{
"@odata.type": "#microsoft.graph.security.autoAuditingConfiguration",
"isAutomatic": true
}取得にはSecurityIdentitiesAutoConfig.Read.All、更新にはSecurityIdentitiesAutoConfig.ReadWrite.Allが必要です。また、委任アクセスではサインインユーザーにSecurity Administratorロール、またはMicrosoft Defender XDR Unified RBACで作成された対応権限を持つカスタムロールが必要です。(Microsoft Learn) (Microsoft Learn)
自動化するときは、単にisAutomaticをtrueにするだけで終わらせず、実行後にヘルスアラートとセンサー一覧を確認する処理まで含めると運用事故を減らせます。
移行・展開時の注意点
センサーv2.xからv3.xへ移行する場合、Windowsイベント監査だけでなく、OS要件、Defender for Endpoint、ローカルシステムアカウント、gMSA/DSAの扱いも同時に確認します。
v3.xセンサーの前提条件を満たしているか
v3.xセンサーを有効化するサーバーには、Defender for Endpointの展開、v2.xセンサーが未展開であること、Windows Server 2019以降、2026年3月以降の累積更新プログラムなどが求められます。また、v3.xはVPN統合やsyslog通知をサポートしないなどの制限があります。(Microsoft Learn)
移行前のチェック項目は次のとおりです。
| チェック項目 | 確認内容 |
|---|---|
| OS | Windows Server 2019以降か |
| 更新プログラム | 2026年3月以降の累積更新プログラムが適用済みか |
| Defender for Endpoint | 対象サーバーでオンボード済みか |
| 既存センサー | v2.xが移行対象として正常稼働しているか |
| サーバー役割 | 純粋なDCか、AD FS・AD CS・Entra Connectを兼ねるDCか |
| 通信 | Defender for EndpointとDefender for Identityの必要エンドポイントへ接続できるか |
| 監査 | 自動監査を使うか、GPOで管理するか |
Windows Server 2025の移行制限に注意する
2026年5月時点のMicrosoft Learnでは、Windows Server 2025のドメインコントローラーをセンサーv2.xからv3.xへ移行することはサポートされていないとされています。対象サーバーでは、v3.x移行がサポートされるまでv2.xセンサーを継続利用する必要があります。(Microsoft Learn)
新規展開と移行では条件が異なる場合があります。Windows Server 2025を含む環境では、「新規でv3.xを使えるか」と「既存v2.xから移行できるか」を分けて確認してください。
gMSA/DSAからローカルシステムへの切り替えを確認する
v3.xセンサーでは、ADデータの読み取りや応答アクションにローカルシステムIDを使います。v2.xで使っていたDirectory Service AccountやgMSAは、v3.xの監査や応答アクションには使われません。Microsoft Learnでは、v3.xセンサーがある場合は、Microsoft Defenderポータルで「センサーのローカルシステムアカウントを自動的に使用する」設定を選択するよう案内されています。(Microsoft Learn)
移行中にv2.xとv3.xが混在していると、ワークスペースレベルでDSA/gMSAの資格情報検証が残り、v3.xセンサーにも資格情報関連のヘルスアラートが表示される場合があります。すべてのセンサーがv3.xへ移行し、v2.xが不要になった段階でDSA/gMSA設定を整理するのが安全です。(Microsoft Learn)
よくある失敗と回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| 自動監査の対象外サーバーを見落とす | AD FS、AD CS、Entra Connectのイベントが不足する | サーバー役割とセンサーバージョンの棚卸しを先に行う |
| GPOと自動監査が競合する | 設定が戻る、ヘルスアラートが消えない | auditpol、gpresult、GPOリンク順を確認する |
| 4662のSACL設定が不足する | ADオブジェクト変更の検出範囲が不完全になる | ユーザー、グループ、コンピューター、gMSA関連オブジェクトまで設定する |
| NTLM監査を広範囲に適用する | 不要なログ増加や運用混乱を招く | ドメインコントローラーに限定して監査設定を適用する |
| AD CSの監査を無計画に有効化する | CAサービス再起動時に遅延が発生する可能性 | 大規模CAではメンテナンス時間帯に検証する |
| スタンドアロンセンサーへ全syslogを転送する | センサーの処理負荷が上がる | 必要イベントだけを転送する |
AD CSでは、証明機関の監査をPowerShellで有効化する例としてcertutil -setreg CA\AuditFilter 127とRestart-Service certsvcが示されています。ただし、Active Directory Certificate Servicesイベント監査の開始と停止を有効化すると、大規模なAD CSデータベースで再起動遅延が起きる可能性があるため、不要なイベントを有効にしない判断も必要です。(Microsoft Learn)
展開後に確認すべきヘルスアラート
監査設定を変更した後は、Microsoft Defenderポータルのヘルスアラートを確認します。
確認場所は次のとおりです。
| 手順 | 操作 |
|---|---|
| 1 | Microsoft Defenderポータルにサインイン |
| 2 | 設定 → ID に移動 |
| 3 | 展開 の 正常性の問題 を開く |
| 4 | ステータス、問題名、重大度でフィルター |
| 5 | センサー別とグローバルの両方を確認 |
監査関連では、NTLM Auditing、Directory Services Advanced Auditing、Directory Services Object Auditing、Configuration container、ADFS container、AD CS auditingなどの不足がヘルスアラートとして表示されます。Microsoft Learnでは、これらの監査構成は1日1回などのタイミングで検証されるものがあり、正常化まで時間差が出る場合があります。(Microsoft Learn)
なお、一部のv3センサー環境では、監査が正しく構成されていても、手動監査構成を使っている場合にWindowsイベント監査のヘルスアラートが残る既知の問題があります。この場合でもセンサーは正常で検出に影響しないとされ、解決策として自動Windows監査構成の有効化が案内されています。(Microsoft Learn)
管理者・開発者向けチェックリスト
最後に、実際の作業順で確認項目を整理します。
| 順番 | やること | 判断基準 |
| -: | ——————- | ——————————————- |
| 1 | センサー一覧を棚卸しする | v2.x、v3.x、スタンドアロン、非DCサーバーを分類 |
| 2 | v3.x対象DCで自動監査を有効化する | DefenderポータルまたはGraph APIでisAutomatic=true |
| 3 | 自動監査対象外を抽出する | v2.x、非DCのAD FS・AD CS・Entra Connect |
| 4 | 必要イベントを確認する | サーバー種別ごとのイベントIDを満たす |
| 5 | GPO競合を確認する | auditpol、gpresult、GPOリンク順を確認 |
| 6 | PowerShellレポートを取得する | New-MDIConfigurationReportで差分確認 |
| 7 | ヘルスアラートを見る | センサー別・グローバル両方を確認 |
| 8 | 移行中環境のgMSA/DSAを整理する | 全v3化後に不要な資格情報設定を削除 |
| 9 | 変更内容を運用ドキュメントに残す | 監査設定、対象GPO、適用日時、確認結果を記録 |
Microsoft Defender for IdentityのWindowsイベント監査は、単なるログ収集設定ではありません。攻撃検知の精度、ヘルスアラートの信頼性、センサーv3.xへの移行計画に直結する基盤設定です。まずはセンサーのバージョンとサーバー役割を整理し、v3.xのドメインコントローラーでは自動監査を有効化します。そのうえで、対象外サーバーを手動またはPowerShellで補完し、GPO競合とヘルスアラートを確認する流れで進めると、展開後の検出漏れや運用混乱を避けやすくなります。
コメント