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

Applies to: Windows Vista BusinessWindows Vista Business 64-bit EditionWindows Vista Enterprise


You can use Windows security and system logs to record and store collected security events so that you can track key system activities to monitor potentially harmful behaviors and to mitigate those risks. You customize system log events by configuring auditing based on categories of security events such as changes to user account and resource permissions, failed attempts for user logon, failed attempts to access resources, and attempts to modify system files.

This article describes the following two Object Access auditing subcategory for success and/or failure events found under Security Settings\Advanced Audit Policy Configuration.
  • Audit File System
  • Audit Handle Manipulation

More Information

In Windows Vista, in Windows Server 2008, in Windows 7, in Windows Server 2008 R2, in Windows 8, or in Windows Server 2012 granular audit policies are integrated with the Group Policies, so they can be applied via a Group Policy Object (GPO) or Local Security Policies. Windows XP had an 'Object Access' category, and would enable file and handle logging. This means that an audit event would be generated for both a success and a failure in Windows XP. However, in Windows Vista and above, this functionality was split into file logging and handle logging. While this is more granular, it also means a little more configuration. 

Audit File System

This security policy setting determines whether the operating system audits user attempts to access file system objects. Audit events are only generated for objects that have configured system access control lists (SACLs), and only if the type of access requested (such as Write, Read, or Modify) and the account making the request match the settings in the SACL.

Right click on the Audit File System and select Properties. Click on Explain tab. The text reads:

If you configure this policy setting, an audit event is generated each time an account accesses a file system object with a matching SACL. Success audits record successful attempts and Failure audits record unsuccessful attempts.

The above statement taken alone is not accurate. 

To help explain, let's consider a scenario on what happens when a user double clicks a text file in Windows Explorer.
  1. Notepad.exe performs an OpenFile with desired access flags.
    • If successful, the OpenFile returns a handle to the text file to Notepad.exe.
  2. Notepad.exe performs on that handle to read the contents of the text file and displays them to the user.
In this case, if only the Audit File System subcategory is enabled, an audit event is logged when Notepad.exe performs step 2 from above. However, if the user does not have permissions to open the file, Notepad.exe never gets to step 2. Therefore, a successful event will be logged if the user has permissions, and no event will be logged if the user does not have permissions. To log events in the failure scenario, the Audit Handle Manipulation category must be enabled as well.

Audit Handle Manipulation

This security policy setting determines whether the operating system generates audit events when a handle to an object is opened or closed. Only objects with configured system access control lists (SACLs) generate these events, and only if the attempted handle operation matches the SACL.

Note: Events in this subcategory generate events only for object types where the corresponding Object Access subcategory is enabled. For example, if File system object access is enabled, handle manipulation security audit events are generated. If Registry object access is not enabled, handle manipulation security audit events will not be generated.