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?!

Using LDP.exe to restore deleted AD objects

The whole process is described here, however, what the article failed to mention:

• you must use LDAPS to connect to AD

• When type in new DN, make sure you type in CN portion as well. Most people tend to copy only OU path

• You need to connect to AD using a user account in local domain, otherwise you won't be see any object under "Deleted Objects" OU

To restore a deleted Active Directory object using Ldp.exe

1. Open Ldp.exe from an elevated command prompt. Open a command prompt (Cmd.exe) as an administrator. To open a command prompt as an administrator, click Start. In Start Search, type Command Prompt. At the top of the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, enter the appropriate credentials (if requested), confirm that the action it displays is what you want, and then click Continue.
2. To connect and bind to the server that hosts the forest root domain of your AD DS environment, under Connections, click Connect, and then click Bind.
3. On the Options menu, click Controls.
4. In the Controls dialog box, expand the Load Predefined drop-down list, click Return Deleted Objects, and then click OK.
5. In the console tree, navigate to the CN=Deleted Objects container.
6. Locate and right-click the deleted Active Directory object that you want to restore, and then click Modify.
7. In the Modify dialog box:
   1. In Edit Entry Attribute, type isDeleted.
      
   2. Leave the Values box empty.
      
   3. Under Operation, click Delete, and then click Enter.
      
   4. In Edit Entry Attribute, type distinguishedName.
      
   5. In Values, type the original distinguished name (also known as DN) of this Active Directory object.
      
   6. Under Operation, click Replace.
      
   7. Make sure that the Extended check box is selected, click Enter, and then click Run.