Change events, on the other hand, can have important security implications, depending on which information about a user, group, or computer was changed. With a few exceptions, account management auditing provides only one change event ID for each object type; therefore, you can't tell what changed simply by the event ID—but, in some cases, the event details tell you more.
In general, for user accounts, account management auditing produces event ID 642 for any change made on the Account tab of a user object's Properties dialog box and provides specific text only for important security status changes such as disable or enable events. For example, if you change a user's description, you'll simply get an event ID 642 with the text User Account Changed but no further information. If you enable or disable an account, you get the same event ID 642 but with the additional information User Account Changed: Account Disabled. Having to look for more information in the event's details makes implementing automated monitoring or selective reporting more difficult; however, tools such as GFI Software's GFI LANguard Security Event Log Monitor (S.E.L.M.), NetIQ's AppManager Suite, and Microsoft Operations Manager (MOM) let you define rules and create reports based on event details.
Account management auditing does provide specific event IDs for a few user account changes. When someone with reset-password authority resets a user's password, you'll see event ID 628 (user account password set). When someone tries to change his or her own password, you'll encounter event ID 627 (change password attempt). After someone repeatedly attempts to log on with an invalid password, Windows 2000 Server locks out the account (assuming the domain has an account-lockout policy enabled) and produces event ID 644 (user account locked out).
You'll find frequent occurrences of event ID 643 (Domain Policy Changed: Password Policy modified), even if you haven't changed your password policy. This behavior is a bug in Win2K. Each time Win2K applies Group Policy, it doesn't check to see whether the new and old policies are actually different. It configures the password policy from the Default Domain Policy Group Policy Object (GPO), which triggers Win2K to report event ID 643. The bottom line is that you can ignore event ID 643.
Table 2 lists the specific event IDs that account management provides for adding members to and deleting them from each type of group list. Provided your organization grants users access to folders and other resources exclusively through groups, event IDs 632, 636, and 660 are extremely valuable because they let you track each instance of a user or group being granted new access. Figure 1 shows the details for an event that added a member to a universal group. The details report which group was affected (Target Account Name), who was added to the group (Member Name), and who performed the operation (Caller User Name). Given that information, you can follow up with the group's owner or through your support call tracking system to verify that the change is legitimate.
Directory Service Access Auditing
As you can see, account management auditing provides good information for tracking user, computer, and group maintenance, but what about monitoring other areas of AD such as changes to GPOs and organizational units (OUs)? This area is where directory service access auditing shows its value. Although a bit more obscure and cryptic, directory service access audit events give you extremely detailed information about every change that takes place in AD. Directory service access auditing reports just one event ID—event ID 565 (Object open). All the useful information is in this event's details. To turn on directory service access auditing, select Domain Controller Security Policy under Administrative Tools; maneuver to Security Settings, Local Policies, Audit Policy; double-click Audit directory service access; and select both Success and Failure.
You can use directory service access auditing to track Group Policy—related changes. The most basic Group Policy change you want to be aware of is when someone edits one or more of the policies that a GPO defines. Although no specific event ID exists for this situation, you can recognize it if you know what to look for. In AD's schema, GPOs have the object type groupPolicyContainer and a version property called versionNumber. Whenever someone edits a GPO, Win2K increments the version number. When computers throughout the domain reapply Group Policy, they compare the current version number of each GPO with the version number that was current the last time the computer applied the GPO. If the version numbers haven't changed, the computer doesn't reapply the GPOs and thus saves resources on the local computers as well as the domain controller (DC). You can detect changes to GPOs by finding event ID 565s that have the Object Type value groupPolicyContainer, the Accesses value Write Property, and a Write Property that includes versionNumber, as Figure 2 shows.
Notice that Win2K doesn't report the GPO display name that you're used to seeing in the Microsoft Management Console (MMC) Active Directory Users and Computers console. Instead, the event provides the object's X.500 distinguished name (DN). For example, in Figure 2, the Object Name is CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=ad,DC=local. The relevant information in a GPO's DN is the long string of characters at the beginning, which is the GPO's globally unique identifier (GUID). You can use the Active Directory Users and Computers snap-in to track a GPO from its display name to its GUID. For example, to obtain the GUID of the Default Domain Controllers Policy GPO, open the Properties dialog box for the Domain Controllers OU and select the Group Policy tab. In the list of GPOs, select Default Domain Controllers Policy, then click Properties. The GPO's GUID is displayed on the General tab in the Unique name field, as Figure 3 shows.
While you're looking at Figure 3, notice the Disable section, which lets you disable the GPO's Computer Configuration policy, User Configuration policy, or both. If someone selects one or both of the check boxes, Win2K stops applying all the associated policies, which could have a wide-reaching effect on computers and users in your domain. To detect when someone changes the status of either or both of these boxes on any GPO, you need to look for event ID 565 where Object Type is groupPolicyContainer and Properties is flags.
A final type of GPO change that you might monitor is a change to a GPO's ACL, which controls who can edit the GPO and which you can use to limit the users and computers the GPO applies to within the OU or domain to which the GPO is linked. (For more information about changing a GPO's ACL, see "Controlling Group Policy, Part 2," Winter 2000, http://www.winnetmag.com, InstantDoc ID 15886.) In this case, look for event ID 565 and Object Type groupPolicyContainer as usual, but the Accesses field should have the value WRITE_DAC (write access to discretionary ACL).
Register
