Securing Windows Server 2008 R2 : Auditing

Being able to natively audit within Windows operating systems is a feature that has existed almost since the dawn of time, back to Windows NT 4.0. Although auditing has evolved with the progression of Microsoft operating systems to become more robust and configurable, the largest change in Windows auditing occurred rather recently—when Microsoft introduced Granular Audit Policies (GAPs) with Windows Server 2008 and Windows Vista.

Traditionally, with Windows 2000 and Windows 2003, auditing policies were broken down into nine distinct categories:

• Audit Account Logon Events

• Audit Account Management

• Audit Directory Services Access

• Audit Object Access

• Audit Logon Events

• Audit Policy Change

• Audit Privilege Use

• Audit Process Tracking

• Audit System Events

Each of these categories contained settings that allowed the administrator to configure what was to be collected as part of an audit trail and recorded in the Event Viewer Security log. Central configuration of the auditing categories was available as a part of AD Group Policy. Essentially, once an administrator created an audit policy in AD within a GPO and linked the GPO to the appropriate places, the machines impacted would understand that they needed to track the policy-designated settings.

The part of Audit Object Access that could never be specified for the machine through Group Policies was the indicator of which users and resources should be tracked specifically. In actuality, by configuring the policy within AD to enable object access auditing, an administrator was only half done with the configuration.

The second step in configuring object access auditing has always involved enabling auditing at the resource level. So, to have a particular resource begin to generate an audit trail, the administrator would have to touch each resource individually to specify that it should audit, and additionally for which users auditing should be tracked. So, for instance, if a file server had 500 shares configured, the probability of requiring an audit trail for any confidential shares is high, but most likely the administrator would not require an access audit trail for all 500 shares. By configuring auditing at the resource level, the administrator would have to physically select each share where auditing was required and enable auditing by configuring the System Access Control List (SACL) for the share. Each and every resource in an environment retains its own SACL which is used to identify the accounts or groups that should be tracked as part of the auditing process.

Now let us examine some of the changes introduced with Windows 2008 and Windows Vista. Microsoft took the nine base categories and evolved them to create GAP. GAP expanded on the original categories and to create a total of 50 categories that could be toggled on and off. This sounds like a really great thing, right? More flexibility, more granular settings, more robust, generally what appears to be an administrator’s dream. Well, in some ways yes, while in other ways no.

One of the limitations of GAP in Windows 2008 and Windows Vista is that it cannot be configured with Group Policy. Instead, GAP can only be configured via the command line tool auditpol.exe. Since GAP is applied by executing a tool on the local machine, the end result is that the auditing settings exist within the Local Computer Security Policy on the machine. For computers in a workgroup to configure normally, there is no issue with this, but if a machine is domain-joined, there is the chance for conflict.

If a Group Policy is configured within AD that utilizes the traditional auditing categories, and the policy is applied to the machine on which you have run auditpol.exe to configure GAP, the local settings may be overridden. In order to prevent this, it is recommended to apply a registry change to all machines with GAP configured that will force the machine to ignore Group Policy-based auditing settings.

So as you can see, with Windows 2008 and Windows Vista, auditing capabilities were improved, but unfortunately, the administrative and management of the settings did not follow suit; instead, they were associated with increased administrative overhead and maintenance. For many corporate environments, the end result of the auditing changes released with Windows 2008 and Windows Vista was a pile of frustrated administrators. However, there is light at the end of the tunnel. With the release of Windows 2008 R2, Microsoft has taken to auditing those last few steps to make it robust as well as centrally manageable, ultimately bringing Windows auditing up to a new level of functionality and maturity.

The largest change in auditing with Windows Server 2008 R2 is the capability to administrate and deploy the GAPs from within Group Policy. Instead of relying on auditpol.exe and being forced to create and run scripts to apply granular auditing setting to systems, administrators now have the advantage of utilizing a familiar toolset to enforce GAP. As you can see in Figure 1, all of the expanded categories available for auditing within GAP are now exposed and enforceable through GPOs.

Be aware that Group Policy-based enforcement of GAP only applies to Windows 7 and Windows 2008 R2 machines. Even though Windows 2008 and Windows Vista machines support GAP, they must still have separate policies created and applied through the use of auditpol.exe.

Another significant change in auditing for Windows Server 2008 R2 revolves around auditing object access. When you enable object access on a machine in Windows Server 2008 R2, there are no SACLs to create or set on each individual resource. Instead, by utilizing Group Policy settings to enforce audit settings, you have the ability to utilize the Global Audit object policy to identify which users and what level of auditing is configured on the machine SACLs. The Global Audit policy has two choices that can be configured: File System Properties and Registry Properties. Configuring File system Properties is displayed in Figure 2. By default, once targeted by a Global Audit policy, all resources will have their SACL configured and enabled for object access auditing. If by chance, the local SACL and the Global SACL are defined on a particular resource, the two lists are combined and the SACLs from both locations will be used for auditing.

Figure 2. Configuring File System Properties.

The final notable change for object access auditing in Windows Server 2008 R2 is that the messages recorded to the event logs now contain more detail. This is referred to by Microsoft as “Reason for access” reporting. Instead of merely stating that an allow or deny has occurred, now the event will additionally state why the event occurred. An example of an Event Viewer message as a result of object access auditing is shown in Figure 3.

Figure 3. Audit Message in Event log.