Auditing Events

[Previous] [Next]

Auditing certain computers, users, and operating system events is a necessary part of network administration. You choose what's to be audited and then, by reviewing the event logs, track usage patterns, security problems, and network traffic trends. Beware of the impulse to audit everything, however. The more events you audit, the bigger the logs. Reviewing huge event logs is a painful chore, and eventually no one looks at them anymore. Therefore, it's critical to decide on an auditing policy that protects your network without creating a large administrative burden. Also bear in mind that every audited event results in a small increase in performance overhead.

By default, all auditing categories are turned off when Windows 2000 is installed. Table 10-3 lists the categories of events that can be audited.

Table 10-3. Auditing categories

Event Category	Description
Account logon events	Activated when a domain controller receives a logon request
Account management	Activated when a user account or group is created or changed
Directory service access	Activated when an Active Directory object is accessed
Logon events	Activated when a user logs on or logs off
Object access	Activated when an object is accessed
Policy change	Activated when a policy affecting security, user rights, or auditing is modified
Privilege use	Activated when a user right is used to perform an action
Process tracking	Activated when an application executes an action that is being tracked
System events	Activated when a computer is rebooted or shut down or another event occurs that affects security

Every audited event tells you something, but it's not always something you need to know. For example, auditing successful logons and logoffs may reveal the use of a stolen password, or it may just produce endless pages showing that your duly authorized users are logging on and off as expected. Auditing logon failures, however, will definitely be rewarding if someone is trying a random password hack.

Before you can audit access to Active Directory objects (described in the next section), you must turn on the Audit Policy setting, using Group Policy. To do so, as well as to enable auditing of any of the other categories in Table 10-3, follow these steps:

1. Choose Active Directory Users and Computers from the Administrative Tools menu.
2. Right-click the domain name in the console tree, and choose Properties from the shortcut menu.
3. Click the Group Policy tab and then the Edit button.
4. In the left pane of the Group Policy console, click your way through Computer Configuration, Windows Settings, Security Settings, and Local Policies to reach Audit Policy (Figure 10-9).



Figure 10-9. Choosing categories of events to audit.

5. Right-click the event category you want to audit, and choose Security.
6. In the dialog box that opens, select the check box to define the setting, and select the option to audit successful and/or failed attempts.

Audit Settings for Objects

Assuming that you've turned on a policy setting for auditing an Active Directory object, you create audit settings by following these steps:

1. Right-click the object you want to audit, and choose Properties from the shortcut menu. Click the Security tab.
2. Click the Advanced button, and then click the Auditing tab (Figure 10-10).
3. Click Add to set up auditing for a new group or user. Make your selection and click OK.
4. In the Auditing Entry For Collwin dialog box (Figure 10-11), select the objects you want to audit from the Apply Onto drop-down list. Then, in the Access, select each type of access that you want audited. (Table 10-4 describes each event.) Click OK when you're finished.

NOTE

---

By default, audit settings are inherited by child objects. On the Auditing tab of the Access Control Settings for Collwin box (shown in Figure 10-10) is a check box for allowing inheritable auditing entries. Clear this box and the audit settings for this object will remain constant, even if the parent object's audit settings are changed. In addition, clearing the box will remove any audit settings that have already been inherited. The second check box on this tab resets existing auditing and allows audit entries to be inherited from the parent object once again.

REAL WORLD  Auditing Cautions

---

Windows 2000 allows such granularity that it's possible—no, easy—to create a real morass when selecting audit settings. So many items can show up in the event log that really important issues may be lost in the crowd. Be very careful when deciding what events need to be audited. Audit as few as is reasonable. You can always add events later as circumstances dictate.

Figure 10-10. Selecting a group or user or computer to be audited in connection with an object.

Figure 10-11. Selecting the specific events you want audited.

Table 10-4. File system events that can be audited

Event	Activated When
Traverse Folder/Execute File	A folder is traversed (that is, someone passes through the folder on the way to a parent folder or a child folder) or an application is run
List Folder/Read Data	A folder is opened or data is viewed in files
Read Attributes	The attributes of a file or folder are viewed
Read Extended Attributes	Extended attributes (defined and created by programs) of a file or folder are viewed
Create Files/Write Data	A file is created inside a folder or a file is changed, overwriting existing information in the file
Create Folders/Append Data	A folder is created inside the folder being audited or information is added to an existing file
Write Attributes	A file or folder attribute is changed
Write Extended Attributes	Extended attributes (defined and created by programs) of a file or folder are changed
Delete Subfolders and Files	A file or subfolder is deleted
Delete	A specific file is deleted
Read Permissions	Permissions for a file or folder are viewed
Change Permissions	Permissions for a file or folder are modified
Take Ownership	Ownership of a file or folder changes

Viewing Event Logs

Event logs must be viewed with regularity for auditing to have any effect. To view the security log, open Event Viewer from the Administrative Tools menu and then click Security Log. Double-click any entry to see more information about it. The security entries in Figure 10-12 are the result of one event. The folder was set to audit successful List Folder/Read Data events. One user opening the folder one time generated all the entries you see. Of course, you'll generally learn more from auditing failed events than from auditing successful ones, but this does demonstrate the need to choose one's auditing battles carefully.

Searching Event Logs

No matter how selective you are, the event logs will mix all sorts of information together, making searches for specific information difficult. To search for a specific type of event, highlight the log in Event Viewer, and choose Find from the View menu. In the Find dialog box (Figure 10-13), select the type or types of events you want returned. Table 10-5 describes the other options in the Find dialog box.

Figure 10-12. Viewing the security log.

Figure 10-13. Searching for specific events in a log.

Filtering Event Logs

If you don't have enough specific information to locate what you need, you can filter an event log for certain types of information. To use event log filtering, follow these steps:

1. Choose Event Viewer from the Administrative Tools menu.
2. Right-click the log you want to search, and choose Properties from the shortcut menu.
3. Click the Filter tab. Table 10-5 describes the fields on this tab. Click OK when you're ready to start the filtering.
4. The log appears, filtered as you requested. To view the full, unfiltered log again, return to the Filter tab and click Clear.

Table 10-5. Options for filtering event logs

Option	Use to Search or Filter For
Information	Notification that some major operation has been performed successfully.
Warning	Notification of some problem or potential problem. Warnings may or may not be significant. For example, replication performed after repeated tries will generate a warning.
Error	Notification of an important event. Errors signify a loss of data or a loss of function. For example, failure of a service to start during boot up will generate an error.
Success Audit	Events audited for success.
Failure Audit	Events audited for failure.
Event Source	A source for an event, such as a system component or a program.
Category	Events by category, such as logon/logoff, policy change, or process tracking.
Event ID	The specific ID number assigned to each logged event.
User	A specific user.
Computer	A specific computer.
From	Events after a specific date. The default is the first date in the log. You can click the drop-down box to select events on a specific date.
To	Events before a specific date. The default is the last date in the file.

Setting the Size of Event Logs

When an event log is full, a dialog box will pop up to notify you. If this happens often, you may want to reduce the number of items being reported or increase the size of the log. To set event log options, follow these steps.

1. Choose Event Viewer from the Administrative Tools menu.
2. Right-click the log you want to configure and choose Properties.
3. On the General tab, set the options you want. Under When Maximum Log Size Is Reached, there are three options.

• If you don't archive this log, choose Overwrite Events As Needed.
• If you archive this log at regular intervals, you can select the Overwrite Events Older Than option. Fill in the appropriate number of days.
• Do Not Overwrite Events, the last option, means that the log must be cleared manually. When the maximum log size is reached, new events will simply not be recorded.

4. Click OK when you're finished.

REAL WORLD  Calling a Halt When the Log Is Full

---

Maybe you are so security-conscious that none of the event log options are acceptable. If you absolutely, positively mustn't lose a single security event, you can set the computer to halt when the security log is full. A registry change is necessary to make this happen. First, set Event Log Wrapping to either Do Not Overwrite Events or Overwrite Events Older Than n Days. Then start RegEdit.exe and proceed to HKEY_LOCAL_MACHINE\SYSTEM\CurentControlSet\Control\Lsa\CrashOnAuditFail, and change the value to 1.

This setting will take effect after a reboot and then, when the log is full, the system will simply stop. After restarting, only administrators will be able to log on until the security log is cleared. This is a drastic measure, but it is necessary in some cases.

Archiving Event Logs

If you will be using event logs to track system usage trends, you must save them. To archive an event log, open Event Viewer from the Administrative Tools menu, and click the log you want to archive. Then, from the Action menu, choose Save Log As. If you save the file in the event log format (.EVT), it can be reopened in Event Viewer, and all the binary data for each event will be retained. You can also save logs as .TXT files or in comma-delimited format (.CSV), but in those cases the binary data isn't saved. Chapter 32 has details on using Event Viewer and the logs that are generated to learn more about the network and tune its performance.