AD auditing and detection: audit policy and event IDs

Hardening configuration reduces the attack surface, but it does not make Active Directory attacks impossible — it makes them harder and noisier. Noisier is only useful if someone, or something, is listening. Most AD compromises that make it to domain dominance succeed not because detection was technically impossible, but because the audit policy, SACLs, and log pipeline needed to see them were never turned on. This post covers the concrete Advanced Audit Policy configuration, the event IDs that matter, SACLs on sensitive objects, and the collection pipeline (WEF, Defender for Identity, honeytokens) to get from "we have logs" to "we would notice."

Configure Advanced Audit Policy via GPO

Legacy audit policy (the nine basic categories) is too coarse. Use Advanced Audit Policy Configuration, applied through a GPO linked to the Domain Controllers OU:

Group Policy path: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies

Enable these subcategories (Success and Failure unless noted):

Apply and verify:

# Apply the GPO, then confirm effective settings on a DC
auditpol /get /category:*

# Check a specific subcategory
auditpol /get /subcategory:"Directory Service Access"
auditpol /get /subcategory:"Kerberos Service Ticket Operations"

If auditpol shows "No Auditing" after a GPO refresh, confirm Local Group Policy Object Editor's Local Policies audit settings are not overriding Advanced Audit Policy — mixing legacy and advanced audit policy on the same machine causes exactly this. Set Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings to Enabled.

Event IDs that matter most

DCSync detection deserves emphasis: it does not appear as a distinct "DCSync" event. It appears as event 4662 with the two replication GUIDs above, issued by a security principal that is not a domain controller computer account or a designated replication service account. Any other principal invoking those extended rights is a strong indicator of credential theft being used to impersonate a domain controller.

SACLs on sensitive objects

Event 4662 and 5136 only fire where a System Access Control List (SACL) is configured on the object. Apply SACLs, not just audit policy, to:

• The domain object itself (DC=domain,DC=com) — required for DCSync detection, since replication rights are evaluated at the domain root.
• AdminSDHolder (CN=AdminSDHolder,CN=System,DC=domain,DC=com).
• Privileged groups: Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators.
• The krbtgt account.
• GPOs linked to the Domain Controllers OU and any Tier 0 OUs.

Configure via Advanced Security Settings > Auditing on the object, or with PowerShell:

$path = "AD:\DC=domain,DC=com"
$acl = Get-Acl $path
$sacl = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    [System.Security.Principal.SecurityIdentifier]"S-1-1-0",   # Everyone — filter later in your SIEM
    "WriteProperty,ExtendedRight",
    "Success",
    [guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"                # DS-Replication-Get-Changes
)
$acl.AddAuditRule($sacl)
Set-Acl -Path $path -AclObject $acl

Verify SACLs are present:

(Get-Acl "AD:\DC=domain,DC=com").Audit | Format-Table IdentityReference, ActiveDirectoryRights, AuditFlags

Windows Event Forwarding to a collector

Domain controller local event logs are not durable evidence — an attacker with DA can clear them, and a single DC's logs give an incomplete picture. Forward to a central collector:

1. On the collector: wecutil qc to configure the Windows Event Collector service.
2. Author a subscription (source-initiated is simplest at scale) targeting the audit subcategories above; deliver via GPO-pushed SubscriptionManager registry value pointing DCs at the collector.
3. On DCs, ensure the Windows Remote Management (WS-Management) service is running and the Network Service account (used by the forwarding service) can read the Security log: add NT AUTHORITY\NETWORK SERVICE to the built-in Event Log Readers group (domain-wide on DCs), or extend the Security channel's access SDDL via Group Policy.
4. Verify delivery:

Get-WinEvent -LogName "ForwardedEvents" -MaxEvents 20 -ComputerName <collector>
wecutil gr <SubscriptionName>

Retain forwarded logs somewhere the domain admins of the audited domain cannot delete from — a separate log-management or SIEM tier, ideally in a different trust/administrative boundary than the DCs being monitored.

Microsoft Defender for Identity and honeytokens

Microsoft Defender for Identity deploys sensors on DCs and AD FS servers and correlates network and event telemetry to detect reconnaissance, golden ticket use, DCSync, and lateral movement patterns without you hand-building every detection rule. It is a strong complement to — not a replacement for — the audit policy and SACLs above, because Defender for Identity itself consumes local ETW/audit telemetry from the DC.

Honeytoken accounts: create decoy accounts that have no legitimate business use — ideally with an enticing name or SPN, no logon activity ever, and a plausible-looking (but unused) password — and alert on any authentication attempt against them. Defender for Identity supports flagging accounts as honeytokens natively; without it, alert directly on 4768/4769/4624 events where the target principal is the honeytoken account. A single hit is a high-confidence signal, since no legitimate process should ever touch it.

What this breaks

Nothing functional — auditing is passive. The real cost is log volume: enabling Directory Service Access auditing (4662) broadly, rather than scoping SACLs to genuinely sensitive objects, can generate enormous event volume on busy DCs and overwhelm both local log retention and your WEF collector. Plan collector storage and SIEM ingestion capacity based on a pilot against a subset of DCs before rolling audit policy out forest-wide, and prefer targeted SACLs over "audit everything."

Once detection is in place, pair it with Domain controller hardening to reduce what attackers can do before you see them, and with Object & ACL security to shrink the set of objects whose compromise matters enough to need a SACL in the first place.