Recipe 17.2. Enabling Auditing

Problem

You want to enable auditing in order to track certain types of activity that can be useful in case you need to backtrack at a later point to determine the cause of security-related issues (e.g., user accidentally deleted, account being compromised, etc.).

Solution

Using a graphical user interface

1. Open the Local Security Policy snap-in.

2. In the left pane, expand Local Policies Audit Policy.

Be sure to thoroughly test any audit settings before implementing them in production. Even after implementing a change in production, periodically monitor the security event log to ensure the log isn't being flooded with events.

Table 17-1. Audit policy settings

Audit setting	Access type	Recommendation
Account Logon Events	User account log on and log off attempts that are validated by this system.	This setting is most often used on domain controllers, which are generally responsible for authenticating users in a domain environment. Be careful when enabling this because of the large number of events that might be logged.
Account Management	Creation, modification, and deletion of user, group, and computer accounts. Also includes password changes.	Consider enabling both Success and Failure auditing for this setting on member systems, which generally shouldn't have too much account management activity. For domain controllers, you may only want to enable Failure, due to the high number of account management activities.
Directory Service Access	Any type of read or write access to an object in Active Directory.	After enabling this setting, you must also modify the SACL of the object you want to audit. Be careful enabling this on a large container or commonly accessed object in the directory because it can generate a lot of events quickly.
Logon Events	User account log on and log off attempts, and the initiation of network connections.	Unlike the Account Logon Events setting, this setting logs the events on the computer that the request is being made on, not necessarily the computer that is validating the accounts involved. Depending on how busy your systems are, this setting may generate a large number of events.
Object Access	Any type of read or write access to an object on the system (file, folder, printer, Registry key, etc.).	After enabling this setting, you must also modify the SACL of the object you want to audit. Be careful enabling this on a frequently accessed object because it can generate a lot of events quickly.
Policy Change	Change to user right policies, audit policies, and trust policies.	Because the number of policy changes is generally low, you might want to consider enabling both Success and Failure auditing for this setting.
Privilege Use	User exercising a user right (e.g., Act as part of the operating system, Access this computer from the network, Log on as a service, etc.).	Enabling either Success or Failure for this setting can generate a lot of events, so enable them only if explicitly needed.
Process Tracking	Process creation and termination, and other process-related activities.	Since processes are created and terminated very frequently, enabling Success or Failure for this setting can generate a lot of events. Enable it only if explicitly needed.
System Events	System restart or shutdown, and modifications to system security or the security event log.	Since the number of these type of events should be relatively low, consider enabling both Success and Failure.

See Also

MS KB 300549, "HOW TO: Enable and Apply Security Auditing in Windows 2000"