To identify user account deletions, event ID 630 uses the same Target and Caller fields as event ID 642 uses. With an event ID 630, you also see two adjacent event ID 565 occurrences. The first event ID 565 lists the DN of the deleted account's OU. The second event ID 565 basically repeats event ID 630 (i.e., shows that the user account was deleted) but identifies the user by its user principal name (UPN) rather than by its display name.
Change to user-account status is another valuable user activity that the Audit account management category tracks. When Win2K locks a user account as a result of failed logon attempts, you'll find event ID 644 (user account locked out). The Target Account Name and Target Account ID identify which user account Win2K locked. The Caller Machine Name field lets you identify the computer from which the failed logon attempt originated. You should see several event ID 675 occurrences or event ID 681 occurrences preceding an event ID 644 in the Security log. Event ID 675 and event ID 681 are failed authentication events from the Audit account logon events category, which I discussed in "Audit Account Logon Events."
When Win2K logs event ID 644, you'll also see a redundant event ID 642 with the description User account locked. When a user account is enabled or disabled, Win2K logs only event ID 642 with the description Account enabled or Account disabled.
Tracking group maintenance is much simpler than tracking user-account maintenance. Because the Audit account management category provides distinct event numbers for each combination of operation (i.e., creation, deletion, member additions, member deletions, and general changes) and group scope (i.e., Universal, Global, and Local), the adjacent event IDs 565 are of little or no value in tracking group maintenance. The only exceptions are event ID 659, event ID 636, and event ID 641 because these events tell you that a group changed but don't tell you which properties changed; the adjacent event ID 565 does. When you change a group's scope or type (i.e., security or distribution), Win2K logs event ID 688 (group type changed); this event's description specifies exactly which options changed. (The event refers to security groups as security enabled and distribution groups as security disabled. You can use security groups for security purposes such as ACLs and rights assignments; you can use distribution groups only in email applications to send email to a collection of users.) For example, when you change a global security group to a universal distribution group, event ID 688 specifies Security Enabled Global Group Changed to Security Disabled Universal Group.
Tracking Policy Changes
Two policy areas in particular—Group Policy and domain account policy—need an audit trail. (For information about Group Policy and for details of the options I discuss in the following paragraph, see "Controlling Group Policy, Part 1," November 2000 and "Controlling Group Policy, Part 2," Winter 2000.)
Group Policy changes. Because Group Policy manages every aspect of Win2K security configuration, changes to Group Policy can have wide-ranging effects on the users and computers in your domain. You can use event ID 565 to trace changes to individual GPOs as well as changes to Group Policy options on OUs, sites, and domains. When you edit a GPO's policies (e.g., you change the security options under Computer Configuration, you enable restrictions under User Configuration), Win2K logs an event ID 565 in which the Object Type is groupPolicyContainer. Under Properties, this type of event, which Figure 6 shows, lists versionNumber as the Write Property. Event ID 565 can't tell you exactly what policies inside the GPO changed because these policies reside outside AD. When you disable a GPO's User Configuration or Computer Configuration sections, event ID 565 lists the Flags Property under the Properties field. When you flag a GPO as No override or Disabled, be aware that this change affects the OU, domain, or site to which the GPO links, rather than the GPO. Therefore, event ID 565's description lists the Object Type as organizationalUnit, domainDNS, or site and lists the updated property as gPOptions. When you change which GPOs link to an OU, domain, or site, event ID 565's description lists the object type accordingly and lists the updated property as gPLink. When an administrator changes a GPO's ACL, event ID 565 lists the object type as groupPolicyContainer, the object name as the GPO's DN, and Accesses as WRITE_DAC (which indicates an update to the discretionary ACL). A GPO's ACL not only controls who can edit the GPO but also limits which computers and users Win2K applies the GPO to. When an administrator delegates control of an OU, event ID 565 lists the object as an OU and the access type as WRITE_DAC.
Domain account policy changes. You need to track changes to domain account policy (i.e., password, lockout, and Kerberos policy) because these policies affect the security of your entire domain. You can configure these policies in any GPO that links to the root of the domain (under Computer Configuration, Windows Settings, Security Settings, Account policy). Because these settings are domain-level settings, changing them in GPOs that link to OUs and sites has no effect on the domain. Domain account policy should seldom change, and you can easily catch such changes because the Audit account management category provides yet another distinct event ID: event ID 643. When you change password or Kerberos policy, Win2K logs event ID 643 with the description Domain Policy Changed: Password Policy modified. If you change lockout policy, event ID 643's description reads Domain Policy Changed: Lockout Policy modified. However, the Caller User Name field doesn't identify which administrator changed the policy because you don't directly change domain policy; instead, you edit a GPO. The next time a DC refreshes Group Policy, the DC encounters the change and applies it to the DC's local configuration under the DC's authority. Therefore, if you notice that your domain policy has changed, you need to work backward in the log and look for changes to Group Policy to determine who made the change.
Reap the Rewards
When you understand how the Audit account management and Audit directory access categories relate to each other, you increase your ability to keep up with changes to your AD domain. Remember that Win2K logs these categories' events on the originating DC. (For example, if an administrator is connected to the Philly DC when he or she creates a user account, Win2K logs the events on Philly's local Security log.) Familiarize yourself with these categories and events and mine the wealth of information that awaits you in the Win2K Security log.
End of Article
<i>--Editors</i>
Editors June 19, 2001