(Article copied from https://blogs.msdn.microsoft.com/spatdsg/2011/06/06/audit-policy-not-registering-audits/)
So there was an interesting case which floated my way the other day.
The Audit policies in the domain controllers policy was set to the following, and there were no other policies blocking or changing these.
After a policy update the following events were logged:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 5/23/2011 7:58:56 PM
Event ID: 4719
Task Category: Audit Policy Change
Level: Information
Keywords: Audit Success
User: N/A
Computer: foo.domain.com
Description: System audit policy was changed.
Subject:
Security ID: SYSTEM
Account Name: DomainControllerName$
Account Domain: DomainName
Logon ID: 0x3e7
Audit Policy Change:
Category: DS Access
Subcategory: Directory Service Changes
Subcategory GUID: {0cce923c-69ae-11d9-bed3-505054503030}
Changes: Success removed
In addition, auditpol /get /category:* simply would show no auditing after policy update:
So, where was this crazy thing being overwritten? It wasn’t in the policies, since we checked all of them carefully for inheritance etc..
Looking at where a client actually stores audit policy may give us a clue C:\Windows\system32\grouppolicy\machine\microsoft\windows nt\audit\audit.csv and C:\Windows\security
But there was nothing there of interest. So, the last place to look was the sysvol data:
M:\SYSVOL\domain\Policies\{CEF3323C-FD89-4C03-9410-18F7A4922E5A}\Machine\microsoft\windows nt\Audit
Aha! Under here was the .CSV file with the headings - but no configuration data in it!
We removed this file and now audit policies flowed properly to the DCs and audit event were generated.
Odd. It turns out that they had applied the policies via a GPOBackup and perhaps something had occurred prior to the backup.
Anyway – hope it helps someone someday