Auditing Windows 2000

Auditing, or the ability to track security events in the Windows NT security log, is a valuable tool for helping you maintain the security of your systems. Microsoft has improved on NT's auditing features with Windows 2000, which offers significant enhancements. In addition to NT’s seven categories of audit events, Win2K provides two new categories to track additional areas of activity. Let's take a close look at Win2K's auditing capabilities and see how they differ from NT's.

Configuring Audit Policy
Like NT, Win2K’s default audit policy disables each audit category, so the security log is empty on a freshly installed system. Unlike NT, you don't use User Manager to enable auditing in Win2K. In fact, User Manager doesn’t work in Win2K domains. Instead, you use the Active Directory (AD) Group Policy to enable auditing. For information on Group Policy and Win2K's configuration process, see my column "Group Policy".

To view Win2K's nine audit categories, go to Active Directory Users and Computers, open a Group Policy Object (GPO), and maneuver to Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy, as Figure 1 shows. As in NT, you can configure each category to record successful and unsuccessful events. Remember that whenever you modify a GPO, your configuration changes will apply to all computers in the organizational units (OUs), domain, or sites that you've linked to that GPO. For instance, if you change audit policy in the Default Domain Policy GPO, which links to the root of the domain, Win2K will apply that same audit policy to every computer in the domain unless a higher priority GPO or a GPO linked to a lower OU has a conflicting audit policy. Remember, the last policy applied wins.

Updated Audit Categories
As Figure 1 shows, Win2K has nine audit categories, including NT's original seven, although some of the names have changed. Let's start by looking at the seven categories you're already familiar with and see how they've changed in Win2K.

First, Audit account management is the same as NT's User and Group Management. This category lets you track the creation, changes, and deletions of users and groups. Second, Audit logon events, which is the same as NT's Logon and Logoff category, records whenever a user attempts to log on to a system, either interactively or over the network. This category also records failed and successful logons and logoffs. Don’t confuse this category with Audit account logon events, one of Win2K's new audit categories.

Third, Audit object access is the same as NT's File and Object Access. This category lets you track access to files, directories, Registry keys, and printers. Remember that object auditing is a two-level activation. You must activate this auditing at the system level and also for the specific objects that you want to audit. To enable auditing for an object, such as a file, open the file’s Properties dialog box from Explorer, click the Security tab, click Advanced, and click the Auditing tab to open the Access Control Settings dialog box, as Figure 2 shows. From this dialog box, you define which users and which types of access to audit for the object. Fourth, Audit policy changes corresponds to NT's Security Policy Changes. This category lets you track changes to the system’s audit policy and rights assignments.

Fifth, Audit privilege use is the same category as NT's Use of User Rights. With this category, you can identify any time a user right is exercised successfully or when someone unsuccessfully tries to use a right that you have not assigned to that user. Sixth, Audit process tracking (same name in NT) lets you monitor each program that executes on the system and how long the program ran. Seventh, Audit system events corresponds to NT's Restart, Shutdown and System. This category lets you monitor when someone boots the system or clears the event log.

New Audit Categories
In addition to the seven updated NT audit categories, Win2K includes two new categories. The first of these, Audit account logon events, fills an important hole in NT's logon monitoring coverage. Tracking logon and logoff activity for domain accounts is problematic with NT because the Logon and Logoff audit category applies more to workstations and member servers than to domain controllers. When you log on at your workstation with a domain account, you are not logging on to the domain controller—the domain controller is just authenticating you. The logon event occurs on your workstation, and NT records the event in your workstation’s security log. Likewise, when you map a drive to a server, you’re logging on to the server, so NT records a logon event in the server's security log. This type of monitoring led to a fractious record of logon activity scattered among all the systems in the domain. To solve this problem, Win2K provides another category of audit events, Audit account logon events, to catch logon activity at a more centralized point—the domain controllers. Using this category, the system traps the domain controller authentication, as opposed to the logon that occurs at the workstation or server. This category watches the domain controllers and records any time a user authenticates or fails to authenticate because of a bad password. With this new category, you can get a complete picture of domain account logon activity by simply looking at the security logs for your domain controllers.

Win2K's other new audit category, Audit directory service access, is similar to Audit object access, only it applies to AD objects instead. Remember that in Win2K, user accounts and groups are objects in AD. As such, they have security descriptors (including an owner, access control list—ACL, and system audit control list) like any object. If you look at the Advanced Security dialog box for a user object in Active Directory Users and Computers, you’ll see an Auditing tab just as you would for any file or directory. With the system audit control list, you can specify exactly which properties and actions you want to audit on that object. For instance, you can specify that you want to audit whenever someone changes the dial-in settings for a user account. This information is valuable because it lets you track exactly what has changed on a user or group. In addition, the information is much more granular than what the Audit account management category gives you (the Audit account management category simply reports that a user or group changed—not what properties of the object changed). With Audit directory service access, you can find out exactly which properties changed. For instance, when an administrator edits Jill’s user account, you’ll know whether the administrator changed her job title or reset her password.

Win2K preserves all of NT's auditing functionality and offers some exciting new capabilities. Don’t forget that Group Policy now controls audit policy. Try out the new Audit account logon category so that you can track logon activity in a more centralized manner.