Auditing File System Access

Many organizations elect to audit file system access to provide insight into resource utilization and potential security vulnerabilities. Windows Server 2003 supports granular auditing based on user or group accounts and the specific actions performed by those accounts. To configure auditing, you must complete three steps: specify auditing settings, enable audit policy, and evaluate events in the security log. This Topic will explore these three processes and provide guidance to effective auditing, so that you can leverage auditing to meet business requirements without being drowned in logged events.


Configuring Audit Settings

To specify the actions you wish to monitor and track, you must configure audit settings in the file’s or folder’s Advanced Security Settings dialog box. The Auditing tab, shown in below Figure, looks strikingly similar to the Permissions tab before it. Instead of adding permissions entries, however, you add auditing entries.

Click Add to select the user, group, or computer to audit. Then, in the Auditing Entry dialog box, as shown in below Figure, indicate the permission uses to audit.

You are able to audit for successes, failures, or both as the account attempts to access the resource using each of the granular permissions assigned to the object.

Successes can be used to audit the following:

 To log resource access for reporting and billing.

 To monitor for access that would indicate that users are performing actions greater than what you had planned, indicating permissions are too generous.

 To identify access that is out of character for a particular account, which might be a sign that a user account has been breached by a hacker.

Auditing for failed access allows you:

 To monitor for malicious attempts to access a resource to which access has been denied.

 To identify failed attempts to access a file or folder to which a user does require access. This would indicate that permissions are not sufficient to achieve a business task.

Audit settings, like permissions, follow rules of inheritance. Inheritable auditing settings are applied to objects that allow inheritance.

Enabling Auditing

Configuring auditing entries in the security descriptor of a file or folder does not, in itself, enable auditing. Auditing must be enabled through policy. Once auditing is enabled, the security subsystem begins to pay attention to the audit settings, and to log access as directed by those settings.

Audit policy may be enabled on a stand-alone server using the Local Security Policy console, and on a domain controller using the Domain Controller Security Policy console. Select the Audit Policy node under the Local Policies node and double-click the policy, Audit Object Access. Select Define These Policy Settings and then select whether to enable auditing for successes, failures, or both.

You may also enable auditing for one or more computers using Active Directory Group Policy Objects (GPOs). The Audit Policy node is located under Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy. Like all group policies, the computers that are affected by the policy will be those contained within the scope of the policy. If you link a policy to the Servers OU and enable auditing, all computers objects in the Servers OU will begin to audit resource access according to audit entries on files and folders on those systems.

Examining the Security Log

Once audit entries have been configured on files or folders, and auditing object access has been enabled through local or group policy, the system will begin to log access according to the audit entries. You can view and examine the results using Event Viewer and selecting the Security log, as shown in below Figure.

As you can see, the Security log can be quite busy, depending on the types of auditing being performed on the machine. You can sort the events to help you identify object access events by clicking the Category column header and locating the Object Access events.

Sorting will, however, provide little assistance as you dig through the logged events. You will often be better served by filtering the event log, which can be done by choosing the Filter command from the View menu, or alternatively by selecting the Security log, then Properties from the Action or shortcut menus, and then clicking the Filter tab. The Filter tab enables you to specify criteria including the event type, category, source, date range, user, and computer. Below Figure illustrates an example of a filter applied to identify object access audit events on a specific date.

Finally, you have the option to export the Security log by selecting the Save Log File As command from the log’s context menu. The native event log file format takes a .evt extension. You can open that file with Event Viewer on another system. Alternatively, you can save the log to tab- or comma-delimited file formats, which can be read by a number of analysis tools including Microsoft Excel. In Excel, you can of course apply filters as well to search for more specific information, such as the contents of the event’s Description field.