Many organizations elect to audit file system access to provide insight into resource usage and potential security issues. Windows Server 2008 R2 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.
Specifying Auditing Settings on a File or Folder
You can audit access to a file or folder by adding auditing entries to its system access control
1. Open the properties dialog box of the file or folder, and then click the Security tab.
2. Click Advanced.
3. Click the Auditing tab.
The Advanced Security Settings dialog box of a folder named Confidential #Data is shown Figure 7-16.
Figure 7-16 The Advanced Security Settings dialog box of a folder named Confidential Data
4. To add an entry, click Edit to open the Auditing tab in Edit mode.
5. Click Add to select the user, group, or computer to audit.
6. In the Auditing Entry dialog box shown in Figure 7-17, indicate the type of access to audit.
Figure 7-17 The Auditing Entry dialog box
You can audit for successes, failures, or both as the specified user, group, or computer attempts to access the resource by using one or more of the granular access levels.
You can audit successes to:
– Log resource access for reporting and billing.
– Monitor access that would suggest users are performing actions greater than what you had planned, indicating that permissions are too generous.
– 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 failed events helps you to:
– Monitor for malicious attempts to access a resource to which access has been denied.
– Identify failed attempts to access a file or folder to which a user does require access, indicating that the permissions are not sufficient to achieve a business requirement.
Auditing entries instruct Windows to audit the successful or failed activities of a security
principal (user, group, or computer) to use a specific permission. The example in Figure 7-16
audits for unsuccessful attempts by users in the Consultants group to access data in the
Confidential Data folder at any level. It does that by configuring an auditing entry for Full
Control access. Full Control includes all the individual access levels, so this entry coversany type of access. If a Consultant group member attempts access of any kind and fails,
the activity is logged.
Typically, auditing entries reflect the permission entries for the object. In other words, you would configure the Confidential Data folder with permissions that prevent members of the Consultants group from accessing its contents. You would then use auditing to monitor members of the Consultants group who nonetheless attempt to access the folder. Keep in mind, of #course, that a member of the Consultants group can also belong to another group that does have permission to access the folder. Because that access will be successful, the activity is not logged. Therefore, if you are concerned about keeping users out of a folder and making sure they do not access it in any way, monitor failed access attempts; however, also audit successful access to identify situations in which a user is accessing the folder through another group membership that is potentially incorrect.
Note: Don’t over-audit
Audit logs tend to get quite large quite rapidly, so a best #practice for auditing is to configure the bare minimum required to achieve the business task. For example, specifying to audit the successes and failures on an active data folder for the Everyone group using Full Control (all permissions) would generate enormous audit logs that could affect the performance of the server and make locating a specific audited event all but impossible.
Enabling Audit Policy
Configuring auditing entries in the security descriptor of a file or folder does not, in itself,
enable auditing. Auditing must be enabled by defining the Audit Object Access setting shown
in Figure 7-18. After auditing is enabled, the security subsystem begins to pay attention to
the audit settings and to log access as directed by those settings.
The policy setting must be applied to the server that contains the object being audited.
You can configure the policy setting in the server’s local GPO or use a GPO scoped to
You can define the policy to audit Success events, Failure events, or both. The policy setting (shown in Figure 7-18) must specify auditing of Success or Failure attempts that match
the type of auditing entry in the object’s SACL (shown in Figure 7-17). For example, to log
a failed attempt by a member of the Consultants group to access the Confidential Data folder,
you must configure the Audit Object Access policy to audit failures, and you must configure
the SACL of the Confidential Data folder to audit failures. If the resultant audit policy audits
successes only, the failure entries in the folder’s SACL will not trigger logging.
Figure 7-18 The Audit Object Access setting
Note: Making sure audit policy matches auditing entries
Remember that access that is audited and logged is the combination of the audit entries on specific files and folders and the settings in Audit Policy. If you’ve configured audit entries to log failures, but the policy enables only logging for successes, your audit logs will remain empty.
Evaluating Events in the Security Log
After you have enabled the Audit Object Access policy setting and specified the access you
want to audit, using object SACLs, the system begins to log access according to the audit entries. You can view the resulting events in the Security log of the server. Open the Event
Viewer console from Administrative Tools. Expand Windows LogsSecurity.
Note :Auditing access to objects such as files and folders requires three components. First,
the Audit Object Access policy must be enabled and configured to audit Success or Failure
events as appropriate for the scenario. Second, the SACL of the object must be configured
to audit successful or failed access. Third, you must examine the Security log. Audit Policy
is often managed by using a GPO, so the GPO must be scoped to apply to the server with
the file or folder, which is usually a file server rather than a domain controller. Some #exam
questions that appear to be testing your knowledge of auditing are actually testing your
ability to scope a GPO with Audit Policy to the correct servers.