Ask Us About...Security November 15, 2001

Security Auditing in Windows 2000

by Steve Riley

Do you know what's happening on your servers—who's accessing them, what your users are doing, what they're attempting to do? If you're like most administrators, probably not. Would you like to know? Microsoft Windows® 2000 provides a security auditing facility that can log several kinds of security-related events. You can use the information here to build a profile of regular activity, spot and track suspicious events, and retain legally-valid evidence of an intruder's actions.

Auditing events are written to the security log in the Event Viewer. Auditing is disabled by default—you need to turn it on; enabling auditing requires administrator access to the machine (if you want to enable auditing on a specific computer) or the domain (if you want to enable auditing across an entire domain). Active Directory® directory service group policies can help you configure custom auditing parameters for different classes of computers.

On This Page

Auditing a Single Computer
Auditing Object Access
Auditing Across an Entire Domain
Auditing Scenarios

Auditing a Single Computer

Go to Start | Programs | Administrative Tools and choose Local Security Policy. This opens an MMC (Microsoft Management Console) view to the computer's local security settings; go to Local Policies | Audit Policy to configure the audit events.

There are nine event categories you can audit, and for each one you can indicate whether to audit success, failure, or both.

• Account logon events. Authenticating (account validation) to the local computer across a network. These events are generated where the account lives.

• Account management. Creating, modifying, or deleting users and groups; password changes.

• Directory service access. Record access to Active Directory. Must be enabled to permit auditing specific directory objects. On domain controllers only.

• Logon events. Interactive logons or network connections to the local machine. These events are generated where the logon occurs.

• Object access. Must be enabled to permit auditing specific objects.

• Policy change. Security policy changes, including privilege assignments, audit policy modifications, and trust modifications.

• Privilege use. Use of a privilege; assignment of special privileges.

• Process tracking. Detailed tracking of process invocation, duplicate process handles, indirect object access, and process termination.

• System events. Events related to security such as system shutdowns and restarts; events that affect the security log.

Configuring auditing will use some disk space on your computer. You can configure a maximum size (in kilobytes) to which the security log can grow and what to do once the log size reaches that limit. In the Event Viewer, right-click Security Log and choose Properties. You'll see:

• Overwrite events as needed. Drop the oldest event from the log each time a new event is written. This retains the most information while keeping the log at its maximum size.

• Overwrite events older than x days. Drop events from the log that are older than x days. If the log fills up before the oldest events age out, no new events will be written. This is a useful setting if you wish to archive the log every x days, but less useful if you don't archive—you'll miss recent events.

• Don't overwrite events. Stop recording audit events once the log fills up. You'll need to manually clear the log.

Archiving the Security Log

Archiving the log is important for a number of reasons. Saving the logs on some off-line storage medium reduces the need to keep large volumes of log data on production servers. Saved logs contain useful information to learn about a computer's regular behavior. Offline logs are also regarded as legal evidence in an investigation; they contain forensic information to help track and determine the actions of an intruder.

To archive the security log, open the Event Viewer, right-click Security Log, choose Save Log File As, and enter a path and filename for the archive. Ideally, this should be a network path to an internal server dedicated for log archiving. Be sure to save the archive in .evt (event log) format—this preserves the binary information in the log's detail records.

Stopping a Server When the Log Is Full

You can configure the server to crash (blue-screen) when the log fills up. This is actually a good idea for highly-secure servers—in some instances, it's better to stop offering a service than to offer it without logging. To configure system shutdown:

1. In the Local Security Policy MMC, go to Local Policies | Security Options.

2. Scroll down to Shut down system immediately if unable to log security audits

3. Double-click this and select Enable.

If you configure this, then when a system crashes, take the following steps to recover:

1. Log on to the system's local administrator account.

2. Archive the log.

3. Clear the log.

4. Re-enable the option—upon crash, the option disables itself.

Additional Auditing Controls

There are two additional auditing events that you can configure, but not from the Audit Policy page. If you want to audit the use of backup and restore:

1. In the Local Security Policy MMC, go to Local Policies | Security Options.

2. Scroll down to Audit the use of Backup and Restore Privilege

3. Double-click this and select Enable.

Audit Privilege Use must be enabled for this to have effect.

To audit the access of global system objects (mutexes, semaphores, and DOS devices):

1. In the Local Security Policy MMC, go to Local Policies | Security Options.

2. Scroll down to Audit the access of global system objects

3. Double-click this and select Enable.

Audit Object Access must be enabled for this to have effect. Auditing global system objects is probably unnecessary in most environments.

Auditing Object Access

If you need to audit access to particular objects, you first need to enable the appropriate general setting in the audit policy—either Directory Service Access for Active Directory objects or Object Access for files, folders, drives, printers, and registry keys. After you've enabled the policy, then you can enable auditing of specific objects, usually on the object's properties page.

Auditing files, folders, and drives. In Windows Explorer, navigate to the file, folder, or drive you want to audit. Right-click the object and choose Properties | Security | Advanced | Auditing. Click Add to select a particular user or group whose access you want to audit. The auditing entry dialog shows various accesses that you can audit the success or failure of. For folders and drives, you'll also be able to indicate the auditing scope—this folder, subfolders, files, or some combination of these.

Auditing printers. Open the Printers folder and right-click the printer you want to audit. Choose Properties | Security | Advanced | Auditing. Click Add to select a particular user or group whose access you want to audit. As with files and folders, the auditing entry dialog shows various accesses that you can audit the success or failure of.

Auditing the registry. Open the registry with REGEDT32 and navigate to the key you want to audit. Choose Security | Permissions from the main menu, then choose Advanced | Auditing. Click Add to select a particular user or group whose access you want to audit. As with files and folders, the auditing entry dialog shows various accesses that you can audit the success or failure of.

Auditing Active Directory. This works only on domain controllers. Open Active Directory Users and Computers. Navigate to the particular directory object you want to audit. Right-click the object and choose Properties | Security | Advanced | Auditing. Click Add to select a particular user or group whose access you want to audit. The auditing entry dialog shows various accesses that you can audit the success or failure of. The Apply onto field allows you to set the scope.

Auditing Across an Entire Domain

You can apply a single auditing policy across an entire domain. On any domain controller, go to Start | Programs | Administrative Tools and choose Domain Security Policy. This opens an MMC view to the domain's security settings.

In Local Policies | Audit Policy you'll see exact same settings here as in a computer's local settings page. You'll also see the same additional auditing settings (global system objects, backup and restore, and shutdown on full log) in Local Policies | Security Options. The settings that you configure here will be applied to every machine in the domain. Domain members won't receive new settings immediately; because these are machine-level policy elements, they'll get applied next time domain member computers boot.

There is an additional page in the domain security policy that's of interest. In Event Log | Settings for Event Logs, you can globally set the security log size, allow or deny guest access to the log, configure the log's disposition, and system shutdown on full log.

Customizing Logging within a Domain

You might want to configure different kinds of auditing for servers and workstations. In this case, don't use the Domain Security Policy MMC to configure auditing. Instead, use group policies in Active Directory to create custom auditing configurations for the various machine classifications you have.

Organizational units (OUs) are the basis for this. In Active Directory Users and Computers, create organizational units that represent your machine classifications. Then, for each OU, create a group policy object that includes the specific audit events appropriate for that class of machines. Here are the steps to do this:

1. Right-click the OU.

2. Choose Group Policy.

3. Click New, give the new group policy object a name, and click Edit.

4. Navigate to Computer Configuration | Windows Settings | Security Settings.

5. Configure the various audit events in Local Policies | Audit Policy, Local Policies | Security Options, and Event Log | Settings for Event Logs.

Finally, move your computers into the OUs. Next time the computers boot, they'll receive the settings defined in the OUs to which they belong.

Local Policy vs. Effective Policy

Audit event settings obey standard group policy application rules. The order of application is:

1. Local policy settings

2. Site policy settings

3. Domain policy settings

4. Organizational unit policy settings

By default, site, domain, and OU policies are all undefined. Each machine's local policy, if it has one, will be the effective policy. If, however, a policy element higher in the hierarchy is defined, and the group policy has been configured to disallow local overrides, that definition will override the lower one. This means that while you can configure as few or as many local auditing events as you wish, if a domain policy (for example) specifically enables or disables a particular auditing event, that setting will take precedence over whatever local setting you might have defined.

Auditing Scenarios

Knowing what to audit might be a little difficult to determine at first. This table lists some potential threats and what auditing settings will help indicate whether the system is under that kind of attack.

Please send any feedback or questions regarding the content of this column to Microsoft Technet.