As you know, maintaining a secure, healthy network entails auditing server and workstation activity and examining logs frequently for signs of intrusion or unexpected events. Each time you use Group Policy or Local Security Policy to adjust security audit settings, you must force a policy refresh to update the settings for each system on which you want to implement the changes. When you use the Microsoft Management Console (MMC) Local Security Policy snap-in to modify security audit settings, you must remember to use the secedit /refreshpolicy machine_policy command to manually refresh the policy and activate the changes. If you don't refresh the policy, the system will remember the new audit settings but fail to implement the changes until you reboot the system (rebooting refreshes the security policy).

When you suspect that a system is under attack, you can use AuditPol to implement security audit changes on a specific system immediately. Unlike other, more dated resource kit tools, AuditPol functions exactly as its documentation states. You can use AuditPol to enable or disable security auditing on local or remote systems and to adjust the audit criteria for nine categories of security events. The command’s syntax is straightforward:

auditpol \[\\computer\] \[/enable | /disable\]
\[/category:type\] \[/category:type\] ...

As with most Windows 2000 utilities and commands, you can display the tool’s options by typing

auditpol /?

at a command prompt. If you omit the computer-name argument, the utility runs on the local system. To run the command on a remote system, enter the name of the remote system. AuditPol is flexible, so you can enter the remote system name a few different ways (e.g., auditpol \\darwin, auditpol \\, auditpol \\

The /enable switch turns on security auditing. Because /enable is the default, you can safely omit the switch when you add or remove categories or the type of events that you want to audit in a category. Use Auditpol without any arguments to display the local system’s current security audit settings, and enter a computer name to display the current security audit settings on a remote machine.

The /category argument correlates with the nine categories of security audit events in Group Policy's Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy and the machine's Local Security Policy's Security Settings\Local Policies\Audit Policy. Select the category or categories that you want to add or modify from the following list (because AuditPol doesn't identify audit categories using the same terms you see in Group Policy or local security policy, I include the snap-in category name in parentheses).

  • Account (account logon events) events monitor logon attempts on a domain controller (DC).
  • Directory (directory service access) is a generic category that you must enable to audit access to DC objects.
  • Logon (logon events) events monitor logon attempts on the local system.
  • Object access (object access) is a generic category that you must enable before you can track access to specific file, folder, or shared resource.
  • Policy (policy change) events track changes to the local security policy.
  • Privilege (privilege use) events monitor operations that grant elevated privileges to user or group accounts.
  • Process (process tracking) is a generic category that you must enable to audit access to a specific process.
  • Sam (account management) events monitor changes to individual or group accounts on the local system in the SAM database.
  • System (system events) events include system and service startup and shutdown, messages from the browser, RRAS, or the W32 Time Service.

For each category, you specify the type of events the system should record: success events, failure events, all events (failure and success), or none. As the syntax illustrates, you can combine /category arguments on the command line to fine tune the events you want recorded in the Security event log.

Here are two equivalent commands that enable security auditing on a DC named darwin for all types of system, domain logon, policy, and directory service access events:

 /enable /system:all /account:all /policy:all /directory:all
 auditpol \\darwin
  /system:all /policy:all /account:all /directory:all

The next command enables auditing for all privilege events and changes the type of security audit on system events to only those that fail. If you run AuditPol repeatedly on the same system, check the utility's output after each operation to confirm the cumulative effects of your changes.

auditpol \\darwin
 /system:failure /privilege:all

The example below eliminates security audit logging for privilege events only, leaving all other settings intact. Notice that you don't enter the /disable switch to disable a specific category of event logging.

auditpol \\darwin

The /disable switch sets the audit type to none for all nine event categories. Don't be misled by the utility’s feedback when you use the command Auditpol /disable. For example, when you enter the command

auditpol \\darwin /disable

with a computer name valid at your site, AuditPol outputs a list of the previously active security audit settings and then correctly sets the audit type to none for all nine categories. You can verify that AuditPol is working correctly by using Group Policy or the Local Security Policy snap-in to display the current settings. Remember, however, that when you change the audit settings, you might need to restart the Local Security Policy snap-in to force the snap-in to refresh the current settings.

Here’s a recommended sequence of commands you can use to get familiar with Auditpol. The first command displays the current security audit settings, the second enables auditing for four categories, and the third disables auditing for all categories and events.

/logon:all /sam:all system:all /account:failure
auditpol \\computername