How easy is it to track Group Policy changes using the event log?

Group Policy Objects contain the settings to control almost everything in Active Directory; including Sites, Domains, Organizational Units, Users, Groups, Computers and other objects. In large enterprises, multiple administrators manage objects centrally through the Group Policy Management Console (GPMC) from different computers in the domain. Often, users complain that their system settings have been changed without their knowledge.

Group Policy Auditing with Windows

Occasionally the IT team is responsible for these changes; however, it is possible that someone with the right to make changes in the Group Policy Management Console has altered settings for which there was no authorization. Changes in Group Policy Objects like these, that can often remain unknown to others, can create accountability issues. It is therefore very important to audit these changes to know who did what change, when and from which location

GPO Auditing is possible with Windows 2000 Server; however, it was always a bit noisy and did not provide granular levels of detail. In the latest versions of Windows Server, Microsoft introduced advanced auditing where users can granularly determine what to audit and what not to audit, thus creating a manageable number of logs.

Group Policy is used to perform numerous tasks; including configuring auditing and deciding what users can or cannot access. It is therefore necessary to monitor Group Policy changes. But how? Here, you will see the steps to enable Group Policy auditing in Active Directory.

How to enable auditing of Group Policy Objects

A Group Policy Object is stored in two parts – Group Policy Templates (defines the GPO template) and Group Policy Containers (an object in Active Directory pointing to GPO template). Group Policy Templates are stored in %sysroot%SYSVOL folder. The auditing of SYSVOL folder, Group Policy Container Objects and DS Objects has to be enabled in order to enable the Group Policy Objects.

How to enable auditing of DS objects

Perform the following steps to enable auditing of Directory Service Objects:

1. Launch Group Policy Management Console (GPMC) from the “Administrative Tools” in the “Start Menu”.

2. Go to Forest -> Domains -> Domain Controllers.

3. Right click “Default Domain Controllers Policy”, and click on “Edit” to access “Group Policy Management Editor” (GPMC Editor).

4. The GPMC Editor window opens up, in the editor window navigate to “Computer Configuration” -> “Policies” -> “Windows Settings” -> “Security Settings” -> “Advanced Audit Policy Configuration” -> “Audit Policies”.

5. Select “DS Access” in the Audit Policies. The following policies will be displayed in it.

I. Audit Directory Service Access

II. Audit Directory Service Changes

III. Audit Directory Service Replication

IV. Audit Detailed Directory Service Replication

1. One by one, double-click these policies, and enable their auditing for both “Success” and “Failure”.

2. Do the same steps to enable the auditing of “Object Access” -> “Audit File System” in “Advanced Audit Policy Configuration”.

How to enable auditing of Group Policy Container Objects

Perform the following steps to enable auditing of Group Policy Container Objects:

1. Launch the “ADSIEdit.msc”.

2. Go to the “ADSI Edit” and right-click on it, select “Connect to” option. Connect to the current domain controller (DC), which will appear with “Default Naming Context”.

3. Click “OK” to connect.

4. This will create a tree in the left panel. Double-click on the node of “Default naming Context”, and go to “DC=www, DC=domain, DC=com” -> “CN=System” -> “CN=Policies”.

5. Right-click the “CN=Policies”, and navigate go the “Properties”.

6. Select the “Security” tab, and click on the “Advanced” button to go to its “Advanced Security Settings”.

7. In the “Advanced Security Settings, go to the “Auditing” tab.

Figure 1: Advanced Security Settings for Policies

1. Click on the “Add” button to add the user for whom the auditing has to be enabled. The following window will appear.

Figure 2: Select User, Computer, Service Account, or Group

1. Enter the name of the user for which the auditing has to be enabled. Instead, you can type “Everyone” to audit the changes in Group Policies for all users.

2. Click on “Check Names” to confirm the username.

3. Click on “OK” to add the user. “Auditing Entry for Policies” dialog box opens up.

Figure 3: Auditing Entry for Policies

1. Choose the entries for which the specified user’s actions will be audited. Click “Full Control” for both “successful” and “failed” types of events.

2. Select the “Apply these auditing entries to objects and/or containers within this container only” checkbox to apply the changes to its child objects.

3. Click on “OK” to apply the auditing entries.

4. In the “Auditing” tab of Advanced Security Settings, click “Apply” and “OK”.

How to enable auditing of SYSVOL folder

Perform the following steps for auditing SYSVOL folder where the Group Policy Templates are stored:

1. Go to the %systemroot% folder in the “Windows Explorer”.

2. Locate the “SYSVOL” folder, right-click on it, and click on “Properties”.

3. Go to the “Security” tab and click “Advanced”. “Advanced Security Settings” for SYSVOL folder will be displayed.

4. Go to the “Auditing” tab, and click on the “Edit” button. The auditing settings will be displayed.

5. Use “Add” button to add a user for which the auditing has to be enabled.

6. Choose the auditing entries. You can choose to audit the files and sub-folders as well.

7. Click “OK” to complete the process.

Native Auditing of Group Policy Changes

After you have enabled GPO auditing by following the above steps, every change in the GPO will be captured and displayed in the Event Viewer. Go to “Start Menu” –> “Control Panel” –> “Administrative Tools” and double-click “Event Viewer” to access it. Here, search for a particular event IDs for Group Policy Changes.

For novice users, it is difficult to know which event IDs are relevant to Group Policy changes. In these situations, Microsoft Technet comes to the rescue. For example, the following link gives you the list of events pertaining to changes in Group Policies: https://technet.microsoft.com/en-us/library/cc749336(v=ws.10).aspx.

Given below are a few examples:

• Event ID Range: 4000–4007: This range covers events concerning Group Policy start events. These events are captured when a Group Policy processing instance begins.
• Event ID Range: 4016–4299: This range covers Component start events. This range of events are captured when a Group Policy component processing starts the task defined in the event.
• Event ID Range: 5000–5299: This range covers Component success events: These events appear in the event log when a Group Policy component successfully completes the task defined in the event.

The following image is an example of an event that shows a certain Group Policy Change. However, it is not clear which Group Policy was modified, when, by whom, and what the before and after values were.

Figure 4: Event captured after modifying a Group Policy

Drawbacks of Native Auditing of Group Policy Objects

Unclear Data

In the above image, the event has been shown in the Windows Event Viewer, but it is not clear which Group Policy was modified, when it was modified, by whom and what the before and after values were. If the record of all event IDs for Group Policy Changes is un-usable, it will be difficult to search for a particular required change in a large event pool.

Multiple Logs

The Event viewer displays multiple events for an action that can throw up an unmanageable number of logs. Additionally, the Event Viewer will display the captured events in a complex format and occasionally with less detail.

Space Consumption

Event logs are memory-mapped files. If you set the maximum log size to 1 GB, it means (1 GB x 4 =) 4 GB space will be captured by the Event Viewer. If you set the log size to lower numbers, only a few events will be monitored, because the events generated after reaching the log size will be either overwritten or archived.

If you have configured logs to be archived for long-term storage, all event logs will then be archived to “%system32%/winevt/logs”, and will continue to take space on primary drive. There are no automatic ways available to transfer these archived logs to a secondary or external drive.

No Predefined Reports

There are no inbuilt pre-defined audit reports. The workaround is to create huge Windows PowerShell scripts or use an existing template. This translates to creating multiple, complex scripts if you want to investigate something as simple as an account deletion event. If administrators want to check the event logs of all network computers in the primary domain controller, they need to configure subscriptions on the server and configure each computer separately in the network, which can be a complex and time consuming process.

How to solve these limitations?

LepideAuditor for Group Policy is an ideal solution for tracking Group Policy changes. You simply need to install the solution, add the domain that has to be audited and the solution can audit all computers in the network from that central console. It provides real-time audit reports to find out the who, what, when and where details of Group Policy changes and displays these changes on very visual 3-dimensional graphs. The “before” and “after” values of each Group Policy change is also shown to make Group policy auditing easier than ever.