Windows DevCenter    
 Published on Windows DevCenter (http://www.windowsdevcenter.com/)
 See this if you're having trouble printing code examples


Defining a Baseline Audit Policy

by Mitch Tulloch
07/26/2005

Auditing for security events on critical computer systems is an essential component of a sound security policy. An audit policy is the portion of a Group Policy object (GPO) that defines which security events have success and/or failure actions audited and recorded in the Security log. A baseline audit policy is the minimum auditing you should perform on a given type of system. Let's examine the default audit policies for Windows Server 2003 server roles and see whether they are adequate for the security needs of a typical company.

Default Audit Policy on Member Servers

On a freshly installed Windows Server 2003 member server with no server roles defined, only two types of auditing are defined:

All seven other audit categories (management events, directory service access, object access, policy change, privilege use, process tracking, and system events) are configured for no auditing. This makes sense for several reasons:

Related Reading

Windows Server Hacks
100 Industrial-Strength Tips & Tools
By Mitch Tulloch

Auditing log-on events and account log-on events on a member server does make sense, however. The difference between these two audit categories is that the auditing of account log-on events records the actions taken by authentication packages. If someone tries to log on to a member server using a local account, the authentication process is performed by the member server itself, and an event (success or failure audit) will be logged in the Security log on the member server. On the other hand, if somebody tries to log on to a member server using a domain account, the authentication process is performed by a domain controller, and an event is recorded in the Security log on the authenticating domain controller.

By contrast, the auditing of log-on events is designed simply to track which users are logging on to which computers on your network, whether interactively (on the local console) or remotely (network log on). Log-on events are always recorded in the security log of the computer where the user is trying to log on. So by auditing both log-on events and account log-on events on a member server, you can record all attempts to log on to the server and, especially, monitor any attempts to log on using local accounts. This is important because local accounts are generally not used in domain environments, so any attempt to log on to a server using a local account other than for troubleshooting purposes should raise a red flag of a possible intrusion attempt. Auditing account log-on events can help expose such attempts.

But is the default audit policy for member servers really good enough? You might also want to consider enabling success and failure auditing for policy change events, as this will detect any attempt to change the security policy on the server. And if you have critical data files on your server and want to track unauthorized attempts to access them, you can also enable failure auditing of object access and then configure SACLs (static access control lists) on the files you want to monitor. Finally, you might also want to audit both successes and failures for both log-on events and account log-on events; I'll explain why in a moment.

Default Audit Policy for Domain Controllers

The default audit policy on a Windows Server 2003 domain controller is more stringent than for member servers and looks like this:

Audit category Default audit setting
Account log-on events Success
Account management events Success
Directory service access Success
Log-on events Success
Object access No auditing
Policy change Success
Privilege use No auditing
Process tracking No auditing
System events Success

Several ideas are most likely behind these default settings. One is that auditing privilege use and process tracking is of not much use since the information gained is mostly useful for troubleshooting purposes. Another is that auditing object access is not critical because Windows File Protection (WFP) guards operating system files, and domain controllers usually aren't used to store other business information the way file servers are. In addition, success auditing gives a good enough picture of how resources are used on domain controllers, and the failure auditing of these resources is therefore unnecessary.

I disagree with this thinking on three points:

A better audit policy for a domain controller might look like this:

Audit category Default audit setting
Account log-on events Success, failure
Account management events Success, failure
Directory service access Success, failure
Log-on events Success, failure
Object access Success, failure
Policy change Success, failure
Privilege use Failure
Process tracking No auditing
System events Success, failure

And in fact, just such an audit policy is recommended by the Microsoft Windows Security Resource Kit.

Security Configuration Wizard

The Security Configuration Wizard (SCW) of Service Pack 1 for Windows Server 2003 can also be used to strengthen the audit policy on servers. SCW provides you with three options for defining an audit policy: no auditing, audit successful activity (the default), and audit successful and unsuccessful activity (Figure 1):

Figure 1
Figure 1. Using the SCW to configure auditing

The table below shows the audit policy configured for the second and third options:

Audit category Audit successful activity Audit successful and unsuccessful activity
Account log-on events Success, failure Success, failure
Account management events Success Success, failure
Directory service access Success Success, failure
Log-on events Success, failure Success, failure
Object access Success Success, failure
Policy change Success Success, failure
Privilege use No auditing No auditing
Process tracking Success Success, failure
System events Success, failure Success, failure

Comparing the these two options with the default and recommended audit policies for domain controllers discussed previously, we can see that the second option (audit successful activity) is stronger than the default policy but weaker than the one recommended by the Security RK. We also see that the third option is close to the policy recommended in the Security RK but differs in two important aspects. First, the policy created by the SCW doesn't audit failure of privilege use, which we saw can be useful for detecting certain kinds of attacks. Second, the SCW-created policy audits both success and failure for process tracking events. This is not a good idea because it will flood your security log with events generated whenever any process initiates or terminates, when handles are duplicated, and when numerous other low-level process events occur. It's difficult to see how any useful threat information can be extracted from such a flood of information.

One thing the SCW does is configure SACLs on operating system files so that object access auditing can collect useful information. So using the SCW to configure auditing on your SP1 domain controllers isn't a bad idea. You just may want to change the auditing of process tracking to No Auditing afterward and also change the auditing of privilege use to Failure. You can accomplish this by modifying the audit policy section of the Default Domain Controllers Policy GPO to make these two audit categories configurable in the LGPO on the domain controllers.

Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.


Return to the Windows DevCenter.

Copyright © 2009 O'Reilly Media, Inc.