Setting Up an Audit Policy

In Part 1 of this series (
Creating an Audit Policy
), I discussed some of the issues to consider when setting up an audit policy in Windows 2000. In this article, I’ll continue the discussion by demonstrating the actual process of setting up an audit policy.

Events to Audit

In Part 1, I explained that you can audit a variety of events. These events fall into several categories. Before I get into the actual process of setting up an audit policy, I’ll briefly review what’s included in these categories:

  • Account Login–An event that’s triggered when a domain controller receives a login request. You can audit an account login based upon successful logins or login failures.
  • Account Management–Pertains to any sort of maintenance to user accounts. For example, if a user creates, renames, or deletes a user account, an event can be logged. Other types of Account Management events include changing passwords, or enabling or disabling user accounts.
  • Directory Service Access–A very general category. Basically, it refers to any time a user changes an Active Directory object. However, as you’ll see later in the series, there are many different ways to audit this type of event.
  • Logon Events–It may seem that Logon Events are the same as Account Logins, but the two are separate. Login Events refer to any time any user logs in or out of the system. In some situations, Login Events may also be triggered when a user connects to or disconnects from a computer on the network.
  • Object Access–It’s easy to confuse Directory Service Access and Object Access. However, whereas the Directory Service Access events log the way that users access Active Directory objects, Object Access tracks the way that users access physical objects such as files, folders, and printers. When establishing an audit policy for Object Access events, it’s important to remember that you can’t simply set up a generic policy that logs every event for every object. Windows 2000 requires you to audit specific objects, such as a specific directory or printer.
  • Policy Change–Perhaps one of the most important types of event category. These events are triggered when someone makes a change to your security policies. These changes may include anything from changing user rights to changing audit policies.
  • Privilege Use–As you may know, in Windows 2000 it’s possible to relieve yourself of some administrative burden by delegating certain rights to others. For example, you might allow the help desk to reset passwords. However, just because you give someone permission to perform a high-level function doesn’t mean you should completely turn your back on them. The Privilege Use category of events can be used to make an event log entry any time that someone uses one of the special rights you’ve assigned to them.
  • Process Tracking–The Process Tracking set of events isn’t generally of much use when it comes to security. Generally, it’s geared more to programmers and administrators who want to know what resources a program is using and why that program keeps crashing.
  • System Events–Events going on within the physical system. For example, you can log each time a server (or workstation) is shut down or restarted. A system event can also be triggered if the security log fills up.

Setting Up an Audit Policy

The method you’ll use to create an audit policy will vary slightly depending on whether you’re creating the policy on a member server, a domain controller, or a stand-alone server. However, you’ll use the same basic tools in each case. All the methods use security-related Microsoft Management Console (MMC) snap-ins. The main difference is that if you’re configuring a domain controller, member server, or workstation, you’ll use the Active Directory Users and Computers snap-in. If you’re configuring a system that doesn’t participate in a domain, you’ll use the Local Security Settings snap-in.

Auditing a Local System

For the purposes of this article, I’ll focus primarily on systems that are part of a domain. However, before I get started, I’ll briefly discuss stand-alone systems. To establish an audit policy on a system that doesn’t participate in a domain, follow these steps:

  1. Load the Local Security Settings snap-in by selecting Programs|Administrative Tools|Local Security Policy from the Start menu.
  2. Double click on the Local Policy object in the Security Settings tree to expand it.
  3. Select Audit Policy from the tree. Doing so will reveal the auditing information for that system.
  4. To enable auditing for any of the areas I discussed earlier, double-click on the type of audit you want to work with. When you do, a dialog box will ask if you want to perform a success or a failure audit (or both) on that type of event.

Once you’ve enabled auditing, it’s up to you to go through the system and fine-tune the type of events that will be audited in each category. The process for doing so is the same as that used for systems that participate in a domain. I’ll discuss these procedures later in the series.

Auditing Within a Domain

To set up an audit policy within a system that’s a part of a domain, follow these steps:

  1. Choose Start|Programs|Administrative Tools|Active Directory Users and Computers.
  2. When the Active Directory Users and Computers console loads, navigate through the console tree to the domain you want to work with. Expand the domain.
  3. Beneath the domain, you’ll see a Computers object and a Domain Controllers object. Select the appropriate object for the system you’re working with. Because my primary test system is a domain controller, I’ll be working under the Domain Controllers section for the remainder of this article.
  4. Once you’ve selected the appropriate object, right-click on it. (That is, right-click on Domain Controllers, not on the icon for the specific system you’re working with.) Doing so opens the Domain Controller’s properties sheet.
  5. Select the Group Policy tab. Select the group policy to which you want to apply the audit policy and click Edit.
  6. Windows 2000 will load the Group Policy console. Navigate through the tree to Default Domain Controllers Policy|Computer Configuration|Windows Settings|Security Settings Local Policies|Audit Policy.
  7. When you select Audit Policy, you’ll see a list of audit events to the right. This list is identical to the one used in the section on auditing systems that don’t participate in a domain. To audit a group of events, double-click on the group of events you want to work with. A dialog box will open that lets you enable success and/or failure audits for that group of events.

After enabling auditing for a group of events, you’ll still have to manually fine-tune the exact events you want to audit. Again, I’ll show you how to do that later.

In future articles in this series, I’ll explain how to audit specific events. For now, it’s important to know that making changes to the audit policy is essentially the same as making changes to the security policy. Whether you’re working on a stand-alone system or on a system that’s part of a domain, security policy updates don’t take effect until they have propagated to the system or domain.

Audit Policy Propagation

Propagation is basically the process of applying the change to all the necessary places within the system or domain. By default, it occurs every eight hours. Of course, you can always tweak the system settings to force propagation to occur more often. However, this isn’t always a good idea, because doing so can decrease a network’s performance. A better method is to use a command to force propagation to occur on an as-needed basis. The command for instant propagation is


If you have trouble getting the command to work, you can also force propagation to occur by rebooting the system. (Of course, rebooting isn’t usually an option if you’re working with a server.)



Now that you know how to enable auditing on various types of events, it’s time to learn how to fine-tune which events will be audited. For example, so far I’ve shown you how to audit when someone attempts to access a resource by enabling an audit on the Audit Object Access option. However, simply enabling this option won’t do you any good unless you also define the objects you want to audit. I’ll show you how to select these objects, and how to do some other types of fine-tuning, in Part 3 (
Auditing Specific Events
). Later in the series, I’ll also show you how to get the most out of the audit logs you’re creating. //

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.

Latest Articles

Follow Us On Social Media

Explore More