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.)
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.
| Related Articles in Previous Issues |
|
This article is the third in Randy Franklin Smith's series about the Windows 2000 Security log. You can find similar information about the Windows NT Security log in Randy's previous series. For your convenience, we list articles from both series below. You can obtain these articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com. Win2K Security Log Articles "Audit Account Logon Events," March 2001, InstantDoc ID 19677 "Tracking Logon and Logoff Activity in Win2K," February 2001, InstantDoc ID 16430 NT Security Log Articles "Archiving and Analyzing the NT Security Log," August 2000, InstantDoc ID 9043 "Protecting the NT Security Log," July 2000, InstantDoc ID 8785 "Monitoring Privileges and Administrators in the NT Security Log," June 2000, InstantDoc ID 8696 "Interpreting the NT Security Log," April 2000, InstantDoc ID 8288 "Introducing the NT Security Log," March 2000, InstantDoc ID 8056 |
