Mystical GPO change

We are monitoring changes on critical AD objects by event ID 4662. It usually does a good job reporting who initiated the change. Today we have an alert as below:

An operation was performed on an object.
Subject : Security ID: SYSTEM Account Name: DC1$ Account Domain: john.com Logon ID: 0x76AB862E
Object: Object Server: DS Object Type: groupPolicyContainer Object Name: CN={xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx},CN=Policies,CN=System,DC=john,DC=com Handle ID: 0x0
Operation: Operation Type: Object Access Accesses: Write Property

This is a normal event 4662 except that the subject is "System" of DC1. Why would the system account change a GPO? 

Turns out that this is our Default Domain Controllers Policy. There wasn't a direct edit to the GPO. Rather, logon credential for a service on this DC was changed, which in turn added the new service account to "logon as service".

How to track any attribute change

1. Assumption #1: DS Access enabled in Group Policy
2. Assumption #2: audit is enabled on the obejct you want to track ( SACL entries)
3. run "repadm /showobjmeta DCName DN_of_object"
4. Check the change time and origin DC of the attribute
5. Check event id 4662 for that time point on the origin DC
6. You may see several 4662 events
7. You should see Subject, Object, and Operation info in the event, and look for operation type "Write Property"
8. In "properties" section, it list only GUID of the property, so you will have to match it up to AD schema here
9. Obviously step 8 is near to impossible as there are a few hundreds attributes and you don't want to check them one by one
10. So you can also just search the GUID from schema context. The query string will look like something like this "schemaIDGUID=#($U@()&%)@" BUT YOU CANNOT USE THE GUID FROM THE EVENT VIREW! You have to convert it first
11. How to convert a GUID reported in event viewer to a LDAP query filter: this page. Life is hard, isn't it?!