Windows Explored

So, recently I had the need to setup auditing on a local workstation to try and determine who or what was deleting a specific set of files. Before we started, we decided to test the auditing on a couple PCs to audit all failed and successful attempts to delete any files or folders within some random test folder. Audit events are recorded in the Security logs of the Windows Event Viewer. Specifically, Audit Object Access events of interest are event ID 4656 (A handle to an object was requested) and 4663 (An attempt was made to access an object). The details should allude to the responsible user account and process. But to our surprise our test folder was not recording any audit events for any of the objects inside.

Maybe an oversight but perhaps auditing was not enabled in group policy. But a quick check revealed that it was being set for both success and failure:

Maybe it wasn’t getting applied to the workstation. Although deprecated since Vista, RSOP from the command line is useful for quickly spotting polices that might not be getting applied to the local computer. Sure enough I could see there was a problem with the audit policies: “The policy engine did not attempt to configure the setting…”

Another hint that GPO Audit policies were not being applied could be seen in the local policy editor (gpedit.msc):

After some research the next morning I stumbled across the following Microsoft KB article Security auditing settings are not applied to Windows Vista-based and Window Server 2008-based computers when you deploy a domain-based policy. In short:

Windows Vista and later versions of Windows enable you to manage audit policies in a more precise manner by using audit policy subcategories. If you configure audit policies at the category level, you override audit policy subcategories.

If you want to manage audit policies by using audit policy subcategories, and you do not want to use Group Policy, you can configure the SCENoApplyLegacyAuditPolicy registry entry. When you configure the SCENoApplyLegacyAuditPolicy registry entry, you prevent category-level audit policies that were configured by using either Group Policy or the Local Security Policy tool from being applied.

I Navigated to Computer Configuration > Policies > Windows Settings > Security Settings > Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings and saw it was checked. If this option is checked, legacy Audit policies (pre-vista) will not be applied and must be set under Advanced Audit Policy Configuration (see this KB for details if you go that route Understanding File and Handle Audit Events in Windows Vista, in Windows Server 2008, in Windows 7, Windows Server 2008 R2, in Windows 8, and in Windows Server 2012. Sure this was all that needed to be done, I set this to disabled and waited. Unfortunately, the legacy audit polices were still not working.

After some more research, I discovered that its simply not enough to change Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings from enabled to disabled. This has no effect on the actual audit.csv configuration file stored in the sysvol policy itself. As you can see, it still contained all the Advanced audit policy settings and file object is missing:

Several more clicks later, I eventually stumbled upon the missing clue to correcting this in this Technet article Advanced Security Audit Policy Step-by-Step Guide. When reverting back to basic (legacy) audit policies, you need to perform some additional steps.

Applying advanced audit policy settings replaces any comparable basic security audit policy settings. If you subsequently change the advanced audit policy setting to Not configured, you will need to complete the following steps to restore the original basic security audit policy settings:

1. Set all Advanced Audit Policy sub-categories to Not configured.
2. Delete all audit.csv files from the %SYSVOL% folder on the domain controller.
3. Reconfigure and apply the basic audit policy settings.

Unless you complete all of these steps, the basic audit policy settings will not be restored.

By the way, after this discovery we decided to stick with Advanced Auditing now that we understood that legacy auditing should be ditched because, well, its legacy.

And, if you haven’t already grown tired of all the links in this blog article, here’s another useful one: Getting the Effective Audit Policy in Windows 7 and 2008 R2.