Getting domain controller security events into Microsoft Sentinel is deceptively complex. This document covers the pipeline from audit policy generation on the domain controller through event routing into the SecurityEvent table, focusing on the configuration decisions that determine whether critical events like 5136 (directory service changes), 4723 (password change attempts), and 4724 (password resets) actually reach Sentinel’s analytics engine.

The agent migration alone (from the retired Microsoft Monitoring Agent (MMA) to the Azure Monitor Agent (AMA)) introduces Azure Arc as a mandatory intermediary, which places a cloud-managed agent on your most privileged servers. Miss one step in the chain (an audit policy subcategory left at “No Auditing,” a Data Collection Rule that omits the PDC Emulator, an XPath filter deployed without local testing) and entire classes of detections go silent with no error and no alert.

Key Takeaways:

  • MMA cloud ingestion shut down after March 2, 2026. Any domain controller still running only MMA is no longer forwarding security events. AMA with Data Collection Rules is the only supported path.
  • Azure Arc on a domain controller is a Tier-0 security decision. Without agent hardening and subscription isolation, any Azure subscription administrator becomes an effective Domain Admin.
  • Event ID 5136 is in the Common event set but NOT Minimal. Selecting “Minimal” in the DCR silently drops all directory service change events.
  • Advanced Audit Policy must be explicitly enabled and verified with auditpol.exe. The Resultant Set of Policy console (rsop.msc) does not display Advanced Audit Policy subcategories and will mislead you.
  • GPMC-initiated GPO modifications generate 5136 events on the PDC Emulator (GPMC connects there by default). However, other AD write operations (scripted provisioning, Azure AD Connect sync, application-driven LDAP writes) generate 5136 on whichever DC processes the write. Deploy AMA on all writable DCs; prioritise the PDC Emulator for GPO change visibility specifically.
  • Most 5136 event-specific fields are NOT pre-parsed columns in SecurityEvent. Fields like ObjectDN, AttributeValue, OpCorrelationID, and AttributeLDAPDisplayName must be extracted from the EventData XML using parse_xml(). Only OperationType is available as a direct column. Any KQL rule that references these fields as bare column names will fail silently.
  • Sentinel stores raw operation codes (%%14674, %%14675), not friendly text. Any detection rule filtering on "Value Added" or "Value Deleted" matches nothing.

Table of Contents

  1. Prerequisites Overview
  2. Agent Architecture: Migrating from MMA to AMA
  3. Azure Arc Prerequisites for Domain Controllers
  4. Configuring Advanced Audit Policy on Domain Controllers
  5. Data Collection Rules: Event Sets, XPath Filtering, and Cost
  6. Collection Architecture: SecurityEvent vs. WindowsEvent Tables
  7. Critical Gotchas
  8. Microsoft Defender for Identity: Coexistence and Complementarity
  9. Verification and Troubleshooting
  10. Sentinel Analytics Rules Dependent on These Events
  11. Anti-Patterns Consolidated
  12. Authoritative Sources

1. Prerequisites Overview

Before a single domain controller security event reaches Sentinel, four layers must be correctly configured. A failure at any layer silently breaks the entire pipeline:

Layer Component What It Controls
Audit Policy Advanced Audit Policy GPO Whether the DC generates the events in its local Security log
Agent Platform Azure Arc (Connected Machine agent) Whether the DC is visible to Azure as a manageable resource
Collection Agent Azure Monitor Agent (AMA) Whether events are read from the local Security log and transmitted
Collection Rule Data Collection Rule (DCR) Which events are selected, filtered, and routed to which table

Each layer depends on the one above it. A perfectly configured DCR is useless if the audit policy never generates the target events. A correctly tuned audit policy produces events that go nowhere if AMA is not installed, or if the DCR filters them out.

The sections that follow address each layer in order, from audit policy through to Sentinel table routing.

Pipeline Architecture

The four layers are strictly sequential. Failure at any layer silently breaks all downstream detection:

flowchart LR
    A["🔐 Audit Policy\n(GPO / auditpol.exe)\nGenerates events\nin Security log"] --> B["☁️ Azure Arc\n(Connected Machine Agent)\nRegisters DC as\nAzure resource"]
    B --> C["📡 Azure Monitor Agent\n(AMA)\nReads Security log\nand transmits"]
    C --> D["📋 Data Collection Rule\n(DCR)\nFilters and routes\nto destination"]
    D --> E["📊 SecurityEvent Table\n(Microsoft Sentinel)\nAnalytics rules\nquery here"]

    style A fill:#d4edda,stroke:#28a745
    style B fill:#d1ecf1,stroke:#17a2b8
    style C fill:#fff3cd,stroke:#ffc107
    style D fill:#f8d7da,stroke:#dc3545
    style E fill:#e2d9f3,stroke:#6f42c1

Troubleshooting shortcut: Start from the left. If auditpol /get shows the correct subcategory, the first layer is healthy. If Get-WinEvent returns results but Sentinel shows nothing, the failure is in the AMA or DCR layers. Work left to right.

2. Agent Architecture: Migrating from MMA to AMA

MMA End of Life

Microsoft retired the Microsoft Monitoring Agent (MMA, also known as the Log Analytics agent) on August 31, 2024. Cloud-side ingestion for MMA underwent a 12-hour validation pause on January 26, 2026, and the hard shutdown occurred after March 2, 2026. Any domain controller still relying exclusively on MMA for security event forwarding is no longer sending data to Sentinel.

The AMA Model

AMA is architecturally different from MMA in three ways:

  • Data Collection Rules (DCRs) govern what AMA collects, replacing the workspace-level configuration that MMA used. Each DCR specifies data sources, filtering criteria, and destination tables.
  • Managed Identity authentication replaces workspace keys. AMA authenticates to Log Analytics using the machine’s Azure identity rather than a shared workspace ID and key.
  • Higher throughput: AMA handles significantly higher throughput than MMA and supports multi-homing to multiple workspaces, which matters on busy domain controllers.

Migration Sequencing

The correct migration sequence for domain controllers is:

  1. Deploy Azure Arc and harden the agent (Section 3)
  2. Install AMA and configure DCRs (Sections 5-6)
  3. Run AMA alongside MMA briefly to validate event parity
  4. Disable MMA’s Security Events data collection
  5. Confirm AMA-only ingestion via the Heartbeat and SecurityEvent tables
  6. Uninstall MMA

Running MMA and AMA simultaneously for an extended period causes duplicate events and double billing. The overlap window should be measured in days, not weeks.

3. Azure Arc Prerequisites for Domain Controllers

Why Arc Is Required

AMA on non-Azure (on-premises or other-cloud) servers requires Azure Arc. The Arc Connected Machine agent registers the server as an Azure resource, providing the managed identity and extension management framework that AMA depends on. There is no way to install AMA on an on-premises domain controller without first onboarding it to Azure Arc.

Tier-0 Security Implications

Onboarding a domain controller to Azure Arc introduces a cloud-based management plane to your most privileged infrastructure. The Arc agent’s extension manager runs as Local System on the DC. By default, any user with sufficient RBAC on the Azure subscription or resource group containing the Arc resource can deploy extensions, which execute as SYSTEM, making them an effective Domain Admin.

This is not a theoretical risk. It is the single most consequential security decision in the entire DC log ingestion pipeline.

Mandatory Hardening

Immediately after onboarding each domain controller to Arc, run the following hardening commands:

# Disable SSH and remote connectivity to the Arc agent
azcmagent config set incomingconnections.enabled false

# Disable Guest Configuration (policy evaluation on the DC)
azcmagent config set guestconfiguration.enabled false

# Restrict extensions to ONLY the monitoring agent and (optionally) MDE
azcmagent config set extensions.allowlist "Microsoft.Azure.Monitor/AzureMonitorWindowsAgent,Microsoft.Azure.AzureDefenderForServers/MDE.Windows"

The extensions.allowlist is critical. Only explicitly listed extensions can be installed; this prevents any Azure administrator from deploying arbitrary extensions (Custom Script Extension, Run Command, etc.) that would execute as SYSTEM on the DC. Don’t use a blocklist; it cannot anticipate future extension types.

Subscription and Resource Group Isolation

Place domain controller Arc resources in a dedicated Azure subscription with tightly restricted RBAC. Do not co-locate DC Arc resources with general-purpose server resources. The Azure administrators of the subscription that contains DC Arc objects hold implicit Tier-0 access, and that boundary must be managed accordingly.

Network Requirements

The Arc agent requires outbound HTTPS (TCP 443) to approximately 10+ Azure endpoints:

  • login.microsoftonline.com (Azure AD/Entra ID authentication)
  • management.azure.com (Azure Resource Manager)
  • *.his.arc.azure.com (Arc metadata and identity services)
  • *.guestconfiguration.azure.com (Guest Configuration, though disabled for DCs)
  • Additional regional endpoints for telemetry and extension download

TLS 1.2 or 1.3 is required for all Arc agent connections. Older TLS versions are rejected.

Service Account Considerations

The Arc agent runs under the NT SERVICE\himds identity, which requires the “Log on as a service” user right. Hardened domain controller GPOs frequently restrict this right to a narrow list of accounts. Verify that your DC security baseline GPO does not strip this right, or add NT SERVICE\himds explicitly before onboarding.

Onboarding Sequence Summary

  1. Register Azure resource providers: Microsoft.HybridCompute, Microsoft.GuestConfiguration, Microsoft.HybridConnectivity
  2. Create a dedicated resource group in an isolated subscription
  3. Assign RBAC (Azure Connected Machine Onboarding role at minimum)
  4. Configure firewall rules for all required endpoints
  5. Verify TLS 1.2/1.3 is enabled on the DC
  6. Ensure NT SERVICE\himds has “Log on as a service”
  7. Generate and run the onboarding script
  8. Immediately execute the three hardening commands above
  9. Verify agent status: azcmagent show should report Status: Connected

4. Configuring Advanced Audit Policy on Domain Controllers

No amount of agent and DCR configuration matters if the domain controller never generates the target events. Audit policy is the foundation of the entire pipeline.

Event-to-Subcategory Mapping

Each Security event is produced by a specific Advanced Audit Policy subcategory. Misconfiguring the subcategory (or configuring the wrong one) is the most common cause of missing events:

Event ID Description Subcategory Category
4723 Password change attempt Audit User Account Management Account Management
4724 Password reset attempt Audit User Account Management Account Management
5136 Directory object modified Audit Directory Service Changes DS Access
5137 Directory object created Audit Directory Service Changes DS Access
5141 Directory object deleted Audit Directory Service Changes DS Access
4662 Operation performed on directory object Audit Directory Service Access DS Access

A critical distinction: events 4723 and 4724 fall under Account Management, not DS Access. Event 5136 falls under DS Access > Audit Directory Service Changes, which defaults to “No Auditing” on a fresh Windows Server installation. If you do not explicitly enable this subcategory, event 5136 will never appear in the Security log regardless of what AMA or the DCR is configured to collect.

GPO Configuration

Create a dedicated Group Policy Object (do not modify the Default Domain Controllers Policy) and link it to the Domain Controllers OU. Do not link it to the domain root; Advanced Audit Policy settings are computer-scoped and should apply only to DCs.

Exact GPO paths:

For Event 5136 (and 5137, 5141):

Computer Configuration > Policies > Windows Settings > Security Settings >
  Advanced Audit Policy Configuration > Audit Policies >
    DS Access > Audit Directory Service Changes -> Success and Failure

For Events 4723 and 4724:

Computer Configuration > Policies > Windows Settings > Security Settings >
  Advanced Audit Policy Configuration > Audit Policies >
    Account Management > Audit User Account Management -> Success and Failure

The Legacy vs. Advanced Audit Policy Conflict

Windows supports two audit policy systems: the legacy 9-category model (under Local Policies > Audit Policy) and the modern ~60-subcategory Advanced Audit Policy. These two systems conflict. When both are defined, the legacy settings override the advanced subcategory settings unless explicitly overridden.

To prevent this, enable the force override setting:

Computer Configuration > Policies > Windows Settings > Security Settings >
  Local Policies > Security Options >
    "Audit: Force audit policy subcategory settings (Windows Vista or later)
     to override audit policy category settings" -> Enabled

This sets the registry value:

HKLM\System\CurrentControlSet\Control\LSA\SCENoApplyLegacyAuditPolicy = 1 (DWORD)

Ensure all nine legacy audit policy categories are set to “Not Defined” in any GPO that applies to DCs. Setting them to “No Auditing” is not the same; “No Auditing” is an active configuration that can override the advanced subcategory settings. “Not Defined” leaves them inert.

The audit.csv Silent Failure

Advanced Audit Policy settings are stored in audit.csv files within SYSVOL. A corrupt or empty audit.csv file silently disables all Advanced Audit Policy settings on any DC that processes it. If audit events unexpectedly stop appearing after a GPO change, inspect the audit.csv file in the relevant GPO folder under SYSVOL.

SYSVOL path for audit.csv:

\\<domain>\SYSVOL\<domain>\Policies\{GPO-GUID}\Machine\Microsoft\Windows NT\Audit\audit.csv

A local cached copy also exists at:

C:\Windows\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv

Recovery procedure when audit.csv is corrupt or causing issues:

  1. In the Group Policy Management Editor, set all Advanced Audit Policy subcategories in the affected GPO to “Not Configured”
  2. Delete the audit.csv file from the SYSVOL path shown above (within the GPO’s folder structure)
  3. Also delete the local cached copy on each affected DC at %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv
  4. Run gpupdate /force on all affected domain controllers
  5. Verify with auditpol /get /category:* that settings have cleared
  6. Re-configure the Advanced Audit Policy subcategories to the desired state in the GPO
  7. Run gpupdate /force again and verify with auditpol that the new settings are applied

Note: Until you delete both the SYSVOL copy and the local cached copy, re-configuring settings in the GPO editor alone may not take effect.

SACL Requirements for Event 5136

Event 5136 also requires appropriate System Access Control List (SACL) entries on the target Active Directory objects. The default AD schema includes inherited SACLs that cover most common objects (OUs, group policy containers, user/computer objects). In most environments, the default SACLs are sufficient. However, if your environment has customized or stripped default SACLs, event 5136 may not fire even with the correct audit policy.

Verification

Do not use rsop.msc to verify Advanced Audit Policy. The Resultant Set of Policy console does not display Advanced Audit Policy subcategories and will show misleading results.

Use auditpol.exe on each domain controller:

auditpol /get /subcategory:"Directory Service Changes"
auditpol /get /subcategory:"User Account Management"
reg query "HKLM\System\CurrentControlSet\Control\LSA" /v SCENoApplyLegacyAuditPolicy

Expected output for “Directory Service Changes” should show “Success and Failure”. The registry value should be 0x1.

Run these commands on every DC, not just one. GPO replication delays, WMI filter exclusions, or security filtering misconfigurations can cause inconsistent policy application across the domain.

5. Data Collection Rules: Event Sets, XPath Filtering, and Cost

With audit policy generating events and AMA installed via Arc, the Data Collection Rule determines which events actually leave the DC and enter Sentinel.

Event Set Presets

The “Windows Security Events via AMA” connector offers three presets plus custom XPath:

Preset Event Coverage Key Inclusions Key Exclusions
Minimal ~38 distinct event IDs1 4723, 4724, 8004 5136, 5137, 4662, 4768
Common ~130 distinct event IDs1 4723, 4724, 5136, 5137, 4662, 4768 –
All Events Every Security log event Everything Nothing
Custom XPath-defined Whatever you specify Everything else

The critical detail: Event ID 5136 is in Common but NOT in Minimal. If your DCR uses the Minimal preset, directory service change events (object modifications, creations, deletions) are silently dropped. Events 4723 and 4724 appear in both Minimal and Common.

Common is the recommended baseline for domain controllers. It covers the event set needed for the vast majority of Sentinel analytics rules targeting Active Directory.

Custom XPath Filtering

For environments that need precise control over which events are collected (whether to reduce cost on high-volume DCs or to capture specific events outside the presets), DCRs support custom XPath expressions.

Syntax for collecting events 5136, 4723, and 4724:

Security!*[System[(EventID=5136) or (EventID=4723) or (EventID=4724)]]

XPath filtering happens at the agent, before transmission. Filtered events never leave the DC, so custom XPath directly reduces both network and ingestion costs.

XPath limitations:

  • XPath 1.0 only: starts-with() and contains() are not supported
  • Maximum 20 XPath expressions per condition box in the portal
  • Maximum 100 condition boxes per DCR2

Important: Get-WinEvent -FilterXPath supports up to 23 XPath expressions, which is three more than the AMA DCR limit of 20. If you build and test an XPath filter locally with Get-WinEvent that uses 21-23 expressions, it will work locally but fail silently when deployed as a DCR. Always ensure your XPath expressions stay within the 20-expression DCR limit. Do not rely solely on Get-WinEvent success as proof that a filter will work in a DCR.

Always test XPath locally before deploying via DCR (keeping the 20-expression limit in mind):

Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=5136]]" -MaxEvents 5

If this returns no results on a DC where you expect 5136 events, the problem is audit policy (Section 4), not the DCR. If it returns results but Sentinel shows nothing, the problem is the DCR configuration or agent health (Section 9).

Tip: To extract valid XPath from Event Viewer, open a filter on the Security log, switch to the XML tab, and copy the content of the <Select> element. Prepend Security! to use it in a DCR.

Cost Analysis

Cost in Sentinel is driven by ingested data volume, not event count. Use _BilledSize for accurate cost analysis:

SecurityEvent
| where TimeGenerated > ago(30d)
| summarize SizeInGB = sum(_BilledSize) / 1e9 by EventID
| sort by SizeInGB desc

On busy domain controllers, event 5136 can generate substantial volume, particularly in environments with frequent GPO modifications or automated AD attribute changes. If cost is a concern, custom XPath filtering for only the event IDs required by your detection rules is more economical than the full Common preset.

DCR Ingestion-Time Transformations

DCRs support lightweight KQL transformations that run at the ingestion pipeline, before data is written to the Sentinel workspace. DCR transformations complement XPath filtering: where XPath operates on the agent (filtering by event ID), DCR transformations operate on the cloud pipeline (filtering or reshaping events that have already been selected).

If a specific service account (for example, an Azure AD Connect MSOL_ account) generates thousands of expected 5136 events per hour, a DCR transformation can:

  • Drop those specific events entirely (they never reach the workspace, so they are never billed)
  • Strip out heavy, unused XML fields from the EventData column to reduce _BilledSize per event without losing the broader 5136 coverage

Example transformation to drop expected MSOL_ sync events:

source
| where EventID == 5136
| where not(SubjectUserName startswith "MSOL_")

This transformation would be applied in the DCR’s transformKql property (via ARM/Bicep or the Azure portal’s DCR transformation editor). Events matching the exclusion condition are dropped at ingestion and never billed.

Important: DCR transformations run against a pre-parsed representation of the event, so fields like SubjectUserName (a pre-parsed SecurityEvent column) are available without parse_xml(). However, fields that are only available inside EventData XML (such as ObjectDN or AttributeValue) are not accessible in transformation KQL; for those, use XPath pre-filtering at the agent level instead.

Avoiding Duplicate Ingestion

If multiple DCRs target the same machine and collect overlapping event IDs, the events are ingested multiple times. Each copy is billed separately. Ensure that only one DCR collects security events from each domain controller, or that custom XPath expressions across DCRs do not overlap.

Important: Use the Sentinel Connector, Not Generic Azure Monitor

When creating DCRs, use the “Windows Security Events via AMA” connector in Sentinel (or its equivalent ARM/Bicep/API with stream Microsoft-SecurityEvent). A generic Azure Monitor DCR for Windows Event Logs routes data to the Event table, not the SecurityEvent table. Data in the Event table is not recognized by Sentinel’s built-in analytics rules.

6. Collection Architecture: SecurityEvent vs. WindowsEvent Tables

Sentinel has two tables that can receive Windows Security events, and the choice between them has far-reaching consequences for detection coverage.

Direct AMA: The SecurityEvent Table

When AMA is installed directly on a domain controller and configured via the “Windows Security Events via AMA” connector, events land in the SecurityEvent table. This table provides over 150 pre-parsed columns: TargetUserName, SubjectUserSid, OperationType, Account, and many more are extracted and typed as first-class fields.

However, not all event-specific fields are pre-parsed. For Event ID 5136 (directory service changes), critical fields such as ObjectDN, AttributeValue, OpCorrelationID, and AttributeLDAPDisplayName are not pre-parsed columns. They remain packed in the EventData XML field and must be extracted at query time (see Section 7.3 for the extraction pattern).

WEC Forwarding: The WindowsEvent Table

When events are collected from a Windows Event Collector (WEC) server using the “Windows Forwarded Events” connector, they land in the WindowsEvent table. This table has approximately 25 columns, with most event-specific data parsed into a single EventData dynamic field (converted from the original XML at ingestion time; if XML parsing fails at ingestion, the raw XML falls back to the RawEventData string column). Queries use dot-notation to access fields directly:

// SecurityEvent (direct AMA) -- pre-parsed fields available for many events
SecurityEvent
| where EventID == 4625
| where TargetUserName !endswith "$"

// WindowsEvent (WEC forwarding) -- requires extraction
WindowsEvent
| where EventID == 4625
| extend TargetUserName = tostring(EventData.TargetUserName)
| where TargetUserName !endswith "$"

AMA on WEC is now supported: Organizations no longer need to run the legacy MMA on the WEC collector server. AMA installed on the WEC server, using the Windows Forwarded Events DCR template, performs the same collection function. However, this does not resolve the SecurityEvent vs WindowsEvent schema gap; events forwarded through a WEC server still land in WindowsEvent regardless of whether AMA or MMA collected them from the WEC host. The architectural trade-off (schema gap, limited OOTB rule coverage) remains identical; only the collection agent changes.

Why This Matters for Detection

Microsoft’s out-of-the-box (OOTB) Sentinel analytics rules (the ones installed via the Windows Security Events solution in Content Hub) query the SecurityEvent table directly. The Windows Forwarded Events solution contains only 2 analytics rules (as of last review; this may change with Content Hub updates). There is no 1-to-1 parity between the tables.

While ASIM (Advanced Security Information Model) parsers exist that normalize across both tables, the OOTB analytics rules have not yet been migrated to use ASIM uniformly. This means that events routed through a WEC forwarder into the WindowsEvent table are effectively invisible to most built-in Sentinel detections.

Bridging the Table Gap with ASIM Parsers

Microsoft’s strategic direction is moving away from querying raw tables (SecurityEvent, WindowsEvent) and toward querying ASIM unified parsers, normalized virtual tables that abstract the underlying data source. The relevant parser for directory and audit events is:

ASIM Parser Normalized Over Use Case
imAuditEvent3 SecurityEvent, WindowsEvent, and others Directory changes, account management

Note on IdentityDirectoryEvents: This is a raw Microsoft Defender XDR Advanced Hunting table populated by the MDI sensor — it is not an ASIM normalised parser, and there is currently no ASIM Identity Directory Events schema. See Section 8 for how IdentityDirectoryEvents compares to SecurityEvent for detection coverage.

For WEC environments: If your organisation must route events through a Windows Event Collector (landing in WindowsEvent), deploying the ASIM parsers means custom analytics rules do not need to be written twice: once for SecurityEvent and once for WindowsEvent. A rule targeting imAuditEvent works regardless of which underlying table holds the data.

Current state caveat: As of early 2026, Microsoft’s out-of-the-box Sentinel analytics rules have not been uniformly migrated to ASIM. The OOTB rules still query SecurityEvent directly. ASIM parsers are most useful for custom detection rules where you want table-agnostic logic, or for organizations that need to normalize across mixed collection architectures. Check the ASIM documentation for current parser availability and GA status before building a detection program around them.

Recommendation for Domain Controllers

Use direct AMA installation (SecurityEvent table) for all domain controllers. This is Microsoft’s official recommendation for security monitoring workloads. WEC-based architectures are appropriate for large-scale endpoint collection (40,000-100,000+ machines) or environments with strict network segmentation requirements, but domain controllers should always have AMA installed directly.

Do not run both the direct AMA connector and a WEC forwarder for the same DC. This produces duplicate events across two tables, doubles cost, and provides no detection benefit.

7. Critical Gotchas

7.1 Event ID 5136: Raw Operation Codes

When event 5136 arrives in the SecurityEvent table, the OperationType field (which IS a pre-parsed column) contains the raw Windows message code, not the human-readable string:

Raw Code Friendly Name
%%14674 Value Added
%%14675 Value Deleted
%%14676 (DSType) Active Directory Domain Services

The friendly text you see in Event Viewer on the DC itself is rendered by local message DLLs (adtschema.dll). Sentinel does not have access to these DLLs and stores only the raw code.

Any KQL detection rule that filters on OperationType == "Value Added" will match zero events. The correct filter is:

SecurityEvent
| where EventID == 5136
| extend OperationTypeFriendly = case(
    OperationType == "%%14674", "Value Added",
    OperationType == "%%14675", "Value Deleted",
    OperationType)

The DSType field exhibits the same behavior: %%14676 rather than “Active Directory Domain Services.”

7.2 The PDC Emulator and 5136 Event Distribution

Group Policy Management Console (GPMC) connects to the PDC Emulator FSMO role holder by default. This means that GPMC-initiated GPO modifications generate 5136 events on the PDC Emulator.

Other AD write operations (scripted provisioning, Azure AD Connect sync, application-driven LDAP writes) generate 5136 on whichever DC processes the write. Deploy AMA on all writable DCs; prioritise the PDC Emulator for GPO change visibility specifically.

If AMA and the DCR are deployed on every domain controller except the PDC Emulator, you lose visibility into GPO-driven directory changes made via GPMC. This is a silent blind spot for a high-value event category.

Identify the PDC Emulator:

Get-ADDomain | Select-Object PDCEmulator
# or
netdom query fsmo

Always confirm that the PDC Emulator has Arc, AMA, and a properly configured DCR before considering DC log ingestion operational. Then ensure all other writable DCs are also covered to capture the full spectrum of directory modifications.

Note that password change events (4723, 4724) behave differently: they are logged on the DC that services the authentication request, and also forwarded to the PDC Emulator via Netlogon RPC. These events are less concentrated on a single DC, but the PDC Emulator still receives copies.

7.3 Paired 5136 Events, the OpCorrelationID, and EventData Extraction

A single Active Directory attribute modification generates two 5136 events:

  1. One with OperationType = %%14675 (Value Deleted) containing the old value
  2. One with OperationType = %%14674 (Value Added) containing the new value

These two events share the same OpCorrelationID GUID, which links them as a single logical operation.

Critical: EventData XML Extraction Required

While OperationType is a pre-parsed column in the SecurityEvent table, the fields ObjectDN, AttributeValue, OpCorrelationID, and AttributeLDAPDisplayName are not pre-parsed. They are packed into the EventData XML field and must be extracted at query time. This is confirmed by the official Microsoft Sentinel Exchange OAB analytics rule (GitHub source), which uses the following extraction pattern:

SecurityEvent
| where EventID == 5136
// Optional: pre-filter on OperationType (a direct column) BEFORE the expensive XML parse
// to reduce compute cost in high-volume environments. Remove to see all operation types.
| where OperationType in ("%%14674", "%%14675")
// The path .EventData.Data navigates the XML structure:
//   .EventData accesses the root <EventData> element
//   .Data accesses the array of <Data Name='...'> child elements
| extend EventDataXml = parse_xml(EventData).EventData.Data
| mv-expand bagexpansion=array EventDataXml
| evaluate bag_unpack(EventDataXml)
| extend Key = tostring(column_ifexists('@Name', "")),
         Value = column_ifexists('#text', "")
| evaluate pivot(Key, any(Value), TimeGenerated, EventID, Computer,
                 Account, AccountType, EventSourceName, Activity,
                 SubjectAccount)
| extend ObjectDN = tostring(column_ifexists("ObjectDN", "")),
         AttributeLDAPDisplayName = tostring(column_ifexists("AttributeLDAPDisplayName", "")),
         AttributeValue = tostring(column_ifexists("AttributeValue", "")),
         OperationTypeExtracted = tostring(column_ifexists("OperationType", "")),
         OpCorrelationID = tostring(column_ifexists("OpCorrelationID", "")),
         ObjectClass = tostring(column_ifexists("ObjectClass", ""))

Note: The parse_xml() + mv-expand + bag_unpack() + evaluate pivot() pattern is computationally expensive. The pre-filter on OperationType (a direct SecurityEvent column, unlike the AD-specific fields) is applied before the XML parse to reduce cost; include it whenever you only need add or delete operations. The official Exchange OAB rule uses this full extraction pattern because it needs to inspect AttributeLDAPDisplayName and AttributeValue to detect webshell indicators.

Simplified extraction for correlation by OpCorrelationID:

If you only need the correlation ID and a few fields, you can use a targeted parse approach instead of the full pivot:

SecurityEvent
| where EventID == 5136
| where OperationType in ("%%14674", "%%14675")  // pre-filter before string parsing
// Raw EventData XML stores fields as: <Data Name="FieldName">value</Data>
// Pattern matches: Name="FieldName">value</Data>
| parse EventData with * 'Name="OpCorrelationID">' OpCorrelationID '</Data>' *
| parse EventData with * 'Name="ObjectDN">' ObjectDN '</Data>' *
| parse EventData with * 'Name="AttributeLDAPDisplayName">' AttributeLDAPDisplayName '</Data>' *
| parse EventData with * 'Name="AttributeValue">' AttributeValue '</Data>' *
| summarize
    OldValue = max(iff(OperationType == "%%14675", AttributeValue, "")),
    NewValue = max(iff(OperationType == "%%14674", AttributeValue, ""))
  by OpCorrelationID, ObjectDN, AttributeLDAPDisplayName

Performance note: parse vs parse_xml: The string-based parse operator is drastically faster than parse_xml() for production detection rules. parse_xml() performs full DOM-based XML parsing, which is CPU-intensive and can cause query timeouts in high-volume environments (the official Microsoft Exchange OAB rule uses it because it needs to inspect multiple attribute values, making it unavoidable there). For any custom detection rule where you only need a handful of fields from EventData, the parse approach is the computationally preferred method. Reserve parse_xml() + pivot() for cases where you genuinely need to extract many unknown or dynamic field names from the XML structure.

The pattern 'Name="FieldName">' matches the XML attribute structure <Data Name="FieldName">value</Data>; use Name="..." as the prefix. For production detection rules requiring many fields, the parse_xml approach remains the reference pattern (as used by official Sentinel rules), but be aware of its cost at scale.

Alerting on a “Value Deleted” event in isolation (without checking whether a corresponding “Value Added” event exists) produces false positives. The deletion is typically one half of a modification, not an actual removal.

What appear to be “duplicate” 5136 events are often modifications to different AD objects that happened at the same time. Always check the ObjectDN field (extracted from EventData) before concluding that events are true duplicates.

7.4 Legacy vs. Advanced Audit Policy Conflicts

As covered in Section 4, the legacy and Advanced Audit Policy systems conflict. But the practical gotcha bears repeating: the conflict is silent. When a legacy audit policy category overrides an advanced subcategory setting, there is no warning in Event Viewer, no alert in Sentinel, and no error in gpresult. The only reliable verification is auditpol.exe /get on the DC itself.

The most dangerous state is a legacy category set to “No Auditing” (which actively disables) rather than “Not Defined” (which defers to the advanced subcategory). These look similar in the Group Policy editor but behave very differently.

8. Microsoft Defender for Identity: Coexistence and Complementarity

Many environments running Microsoft Sentinel also deploy Microsoft Defender for Identity (MDI) on their domain controllers. Understanding where MDI and AMA overlap (and where they don’t) prevents both configuration conflicts and false confidence in detection coverage.

MDI Sensor Architecture

The MDI sensor runs on the domain controller and reads security events directly from the Windows event log on the DC.4 It processes events locally and sends only parsed, abstracted telemetry to the Defender for Identity cloud service. Raw security events are not forwarded to Log Analytics or Sentinel by MDI.

MDI telemetry reaches Sentinel through a separate path: the Microsoft Defender XDR connector, which populates the IdentityDirectoryEvents, IdentityLogonEvents, and IdentityQueryEvents tables.

Why IdentityDirectoryEvents Is Not a Substitute for SecurityEvent

IdentityDirectoryEvents contains directory change information, but differs from SecurityEvent in ways that matter for detection engineering:

  • Latency: IdentityDirectoryEvents has 2-4 hour ingestion latency versus near-real-time for SecurityEvent (community-reported; not an official Microsoft SLA)
  • Abstraction: MDI uses high-level ActionType values rather than raw event fields: actor details, specific attribute values, and operational context may be missing or simplified
  • Coverage: MDI focuses on identity-relevant events; not all security events that appear in the Security log are represented

Sentinel’s OOTB analytics rules for Windows Security events query SecurityEvent, not IdentityDirectoryEvents. Relying solely on MDI telemetry for Sentinel-based detections leaves significant gaps.

MDI Auto-Configuration and GPO Conflicts

MDI includes an auto-configuration feature that can set audit policy subcategories directly on the DC via local LSA policy (not GPO). Key facts:

  • Auto-config is opt-in, not default. It must be explicitly enabled in the Defender XDR portal under Settings > Identities > Advanced Features. As of March 2026, the Microsoft documentation still marks this feature as (Preview); check the current documentation for the latest status, as this feature has been in preview and may or may not have reached GA by the time you read this.
  • Auto-config applies settings to the local audit policy, not the domain group policy.
  • GPO settings take precedence over local policy. If your GPO defines “Audit Directory Service Changes” as “Success and Failure,” the GPO wins regardless of what MDI auto-config sets locally.
  • Auto-config re-applies every 24 hours, which can cause confusion if you are troubleshooting audit policy on a DC and your manual changes are periodically overwritten.

Events MDI Requires That Sentinel “Common” Preset Misses

MDI requires several event IDs that are not included in Sentinel’s Common event set:

Event ID Description In MDI Requirements In Sentinel Common
4741 Computer account created Yes No
4743 Computer account deleted Yes No
4753 Distribution group deleted Yes No
4758 Universal group changed Yes No
4763 Universal group deleted Yes No
7045 New service installed Yes No

If you rely on the Common preset for your DCR and assume it covers MDI’s requirements, these events will not be forwarded to Sentinel. Whether this matters depends on your detection strategy: if MDI handles these detections natively through its own telemetry path, Sentinel does not need them in SecurityEvent. But if you have custom analytics rules targeting these event IDs, you need a custom XPath DCR.

  1. Use GPO as the single authoritative source for audit policy. Configure the GPO to cover the union of both Sentinel and MDI event requirements.
  2. Do not enable MDI auto-config if you already manage audit policy via GPO. Dual management creates confusion with no benefit; GPO always wins, but the auto-config’s 24-hour re-application obscures troubleshooting.
  3. Deploy AMA + Arc for raw event forwarding to the SecurityEvent table. This is Sentinel’s data path.
  4. Enable the Defender XDR connector for IdentityDirectoryEvents as supplemental enrichment, not as a primary detection source.
  5. Both the MDI sensor and AMA coexist on the same DC without conflict. They read events through different mechanisms and send data to different destinations.

9. Verification and Troubleshooting

After deploying audit policy, Arc, AMA, and DCRs, use this phased checklist to confirm the pipeline is working end to end.

Phase 1: Verify Audit Policy on the DC

auditpol /get /subcategory:"Directory Service Changes"
REM Expected: Success and Failure

auditpol /get /subcategory:"User Account Management"
REM Expected: Success and Failure

reg query "HKLM\System\CurrentControlSet\Control\LSA" /v SCENoApplyLegacyAuditPolicy
REM Expected: 0x1

Run on every domain controller. Do not assume GPO replication is consistent.

Phase 2: Verify Events Exist Locally

Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=5136]]" -MaxEvents 5
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4723]]" -MaxEvents 5

If no events appear, the audit policy is not effective on this DC. Return to Phase 1.

Phase 3: Verify Arc and AMA Agent Health

azcmagent show
REM Status should be: Connected

REM Verify AMA process is running
tasklist /FI "IMAGENAME eq MonAgentCore.exe"

Phase 4: Verify DCR Association

Check that the DCR is associated with this specific DC’s Arc resource:

  • In the Azure portal, navigate to the DCR and check the Resources tab, where the DC should be listed
  • On the DC itself, verify the DCR configuration file exists: C:\Resources\Directory\AMADataStore\mcs\mcsconfig.latest.xml

Phase 5: Verify DCR XPath Coverage

Confirm that the DCR’s XPath expression (or event set preset) includes the target event IDs. If using Custom XPath, test the same expression locally with Get-WinEvent as shown in Phase 2. Remember that Get-WinEvent supports up to 23 XPath expressions while DCRs only support 20; if your filter has 21-23 expressions, it will pass the local test but fail in the DCR.

Phase 6: Verify Data in Sentinel

// Confirm target events flowing from specific DCs
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID in (5136, 4723, 4724)
| summarize Count = count(), LastSeen = max(TimeGenerated) by Computer, EventID
| sort by Computer asc, EventID asc

// AMA heartbeat health across all DCs
Heartbeat
| where Category == "Azure Monitor Agent"
| where TimeGenerated > ago(1h)
| summarize LastHeartbeat = max(TimeGenerated), HeartbeatCount = count() by Computer
| extend MinutesSinceHeartbeat = datetime_diff('minute', now(), LastHeartbeat)
| sort by MinutesSinceHeartbeat desc

// Sentinel connector health
SentinelHealth
| where TimeGenerated > ago(7d)
| where OperationName == "Data fetch status change"
| where SentinelResourceName has "SecurityEvents"
| summarize arg_max(TimeGenerated, *) by SentinelResourceName

If your domain controllers communicate with Azure through Azure Private Link (Azure Monitor Private Link Scope / AMPLS), AMA requires a Data Collection Endpoint (DCE) to route traffic through the private network instead of the public endpoint.

Key considerations:

  • A DCE is required for any AMA agent on a network that uses DNS private link zones. Without it, AMA will attempt to use the public endpoint, which may be blocked by your firewall or DNS configuration.
  • Create a DCE in the same region as the domain controller. AMA can only connect to a DCE in its own region.
  • Associate the DCE with the DCR. In the DCR’s configuration, specify the DCE as the endpoint. This can be done via the Azure portal (DCR > Configuration > Data Collection Endpoint) or via ARM/Bicep.
  • Add the DCE to your AMPLS resource. This registers the DCE in your private DNS zone and enables communication over the private link.
  • DNS resolution is critical. Verify that the DC can resolve the DCE’s hostname to a private IP address, not a public one. Use nslookup <dce-hostname>.ingest.monitor.azure.com to confirm.

If AMA heartbeats appear but no SecurityEvent data flows, and your environment uses Private Link, a missing or misconfigured DCE is a common cause.

Common Failure Points

Symptom Likely Cause Resolution
No 5136 events on DC locally Audit policy not applied or overridden by legacy policy Verify auditpol, check SCENoApplyLegacyAuditPolicy, check legacy categories are “Not Defined”
Events on DC but not in Sentinel AMA not running, DCR not associated, or XPath excludes the event Check MonAgentCore.exe, DCR Resources tab, XPath configuration
Events from some DCs but not all DCR not associated with all DC Arc resources Check DCR Resources tab for missing DCs; check PDC Emulator specifically
5136 events absent but 4723/4724 present Using Minimal preset (5136 not in Minimal) Switch to Common or add 5136 via custom XPath
Heartbeat shows AMA but no SecurityEvent data DCR uses wrong stream or wrong connector type Verify DCR uses Microsoft-SecurityEvent stream, not generic Event table
Heartbeat but no data in Private Link environment Missing or misconfigured Data Collection Endpoint (DCE) Create DCE in same region, associate with DCR, add to AMPLS, verify DNS
Duplicate events in SecurityEvent Multiple overlapping DCRs or MMA+AMA running simultaneously Remove duplicate DCR associations; uninstall MMA

10. Sentinel Analytics Rules Dependent on These Events

The configuration decisions above directly determine whether these Sentinel detection rules function. The Min. DCR Preset column identifies the lowest preset that delivers the required event IDs — rules requiring Common or Custom XPath are silently blind on domain controllers configured with only the Minimal preset.

Analytics Rule Source Required Event IDs Severity Min. DCR Preset Impact If Events Missing
Exchange OAB Virtual Directory Attribute Containing Potential Webshell OOTB 5136 High Common Blind to Exchange server webshell exploitation via OAB modification (CVE-2021-27065); all 5136 fields require parse_xml() extraction — not pre-parsed columns
AdminSDHolder Modifications OOTB 5136 High Common No visibility into AdminSDHolder backdoor persistence — SDProp-based privilege propagation goes undetected
GPO Link/Unlink Tracking Custom 5136 High Common No visibility into GPO tampering for persistence or defense evasion
Non Domain Controller Active Directory Replication OOTB 4662, 4624 High Common Misses DCSync-style attacks — non-DC accounts using directory replication to retrieve credentials (T1003.006)
Service Principal Name (SPN) Assigned to User Account OOTB 5136 Medium Common Misses Kerberoasting preparation — SPN assignment to a user account enables offline hash cracking
Possible Resource-Based Constrained Delegation Abuse OOTB 5136 Medium Common Blind to RBCD privilege escalation via msDS-AllowedToActOnBehalfOfOtherIdentity attribute modification
Certified Pre-Owned — TGTs Requested with Certificate Authentication Community (FalconFriday) 4768 Medium Common Blind to machine certificate misuse for Kerberos TGT requests — AD CS abuse patterns go undetected
AD Object Attribute Modification Custom 5136 Variable Common Total loss of directory change visibility
User Account Enabled and Disabled Within 10 Minutes OOTB 4722, 4725 Medium Minimal Misses account enable/disable cycling used to conceal adversary activity
AD User Enabled and Password Not Set Within 48 Hours OOTB 4722, 4723 Low Minimal Misses enabled accounts without password protection (persistence technique)
Multiple Password Reset by user OOTB 4723, 4724 Low Minimal Misses bulk credential abuse patterns across multiple users and data sources
Credential Dumping Tools — Service Installation OOTB 7045 High Custom XPath Blind to Mimikatz and similar credential dumper service installations; 7045 is absent from both Minimal and Common presets

Rules marked OOTB are sourced directly from the Azure Sentinel GitHub repository (Solutions/Windows Security Events, Detections/SecurityEvent, or partner solutions). Community (FalconFriday) rules are in the Solutions/FalconFriday directory. Custom rules have no direct repository equivalent and must be written or adapted locally.

The Exchange OAB rule deserves specific mention: it detects a high-severity, actively exploited attack technique (T1505.003 - Server Software Component: Web Shell) and depends entirely on event 5136 being collected from the domain controller that hosts the Exchange server’s AD objects. As noted in Section 7.3, this rule uses the full parse_xml() + pivot() + column_ifexists() pattern to extract fields from EventData; it does NOT reference ObjectDN or AttributeValue as direct SecurityEvent columns. All other 5136-dependent rules in this table share this same extraction constraint.

Event 7045 (a new service was installed in the Service Control Manager) is absent from both Minimal and Common presets — the same coverage gap identified in the MDI events comparison. Capturing it requires an explicit Custom XPath expression: Security!*[System[EventID=7045]].

Anti-Patterns Consolidated

Anti-Pattern Why It Fails Correct Approach
Running MMA and AMA simultaneously long-term Duplicate events, double billing Migrate in days, not weeks; disable MMA collection before uninstall
Deploying Arc on DCs without agent hardening Extension manager runs as SYSTEM; cloud admin becomes Domain Admin Run all three azcmagent config set commands immediately after onboarding
Placing DC Arc resources in a shared subscription Subscription admins gain implicit Tier-0 access Use a dedicated, RBAC-restricted subscription
Using extension blocklist instead of allowlist Cannot anticipate future extension types Use extensions.allowlist with only required extensions
Applying audit policy GPO at domain root Applies to all machines, not just DCs; unintended scope Link to Domain Controllers OU only
Modifying Default Domain Controllers Policy Risk of breaking inherited settings; poor change control Create a dedicated GPO for audit policy
Mixing legacy and Advanced Audit Policy Legacy categories silently override advanced subcategories Set all 9 legacy categories to “Not Defined”; enable force override
Setting legacy categories to “No Auditing” Actively disables; different from “Not Defined” Use “Not Defined” to defer to advanced subcategory settings
Using rsop.msc to verify Advanced Audit Policy Does not display subcategory settings Use auditpol.exe /get on each DC
Not enabling “Force subcategory settings” override Legacy policy wins even when advanced is configured Enable the override GPO setting; verify SCENoApplyLegacyAuditPolicy = 1
Selecting “Minimal” event set for DC monitoring Drops 5136, 4662, 4768, and other critical events Use Common or Custom XPath
Selecting “All Events” on busy DCs Massive ingestion volume and cost Use Common or targeted Custom XPath
Multiple overlapping DCRs on same machine Duplicate events, double billing One security events DCR per DC
Using generic Azure Monitor DCR instead of Sentinel connector Data routes to Event table, not SecurityEvent Use “Windows Security Events via AMA” connector specifically
Deploying custom XPath without local testing Silent failure if syntax is wrong Test with Get-WinEvent -FilterXPath first (but respect the 20-expression DCR limit vs. Get-WinEvent’s 23)
Using WEC forwarding for domain controllers Events go to WindowsEvent table; OOTB rules query SecurityEvent Install AMA directly on each DC
Assuming WEC + Content Hub rules work together Only 2 OOTB rules target WindowsEvent (as of last review; may change with Content Hub updates) Use direct AMA for SecurityEvent table
Filtering on OperationType == "Value Added" Raw codes (%%14674) stored, not friendly text Use %%14674 / %%14675 in KQL filters
Deploying AMA on all DCs except PDC Emulator GPMC-initiated 5136/5137/5141 events go to PDC Emulator; other writes go to whichever DC processes them Deploy AMA on all writable DCs; prioritise PDC Emulator for GPO change visibility specifically
Alerting on 5136 “Value Deleted” without checking for paired “Value Added” Most deletions are one half of a modification Correlate via OpCorrelationID (extracted from EventData XML)
Treating duplicate-looking 5136 events as noise Different ObjectDN GUIDs = different objects Check ObjectDN (extracted from EventData) before deduplicating
Referencing ObjectDN, AttributeValue, or OpCorrelationID as direct SecurityEvent columns These are NOT pre-parsed columns; they are packed in EventData XML Use parse_xml(EventData) + mv-expand + bag_unpack() + pivot() pattern, or targeted parse extraction
Testing XPath with Get-WinEvent using 21-23 expressions Get-WinEvent supports 23, but DCRs only support 20 expressions Keep XPath expressions within the 20-expression DCR limit
Relying solely on MDI IdentityDirectoryEvents for Sentinel detections 2-4 hour latency (community-reported; not an official SLA), missing fields, abstracted ActionTypes Use SecurityEvent as primary; IdentityDirectoryEvents as supplemental
Using Sentinel Common preset assuming it covers all MDI requirements 4741, 4743, 4753, 4758, 4763, 7045 are missing Use custom XPath if Sentinel needs these events
Enabling MDI auto-config alongside GPO-based audit policy Dual management confusion; GPO always wins anyway Use GPO as single source; disable MDI auto-config
Not using tostring() on dynamic field extractions Type errors in KQL at query time Always wrap extracted fields with tostring()
Using event count instead of _BilledSize for cost analysis Event sizes vary dramatically; count misleads Use sum(_BilledSize) for accurate cost measurement

Authoritative Sources

Tier 1: Microsoft Official Documentation

  1. AMA Migration Guide - Microsoft Learn: Plan migration to Azure Monitor Agent from Log Analytics agent
    • Authority: Official Microsoft migration documentation
    • Key Contribution: MMA retirement timeline, AMA feature parity, migration procedures
  2. Windows Security Events via AMA Connector - Microsoft Learn: Stream Windows security events via AMA to Sentinel
    • Authority: Official Sentinel connector documentation
    • Key Contribution: Event set definitions (Minimal/Common/All), DCR configuration, XPath syntax
  3. Azure Arc Connected Machine Agent - Microsoft Learn: Azure Connected Machine agent prerequisites
    • Authority: Official Arc documentation
    • Key Contribution: Network requirements, service account prerequisites, onboarding procedures
  4. Advanced Audit Policy Configuration - Microsoft Learn: Advanced security audit policy settings
    • Authority: Official Windows security documentation
    • Key Contribution: Subcategory definitions, event-to-policy mapping, GPO configuration paths
  5. Microsoft Sentinel SecurityEvent Table Schema - Azure Monitor Logs reference - SecurityEvent
    • Authority: Official Log Analytics schema reference
    • Key Contribution: Complete column listing confirming which fields are pre-parsed vs. packed in EventData
  6. Microsoft Defender for Identity Audit Policy Requirements - Configure Windows event auditing
    • Authority: Official MDI documentation
    • Key Contribution: Required event IDs, auto-configuration behavior (Preview status confirmed), sensor architecture
  7. Azure Arc Security Guidance for Domain Controllers - Microsoft Tech Community / Microsoft Learn
    • Authority: Microsoft security team guidance
    • Key Contribution: Tier-0 risk assessment, hardening commands, subscription isolation recommendations
  8. Data Collection Endpoints Overview - Data collection endpoints in Azure Monitor
    • Authority: Official Azure Monitor documentation
    • Key Contribution: DCE requirements for Private Link environments, regional constraints
  9. AMA Private Link Configuration - Network Isolation for Azure Monitor Agent via Private Link
    • Authority: Official Azure Monitor networking documentation
    • Key Contribution: Private Link setup for AMA, DCE association requirements

Tier 2: Microsoft GitHub & Partner Sources

  1. Azure Sentinel GitHub Repository - github.com/Azure/Azure-Sentinel
    • Authority: Official Sentinel community content, maintained by Microsoft
    • Key Contribution: Analytics rule definitions (Exchange OAB rule confirms parse_xml extraction pattern for 5136), ASIM parser status, Content Hub solution details
  2. Exchange OAB VirtualDirectory Attribute Modification Rule - GitHub YAML source
    • Authority: Official Microsoft Sentinel analytics rule
    • Key Contribution: Definitive proof that 5136 event fields (ObjectDN, AttributeValue, etc.) require parse_xml extraction, not direct column access
  3. Windows Security Event ID Reference - Microsoft Learn: Windows security audit events
    • Authority: Official event ID catalog
    • Key Contribution: Event-to-subcategory mapping, event field definitions
  4. Sentinel ASIM Documentation - Microsoft Learn: Advanced Security Information Model
    • Authority: Official normalization framework documentation
    • Key Contribution: Cross-table normalization status, parser availability for SecurityEvent and WindowsEvent
  5. Collect Windows Events with AMA - Microsoft Learn: Data collection for Windows events
    • Authority: Official Azure Monitor documentation
    • Key Contribution: XPath expression limits (20 per DCR condition box), DCR configuration details

Tier 3: Community & Industry

  1. Artic6 Blog: Sentinel - Tracking Group Policy Changes - a6n.co.uk
    • Authority: Practitioner field guide (February 2026)
    • Key Contribution: Confirms EventData XML extraction requirement for 5136 in real-world Sentinel deployment
  2. Parsing EventData from SecurityEvents - Microsoft Tech Community
    • Authority: Community thread with Microsoft participation
    • Key Contribution: Confirms parse_xml() as recommended approach for EventData extraction
  3. EventData is not always parsed (GitHub Issue #1110) - Azure-Sentinel GitHub
    • Authority: Official Sentinel GitHub issue tracker
    • Key Contribution: Documents that certain event fields are inconsistently pre-parsed; confirms need for manual XML extraction
  4. Palantir Windows Event Forwarding Guidance - github.com/palantir/windows-event-forwarding
    • Authority: Widely referenced enterprise WEF implementation guide
    • Key Contribution: WEC architecture patterns, scale considerations, event filtering strategies
  5. Community KQL Repositories & Microsoft Tech Community Forums
    • Authority: Practitioner experience and field-validated patterns
    • Key Contribution: Real-world XPath configurations, cost optimization queries, troubleshooting patterns

Notes

  1. Event set sizes are based on counting the distinct event IDs listed in the official Windows security event sets reference. Minimal contains approximately 38 distinct event IDs; Common contains approximately 130. These are counts of distinct event IDs collected, not event volume or instance counts generated on a busy DC. ↩ ↩2

  2. The limit of 100 condition boxes per DCR was not confirmed against Tier 1 Microsoft documentation at time of writing. The 20-expression limit per condition box is confirmed in Collect Windows events with AMA. Verify the condition box limit against current Azure Monitor service limits before relying on this figure. ↩

  3. imAuditEvent is a KQL unifying parser function (invoked as imAuditEvent()) — it is not a table name. Built-in source-specific parsers follow the _Im_AuditEvent_<Source>Vxx naming convention. See the ASIM Audit Events normalization schema and the full ASIM parsers list for current parser availability and GA status. ↩

  4. The official MDI event collection overview states: “For Windows events, Defender for Identity detection relies on specific event logs. The sensor parses these event logs from your domain controllers.” Sources: Microsoft Defender for Identity event collection overview and Defender for Identity architecture. The MDI auto-configuration feature (Section 8.3) uses LSA policy APIs to configure audit policy subcategory settings on the DC — this is a separate function from event collection. The sensor’s event reading relies on the Windows event log directly. ↩