If someone deletes a GPO, you'll see event ID 565 with the Object Type groupPolicyContainer, an Object Name that begins with CN=Policies,CN=System, and an Accesses value of Delete Child. The same event ID with the same Object Type and the same opening phrase for the Object Name but whose Accesses value is Create Child instead of Delete Child tells you that someone created a new GPO. Unfortunately, neither event specifies the GUID or display name of the GPO.
The other area of Group Policy—related changes that warrants monitoring is changes to Group Policy—related properties on an OU. As Figure 4 shows, each OU has a list of GPOs that are linked to it; each linked GPO has two options, No Override and Disabled; and the OU has a Group Policy—related Block Policy inheritance check box. If someone links or unlinks a GPO or selects or clears any of the other options, the change can have wide-reaching effects on the computers and users contained in that OU. To detect changes to an OU's list of linked GPOs, changes in the No Override or Disabled options for a GPO link, or changes to the Block Policy inheritance value, look for event ID 565 with an Object Type value of organizationalUnit and the Write Property values gPOptions and gPLink, as Figure 5 shows.
GPOs can also be linked to domains or to sites. To detect Group Policy—related changes to a domain or site, look for event ID 565 where the Object Type is domainDNS or site and the Write Property values are gPLink and gPOptions.
To keep tabs on how administrative authority and other AD permissions are being modified, you can monitor for changes to OU ACLs. The event details you look for are similar to those I described earlier for GPO ACLs. When you see event ID 565, Object Type organizationalUnit and Accesses WRITE_DAC, you know that someone changed the permissions on that OU. The Object Name field plainly reports the OU's DN.
You can detect new OU creation by looking for event ID 565 where Object Type is organizationalUnit and Accesses is Create Child. On such an event, Object Name specifies the parent OU, not the name of the new OU. Deletion events have the same event details except that the Accesses value is Delete Child instead of Create Child.
You can detect site-related changes by looking for event ID 565 where Object Type is site, siteLink, siteLinkBridge, subnet, nTDSSiteSettings, or serversContainer. Changes to replication between DCs show up as event ID 565 with Object Type nTDSConnection or nTDSSiteSettings. To monitor trust relationship changes, look for event ID 565 with Object Type trustedDomain, which Win2K uses for both trusted and trusting domains. If you have one or more enterprise Certificate Authorities (CAs) set up in your domain, you can monitor changes to certificate templates, the CAs themselves, and certificate revocation lists (CRLs) by looking for Object Type pKICertificateTemplate, pKIEnrollmentService, certificationAuthority, or cRLDistributionPoint.
Searching the Security Log
Account management and directory service access auditing truly provide the information you need to stay on top of AD changes. The details are in the Security log, but how do you find them? Manually searching through each event is obviously not an option. For ad hoc searches, you can use Event Viewer's find feature. Open Event Viewer, right-click the Security log, and select View/Find. As Figure 6 shows, you can specify the event ID and enter in the Description field text that you want Event Viewer to search for in the details of the found events.
For any kind of regular monitoring, you need a more sophisticated tool. For example, you could use the Microsoft Windows 2000 Resource Kit's dumpel.exe utility, which you can also download from http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/dumpel-o.asp. You can use Dumpel to filter on event number—but not on event details, which Dumpel refers to as strings. You can use the Findstr command to further filter events such as event ID 565 based on the contents of their strings.
Unfortunately, though, Win2K logs schema attributes' GUID rather than their display name in the Security log, and Dumpel doesn't translate the GUID into the name. Therefore, when you dump event ID 565, you get something that looks like the results that Figure 7 shows. To decipher these results, you can use the Win2K AD schema documentation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/windows_2000_schema.asp. If you browse that site, you can verify that bf967aa5-0de6-11d0-a285-00aa003049e2 is the schema GUID for organizational-Unit and f30e3bbe-9ff0-11d1-b603-0000f80367c1 and f30e3bbf-9ff0-11d1-b603-0000f80367c1 are the GUIDs for gPLink and gPOptions. With this information in hand, you could use the sample commands
dumpel -l security -t
-format Idtus -m security
-e 565 > events.txt
findstr "bf967aa5-0de6-11d0-
a285-00aa003049e2" events.txt
to get a list of all event ID 565 events in which the object type is organizationalUnit.
As you can see, if you know what to look for, you can stay well informed about what's going on in AD—or at least be able to figure out what happened and who did it when a problem arises. Remember that you need to enable Audit account management and Audit directory service access in your Default Domain Controllers Policy GPO, and you must check each DC to get a complete record of activity in the domain. Happy Security log hunting!
Register
