Audit Group Policy Changes

Auditing Group Policy changes is a good practice to apply to ensure no settings are removed or added that could affect end-user experience.

This should apply to every environment, as such it is equally important to track all changes made to Group Policy in a Citrix environment. Many large enterprise companies come with large IT teams, many of whom have the ability to work within Group Policy and do so frequently. With this in mind, it’s easy to lose track of the configurations that are made. A Group Policy system could start with ten settings, and end up with hundreds. How many of the settings implemented can be justified? How many settings are applied to all users when in theory not everyone needs it applied to them? How many settings are configured but never removed when no longer needed?

Microsoft and other third-party solutions exist such as AGMP (Advanced Group Policy Management) and Netwrix exist that all have ways to audit Group Policy. It is recommended to use these if you have the opportunity, but there is also a method for those of you who don’t have such tools at your disposal. The capabilities to monitor Group Policy changes come built-in to Windows Server. Whilst this method doesn’t tell you exactly what setting has changed, it does tell you when Group Policies are edited, deleted, linked, unlinked, created and by who – so it may well suit your needs.

♣ Enable Directory Service Changes
♣ Configure Group Policy Object Permissions using ADSIEdit
♣ Viewing Group Policy Audit Event Logs
♣ Configure Event Log Forwarding (Subscriptions)

Enable Directory Service Changes

Log on to a Domain Controller and launch the Group Policy Management Console. Edit the Default Domain Controllers Policy found under the Domain Controllers built-in Organizational Unit.

Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> DS Access -> Audit Directory Service Changes.

Check Configure the following audit events -> Success -> OK.

Configure Group Policy Object Permissions using ADSIEdit

Now on a Domain Controller, launch ADSI Edit as an administrator.

Connect to the Default naming context and browse to CN=System -> CN=Policies under your domain name. Right-click Policies and click Properties.

Click the Security tab followed by the Advanced button.

Click on the Auditing tab and then on Add.

Click Select a principal.

Enter Everyone and click OK.

Under Applied to select This object only.

Check the Create groupPolicyContainer objects permission and click OK.

Create a second permission entry for Everyone which applies to Descendant groupPolicyContainer objects.

Check Delete and Modify permissions. Do not click OK yet.

Also check Write versionNumber. Click OK.

Click OK.

Click OK.

Viewing Group Policy Audit Event Logs

The following Event Log ID’s are of interest:

• 5136 – Group Policy changes, value changes, links, unlinks.
• 5137 – Group Policy creations.
• 5141 – Group Policy deletions.

Now when a Group Policy object is created. Event ID 5137 is logged containing details of who created the Group Policy object and the fact an object was created.

The Event Log description also displays the Group Policy Object’s Unique ID – 73744FDF-xx.

Another Event ID 5136 is logged with the Sysvol Path where the Group Policy obect will be stored. The Unique ID is used in the path name.

SYSVOL shows the path directory.

The Unique ID explained earlier also shows against the GPO when using Group Policy Management Console. Also take note of the Computer version which is currently at value 0 since it has not been edited before.

Another Event ID 5136 is logged showing the version number with a value of 0.

The New Group Policy Object value is deleted to make way for the name that was actually given to the GPO.

And as expected the display name is updated with a value of NewGPO.

When a change is made to the NewGPO Group Policy object an Event ID 5136 is logged. The account that made the change is recorded along with the Unique ID that helps you identity which GPO was changed.

The version number is also increased to a value of 2.

That same value reflects within the Group Policy Management Console.

When a Group Policy Object is linked to an Organizational Unit, an Event ID 5136 is logged with information of the user who made the link.

The OU that the GPO was linked to is recorded including a gPLink display name.

There isn’t much difference when a GPO is unlinked. An Event ID 5136 is again logged, only the Type shows as Value Deleted, indicating that the GPO was unlinked from the UserOU OU.

When a GPO is deleted, an Event ID 5141 is logged with the Unique ID of the GPO that was deleted and the user who performed the deletion. With the events now being logged, it’s a good start to tracking and monitoring all Group Policy activity. Another thing I like to do is separate the useful information from the rest of the pack. You are probably aware that the Security log on any server contains thousands of entries, nevermind the Security log of a Domain Controller. One option we have and I recommend this is forwarding the Group Policy related Event Logs to a collector server.

Configure Event Log Forwarding (Subscriptions)

In this scenario, my source Event Log server, the domain controller is named dc.jgspiers.com and the collector, who is collecting the GPO related events is named collector.jgspiers.com. On your Domain Controller(s), run winrm qc. On Windows Server 2012 R2 and above this is already configured however you can run the command just to be sure.

On your collector server, run command wecutil qc.

Since the collector will be reading events from your Domain Controller, edit the Event Log Readers built-in group adding the collector server as a member of that group. The group can be found in Active Directory under the Builtin OU.

On the collector server, open up Event Viewer. Click on Subscriptions and then click Yes on the message to configure the Windows Event Collector Service.

Now right-click Subscriptions and click Create Subscription.

Enter a name and click Select Computers next to Collector initiated.

Click Add Domain Computers.

Add the source (Domain Controllers) and click Test. Once the test has passed click on OK.

Click Select Events.

Check Information. Under Event logs select Security and in the <All Event IDs> box enter 5136-5137, 5141. This ensures the collector only collects Event Logs that we care about. Click OK.

Click Advanced and take note of the firewall port that must be open between the endpoints. HTTPS can be configured if desired. Click OK and then OK again to complete the Subscription creation.

The Subscription will show as below on the collector server..

Before Security events will be collected, you must allow the NETWORK SERVICE account access to the Security log via permissions. Launch RegEdit on each Domain Controller and navigate to HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security. Double-click the CustomSD REG_SZ.

Append (A;;0x1;;;S-1-5-20) to the end of the value. S-1-5-20 is the SID of the NETWORK SERVICE account. Click OK.

After a short moment in time you should start to get forwarded events in relation to Group Policy changes in the Forwarded Events location of Event Viewer on the collector server.

You could create a PowerShell script to send an email and use this script in a Scheduled Task which executes upon event log creation. That way you’ll receive an email upon these alerts rather than having to go looking for them.