Short version:

How do I apply subcategory audit policy settings programmatically or via command-line tools (i.e. auditpol.exe) that don't get overwritten by local security policy?

Long version:

I have a stand-alone Windows Server 2008 R2.  When I use auditpol.exe or the AuditSetSystemPolicy API to set subcategory audit settings these changes take effect immediately.  However on a reboot the settings are reset.  I can see security event log entries indicating when I change the policy as well as the system resetting the policy on the restart.

I have seen a few articles indicating that Local Security Policy is not aware of these settings through its secedit.sdb database.  That explains why the Local Security Policy snap-in does not accurately reflect the current resultant policy (RSoP).  I did not expect Local Policy to overwrite these values on startup (and apparently every ~16 hours?).

In this blog post: Getting the Effective Audit Policy in Windows 7 and 2008 R2 (http://blogs.technet.com/b/askds/archive/2011/03/11/getting-the-effective-audit-policy-in-windows-7-and-2008-r2.aspx) the author mentions Local Policy stomping on auditpol.exe settings in the context of RSoP.

Any help or insight into the behavior of Local Security Policy is greatly appreciated.

Thanks,

Don

Don-

Have you tried setting this policy on the local GPO: 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?

In a domain-based environment this setting is required to tell Windows to ignore the "legacy" category-based audit settings and instead respect the "Advanced Audit Policy" settings that use subcategories.

Darren

Turns out the Local Security Policy thought it needed to apply audit policy settings even though every Advanced Audit Policy Configuration item was marked "Not Configured."  On reboot or when forcing local policy application with "GPUPDATE.EXE /force" all advanced audit policy was being wiped out.  this was confirmed by looking at the output from "GPRESULT.EXE /H ResultsBefore.htm."  This showed audit policy was being applied.

Big thanks to Ned Pyle, author of Getting the Effective Audit Policy in Windows 7 and 2008 R2, for offering up the fix.

I needed to remove the files that Local Security Policy used to track audit policy.  Removing c:\Windows\security\audit\audit.csv, c:\Windows\System32\GroupPolicy\Machine\Microsoft\WindowsNT\Audit\audit.csv and c:\Windows\System32\GroupPolicy\gpt.ini then rebooting put Local Security Policy back into a state where it didn't think it needed to apply advanced audit policy.  Any changes using AUDITPOL.EXE or AuditSetSystemPolicy(...) then survived local policy application.  "GPRESULT /H ResultsAfter.htm" also confirmed that audit policy was not being  applied.

A couple of caveats regarding advanced audit policy...per Ned's blog post above, you CANNOT rely on the Local Security Policy MMC console to accurately reflect the active policy settings...use AUDITPOL.EXE.  Also once you set ANY advanced audit policy setting in Local Security Policy it will overwrite all advanced settings when the policy is applied.  AFAIK there is no way short of manually deleting the above files to tell Local Security Policy to forget advanced audit settings.

--Don

Hi,

Thanks for the workaround to get this working? we dont want to use this workaround as this may affect other functionality. 

is there any hotfix/patch which solves this problem.

Thanks,

Geeta