Tracking Group Policy Changes: Part 1

Following my earlier blog post, Unauthorized Use of Windows Administration Tools Use Case, one of our readers asked about methods for monitoring changes made to group policies. LogRhythm has built-in processing policies for almost any log imaginable in Windows and Active Directory, so let’s take a look and see what we can find.

Disclaimer: Please get comfortable with auditing in the lab before touching a production environment.

Microsoft offers a variety of auditing options—one of which is Directory Service. Within this audit category, you can choose which particular activities you are interested in. There are four options:

  • Directory Service Changes
  • Directory Service Replication
  • Detailed Directory Service Replication
  • Directory Service Access

The one we are interested in is “Directory Service Changes.” This policy allows you to audit events generated by changes to objects in Active Directory. “Changes” include Modify, Create, Undeleted, Move and Delete, represented in Windows 2008 and 2008 R2 by Events IDs 5136, 5137, 5138, 5139 and 5141, respectively. (See https://technet.microsoft.com/en-us/library/dd772641.aspx.)

As you know, the auditing option is one half of the story. You need the matching SACLs on the objects you wish to audit in order for the audit policy to tell you anything. Active Directory has SACLs enabled for a minimum number of actions by default. In my default deployment of AD, it looked like this:

Figure 1. Default Deployment of Active Directory Figure 1: Default Deployment of Active Directory

So the default configuration would give us visibility of Group Policy Objects (GPOs) being created, modified and linked, but not being deleted.

There is a great TechNet article on the subject of configuring AD Object Auditing that I strongly recommend that you read if you can.

Following the above blog’s guidance, I just added the “EVERYONE > DELETE > Descendent Group Policy Container objects” for the purposes of this demonstration, because deletion of GPOs is pretty important to me too!

To test this functionality, I edited the Minimum Password Length under Computer Configuration — Windows Settings — Security Settings — Account Policies. It started out “Not Defined,” and I changed it to a value of 2.

Figure 2. Minimum Password Length Properties Figure 2. Minimum Password Length Properties

Four logs of type 5136 are generated in the Windows Event log as a result:

Figure 3. Four 5136-Type Logs Generated in the Windows Event Log Figure 3. Four 5136-Type Logs Generated

Let’s take a closer look at one of these events:

Figure 4. 5136 Event Properties Figure 4. 5136 Event Properties

The User ID made the change, and the domain name of that user are provided—along with a reference to the Object. Unfortunately, the policy name is provided as a globally unique identifier (GUID) in the log, so we will need to resolve it to a name. To get the Policy name from the GUID in this log, run the following command in PowerShell:

(New-Object DirectoryServices.DirectorySearcher -Property @{Filter = ‘CN={6AC1786C-016F-11D2-945F-00C04FB984F9}’}).FindOne().properties.displayname

Or, more simply:

(([adsisearcher]”CN={6AC1786C-016F-11D2-945F-00C04FB984F9}”).findone()).properties.displayname

This returns the string “Default Domain Controllers Policy,” which is the name of the policy I edited.

“{6AC1786C-016F-11D2-945F-00C04FB984F9}” is, in fact, a well-known GUID, but when you create your own GPOs, they will have unique GUIDs in your environment.

Each time a Group Policy setting is changed, four logs are created within the EventLog: two pairs of two logs with each pair linked by a correlation ID and that consists of a Value Deleted and Value Added entry. So it looks like AD is recording the fact that an old value existed and has been removed and a new value has been added in its place.

AD DS Auditing does not record the actual values that are changed—only the fact that a value has been changed. You will need a third-party tool if you want to record the actual changes.

When a Policy is linked to an OU, the same Event ID 5136 is generated, with slightly different information:

Figure 5. Updated 5136 Event Properties Figure 5. Updated 5136 Event Properties

Here, you can see the name of the OU that the policy was linked to and the GUID of the Policy that was linked.

Finally, I wanted to test creating and deleting a policy:

Figure 6. New GPO Figure 6. Testing a new GPO

Creating a new policy resulted in six new log entries—one of type 5137, which records the initial creation of the new policy—and five more type 5136 setting various elements of the new policy.

Figure 7. Creating a New Policy Resulted in 6 New Log Entries Figure 7. Creating a New Policy Resulted in 6 New Log Entries

I then deleted it, and the 5141 Event was generated as expected:

Figure 8. 5141 Event Figure 8. 5141 Event

So what can we do with all of these logs? Part 2 of this blog series will show how LogRhythm can consume these logs to provide visibility and alerting.