Active Directory Audit Policy Configuration Gaps: The Categories Nobody Enables Before They Need the Logs

What Are Active Directory Audit Policy Configuration Gaps

Most Active Directory teams assume that if the Security event log is filling up, the environment is "being audited." It isn't — not in the way that matters for detecting an attack. Active Directory audit policy configuration gaps are the subcategories that Windows ships off, half-configured, or silently overridden, so the events an investigator would need later were never generated in the first place. Windows organizes what gets logged into an Advanced Audit Policy Configuration made of 10 categories subdivided into dozens of subcategories — expanded from the original 9 basic categories to 53 granular subcategories starting with Windows Vista and Windows Server 2008 (the count has grown further since, as later Windows releases added subcategories such as Group Membership and PNP Activity), as described in Microsoft's own history of the Windows Server advanced auditing policies. Each subcategory is an independent on/off switch. Leave one off, and every event it would have generated simply never exists — there's no log to review later, no gap to notice in an incident review, nothing.

In practice, four blind spots show up over and over in AD environments that have never had their audit policy deliberately reviewed, and that map directly to what our Active Directory security audit checks look for:

• Account Management left at Windows defaults instead of fully enabled (success and failure), so user, computer, and group changes go partially or fully unlogged.
• Account Logon (the category that actually covers Kerberos authentication on domain controllers) disabled outright — this one is off by default even on servers.
• Policy Change not covering the subcategories that matter beyond the one Windows already logs for you.
• No honeypot or decoy accounts anywhere in the directory, so there's no near-zero-false-positive tripwire for enumeration or credential abuse.

Each is small on its own. Together they mean the categories that would catch privilege creation, credential abuse, and an attacker covering their tracks are the ones least likely to be logging anything. These gaps sit alongside the other hardening priorities covered in Hardening Active Directory: What to Lock Down First — audit policy rarely gets the same attention as ACLs or Tier 0 isolation, precisely because a missing log doesn't announce itself. Unlike a dangerous ACL or an over-permissioned group, a disabled audit subcategory produces no artifact to stumble across during a routine review — the only way to find it is to go and check the effective policy directly, on the domain controller, rather than assume the GPO editor tells the full story.

How Windows Audit Policy Actually Works — And Where It Silently Fails

Microsoft publishes a baseline recommendation table for exactly this reason: the Windows Server default policy leaves several identity-relevant subcategories off, and only a subset of Account Management subcategories log failures out of the box. Two defaults stand out for AD specifically:

• Audit Credential Validation (the subcategory under Account Logon that governs NTLM and Kerberos password validation) ships as No | No — completely disabled — on both Windows Client and Windows Server. Microsoft's own baseline recommendation raises it to Yes | Yes on servers (the domain controllers this article is about) and to Yes | No on clients, and the other three Account Logon subcategories (Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events) carry no default at all.
• Audit Policy Change (under Policy Change) defaults to Yes | No — success only. Microsoft's baseline recommends Yes | Yes.

That second one matters because of a detail Microsoft documents directly on the event itself: Event ID 4719 ("System audit policy was changed") "is always logged regardless of the 'Audit Policy Change' sub-category setting." That's reassuring for the one event admins usually know about — but Authentication Policy Change and Authorization Policy Change are separate, independently-switched subcategories within the same Policy Change category, and neither gets that same free pass. If those aren't explicitly enabled, an attacker who quietly loosens Kerberos delegation settings or a privilege assignment leaves nothing behind.

The Legacy-vs-Advanced Override Trap

There's a second, more operational trap, and it's the same category of problem as the GPO misconfigurations that turn Group Policy into an attack vector: even when a GPO correctly enables an advanced subcategory, that setting can be silently overridden by the legacy 9-category Local Security Policy unless the domain also enables "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" — the SCENoApplyLegacyAuditPolicy registry value under HKLM\SYSTEM\CurrentControlSet\Control\Lsa, per Microsoft's documentation for that policy. Skip it, and the GPMC can show every subcategory configured correctly while the domain controller quietly keeps applying the old category-level policy instead.

This piece is deliberately about whether these categories are even switched on. What to do once they are — which specific event IDs to alert on and how to build the detection logic — is covered in Active Directory Monitoring: Security Event IDs That Matter.

Detection: Verify What's Actually Enabled, Not What GPO Claims

Checking the Effective Policy with auditpol

Don't trust the Group Policy Management Console alone. Run auditpol directly on a domain controller to see the effective policy:

# Full effective audit policy on this DC
auditpol /get /category:*

# Just the categories this article covers
auditpol /get /category:"Account Logon"
auditpol /get /category:"Account Management"
auditpol /get /category:"Policy Change"

# Confirm the legacy-override GPO setting actually took
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name SCENoApplyLegacyAuditPolicy -ErrorAction SilentlyContinue

If any subcategory reads "No Auditing," the events in the table below are not being generated on that box — full stop, nothing to hunt for later:

Why a Honeypot Account Closes the Loop

A honey user is a decoy AD account with no real privilege, placed so that enumeration tools (BloodHound, password sprayers, Kerberoasting scripts) find it and try it like any other target. Because a legitimate user or service never touches it, any 4768/4769/4624 against that account is close to a 100%-confidence signal — the opposite of the noisy alert-fatigue problem the other three categories can create once they're switched on. Effective decoys need realistic metadata and placement, not an obvious name like honeypot-admin-01, per the deception-technology guidance in this space. The same principle underpins detecting ACL abuse and DCSync paths: a replication request from an account that has no business replicating is exactly the kind of low-noise, high-confidence signal these audit categories exist to surface.

Also worth checking: attackers who succeed in disabling logging outright are executing MITRE ATT&CK T1562.002 — Impair Defenses: Disable Windows Event Logging, a defense-evasion technique that specifically targets the audit policy this article covers. An environment that never enabled these categories in the first place gives that technique a free win it wouldn't otherwise have.

Remediation: Closing the Four Gaps

Fix Account Logon and Account Management First

1. Enable Account Logon in full, success and failure, via Default Domain Controllers Policy → Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Account Logon: Credential Validation, Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events.
2. Bring Account Management up to Microsoft's baseline (success and failure) for User Account Management, Security Group Management, Computer Account Management, and Other Account Management Events — not just the success-only default.

Complete Policy Change and Lock In the GPO Override

3. Complete Policy Change: enable Authentication Policy Change and Authorization Policy Change alongside the already-partial Audit Policy Change subcategory, so Kerberos policy and privilege-assignment tampering actually generates events.
4. Set the legacy-override GPO ("Audit: Force audit policy subcategory settings...") domain-wide, then re-run the auditpol /get check above on a DC after a gpupdate /force — verify the effective policy, don't just trust the GPO editor.

Deploy a Decoy Account and Alert on 4719

5. Deploy at least one honeypot account per domain, with realistic attributes and group placement, and alert on any authentication event against it.
6. Forward all of the above to a SIEM and alert on Event ID 4719 unconditionally — Microsoft's own guidance is to treat any unplanned audit policy change as a high-priority investigation trigger, since attackers disable auditing specifically to operate without evidence.

Treat this as a recurring check, not a one-time project: a domain controller rebuild, a new GPO that resets the legacy-override setting, or a migration to a fresh forest can quietly re-introduce any of these four gaps, and none of them will show up as an alert — they'll just show up as an absence, months later, in an incident where the logs you needed were never written. Folding this check into a recurring AD audit workflow is the only reliable way to catch the drift before it matters.

How EtcSec Detects This

EtcSec checks Active Directory Group Policy objects during every audit for exactly these gaps: AUDIT_POLICY_WEAK flags subcategories left below Microsoft's baseline, DC_AUDIT_POLICY_INCOMPLETE flags domain controllers where the effective policy doesn't match what the GPO claims, ANSSI_R38_ADVANCED_AUDIT_NOT_ENABLED checks compliance with ANSSI recommendation R38 for advanced audit policy coverage, and NO_HONEYPOT_ACCOUNTS flags directories with zero decoy accounts anywhere in scope.