Mining the Win2K Security Log

Tracking changes in your domain has always been important. Tracking domain changes in Windows 2000 is more vital than ever, for a couple of reasons. First, during a Windows NT-to-Win2K migration, many organizations merge multiple NT domains into one Win2K Active Directory (AD) domain; you're more likely to lose track of events in that larger AD domain. Second, a big advantage of migrating to AD is Administrators' ability to delegate account management, password resets, and other tasks to the Help desk or to subadministrators. But with the delegation of authority comes the need to ensure the proper and careful use of that authority.

Using an AD domain increases your tracking needs, but Win2K gives you several ways to track activity that occurs in AD. The Audit account management and Audit directory access audit categories can help you monitor changes to user accounts, user groups, and policy in your Win2K AD domain as well as in workstations' and member servers' local SAMs.

Combining Forces
One user action can generate multiple events in the Security log. Each Audit account management and Audit directory access event reveals specific information, but neither category gives you an entire picture of a user's action. (Audit account management events supply distinct event IDs for each situation but don't always tell you what about the object changed; the Audit directory access event ID 565 identifies the accessed properties.) However, when you examine these events in relation to one other, you can recognize patterns that identify the higher-level user action. Together, these two categories give you the ability to track maintenance activity in AD.

You might be familiar with the Audit account management audit category, which tracks creations and deletions of and modifications to user accounts and groups. (Win2K and NT implement this category similarly.) This category uses a different event ID for every situation; Table 1 lists these event IDs and their meanings. This category is most useful when you activate it on domain controllers (DCs) to track changes to AD. However, you can also activate the category on workstations and member servers to track changes to the local SAM.

Note, though, that for most changes to user accounts and groups, Audit account management logs only that the object changed—not what that change was. For example, Figure 1 shows an event ID 642 that records a change to a user account. The Target Account Name, Target Domain, and Target Account ID fields identify the user account that changed. Caller User Name and Caller Domain identify who changed the account. You can use the information in the Caller Logon ID field in conjunction with an event ID 528 or event ID 540 to link this event to a logon session. (For information about these events and how they identify logon sessions, see "Audit Account Logon Events," March 2001; for a list of other Security log articles, see "Related Articles in Previous Issues.") However, you can't determine precisely what changed (e.g., whether the administrator changed the user's job title or the user's account restrictions).

Enter the Audit directory access audit category, which is new to Win2K and applies only to DCs. Each object in AD has an audit control list (not to be confused with an ACL) which specifies which types of access Win2K should record in the Security log. When you enable Audit directory access and someone accesses an AD object, Win2K looks at the object's audit control list to determine whether to report the access. When you disable Audit directory access, Win2K ignores audit control lists in AD. This category generates one event, event ID 565, for all situations.

Figure 2 shows the event ID 565 that Win2K logged for the same user-account change that generated the Audit account management event in Figure 1. The DS value in the Object Server field indicates that the directory service (i.e., AD) encountered the event. Object Type specifies the type of accessed AD object—a user, in this example. Object Name uses the Lightweight Directory Access Protocol (LDAP) distinguished name (DN) format to identify the accessed object. In this example, the accessed user account was John in the acme.com domain. You can use the Client User Name, Client Domain, and Client Logon ID fields to identify the user who changed the account (as you use the Caller User Name, Caller Domain, and Caller Logon ID fields in event ID 642). The first line of text under Properties shows that the type of access was a write operation to one or more properties. The remaining lines of text show that the changed property was displayName, meaning the user object's Display name field.

Event ID 565 shows you exactly which properties changed. Typically, property names are self-explanatory, but some names are difficult to identify because the property names in event ID 565 come directly from AD's schema. For example, if you change a user's last name, Win2K logs the event as a change to the sn property, where sn stands for surname. When you encounter a confusing property name, you can use the Microsoft Management Console (MMC) Active Directory Schema snap-in to get some hints as to the name's meaning. This snap-in isn't registered by default. Before you can use the snap-in, you need to open a command prompt, change to the \%system root%\system32 directory, and run the command

regsvr32 schmmgmt.dll 

The Active Directory Schema console's Description column displays the meaning of various objects' property names. For example, a user object's "l" property is the object's Locality-Name, as Figure 3 shows. (However, you then need to figure out that Locality-Name corresponds to the City field on the Address tab of the user object's Properties sheet; you can access that sheet from the MMC Active Directory Users and Computers snap-in.) Event ID 565's remaining fields aren't relevant to your task of tracking changes to user accounts or groups.

Depending on the type of change that occurs, Win2K might log both an Audit account management event and event ID 565 or only an event ID 565 because Audit account management isn't specific to AD. Rather, that account tracks user, group, and account policy changes that Win2K executes through SAM functions. On Win2K DCs, AD in effect replaces the SAM, so Win2K translates SAM updates into AD updates. To see the properties that these events hold in common, compare the properties on an AD user account (which you can view from the Active Directory Users and Computers console) to the subset of properties found on a SAM user account (which you can view under Local Users and Groups in the MMC Computer Management console). When you update a property that the SAM supports (e.g., a user's display name), Win2K logs both an account management event and event ID 565. However, when you update a property that only AD supports (e.g., a user's last name), Win2K logs only event ID 565.

To use these two audit categories to track changes to your domain, you need to activate the categories—for all the domain's DCs—in the Default Domain Controllers Policy Group Policy Object (GPO) linked to the Domain Controllers organizational unit (OU—for information about how to define audit policy in GPOs, see "Tracking Logon and Logoff Activity in Win2K," February 2001).

You don't need to edit the audit control list of individual AD objects because the default audit control list at the root of the domain audits all changes by default. To view this audit control list, open the Active Directory Users and Computers snap-in and select View, Advanced Features from the menu bar. Right-click your domain root, and click Properties. Go to the Security tab, click Advanced, then go to the Auditing tab, which Figure 4 shows. Click View/Edit to see all successful and failed modify operations.

By default, Win2K uses the Everyone group to track all modify operations—regardless of who performed them. If you want to track the actions of specific users, you can specify another group or user. Users, groups, and other AD objects automatically inherit the default audit control list unless you configure the list differently. Win2K applies the same inheritance model and options for audit control lists as it does for ACLs. To learn how ACL inheritance works and how to control it, see "NTFS Access Control Security Enhancements," May 2000, and apply the rules in that article to audit control lists.

Tracking User Account and User Group Maintenance
When someone creates a user account through the Active Directory Users and Computers snap-in, Win2K usually logs at least eight events. Although the sequence of these events can differ, the first event is usually event ID 565.

The event's Object Name lists the OU in which the user account was created and specifies Create Child as the access type. The Object Type field displays the type of created object (i.e., a user). However, event ID 565 doesn't specify the name of the created child object. Win2K also logs account management event ID 624 (user account created), which does specify the display name of the newly created user account.

After you create the user account, the Active Directory Users and Computers snap-in immediately sets various options on the account. These changes generate a variable number of occurrences of event ID 642 (user account changed), which don't specify which properties changed. You'll see an equal number of event ID 565 occurrences, which do list the changed properties. The quantity of the event ID 565 and event ID 642 pairs depends on which options you selected when you created the user account.

Another account management event that you encounter when you create user accounts is event ID 627 (change password attempt). When event ID 627 immediately follows a user account creation, the event simply represents the specification of the initial password that you created for the account. At all other times, event ID 627 is useful for tracking password changes. The Target Account Name, Target Domain, and Target Account ID fields identify the user whose password was reset. The Caller User Name and Caller Domain identify who changed the password. You can use Logon ID to connect this password reset to a corresponding logon event ID 528 or event ID 540. If the Target Account Name and Caller User Name match, you can conclude that the user changed his or her own password. Otherwise, the event means that someone else with password-reset authority changed the user's password. By monitoring event ID 627 occurrences, you can monitor Help desk personnel and others who reset forgotten passwords.

To track general user-account maintenance activities such as changes to users' addresses, organizational data, or account restrictions, look for an event ID 642 that doesn't occur directly after (i.e., within about 1 second after) a user account creation (i.e., event ID 624). Event ID 642 simply informs you that the user account changed and who changed the account. To find out which fields changed, look for adjacent event ID 565 occurrences and note the properties that appear in the descriptions. (AD contains all user Account options, which Figure 5 shows, in one property called userAccountControl. Therefore, when you see this property, any of these options might have changed.)

   Previous  [1]  2  Next