There’s no doubt that the built-in security auditing in Windows is thorough–sometimes too thorough, as anyone who has tried to manage auditing logs in large AD environments knows. But when it comes to auditing Group Policy changes, the native auditing can be lacking. It’s why we built our Group Policy Auditing & Attestation (GPAA) product last year–to make sense out of Group Policy changes that happen within your environment in a way that is meaningful to Group Policy administrators. In this post, I want to talk about what Windows does and doesn’t do for you, when it comes to Group Policy change auditing. The big thing to note about native Windows auditing and Group Policy is that, when it comes to auditing changes to GPO settings, there is, literally, nothing available in the box. That is, if you make a change to a GPO setting, there is no native way of determining what that change was in any meaningful way. You’ll be able to tell that *something* has changed, but not what the changed setting was, nor its before or after values. That’s where a product like GPAA comes into play. GPAA can show you, not only who made the change and when, but also what the actual setting change was, as shown in this figure:

Capturing GPO Settings Changes with GPAA

In addition, other types of operations related to Group Policy management do generate audit events, but it takes a bit of work to make sense of them. In this article I want to describe what exactly you can audit natively, when it comes to GP management, and what you can’t. And, show you how GPAA can make the whole process much easier. But first, lets talk about the best way to configure auditing for your AD environment.

Windows Auditing Options

The first thing to know, is that there is “legacy” auditing and then there is “advanced” auditing, within Windows server. Legacy auditing has existed since Windows 2000, and contains a set of coarse-grained audit categories that you can enable, as shown in this figure of audit configuration within a Group Policy Object:

Legacy Audit Categories

The downside to using these audit categories, is that they are pretty darn noisy. That is, if you enable even a few of them on your AD domain controllers, you are likely to get your security logs rolling over pretty quickly in a reasonably large environment. This is because within each of these coarse categories, are a number of sub-category event types that are audited and you have no control over which of those you get when you enable a particular category–you get them all. So unless you have a really good event log collection system, you may end up missing events as the logs roll over. I’ve seen security logs in large organizations completely roll over in a matter of 15-20 minutes, and that’s with making the security log file size reasonably large. So, what can you do?

Fortunately, when Server 2008 shipped, Microsoft introduced “Advanced Audit Configuration”. This advanced auditing capability gave you the ability to turn on and off, all of those sub-categories within the legacy audit categories, so that you could audit just what you needed, and no more. In Server 2008, you could set these audit sub-categories on your Domain Controllers using the command-line auditpol.exe tool. But, starting in Server 2008-R2, Microsoft added these options to Group Policy, so that you could easily and graphically configure these advanced audit categories, as shown in the figure below:

Advanced Auditing Configuration in Group Policy

You’ll notice that under each major category on the left, in the screenshot above, there are sub-categories that can be enabled or disabled for auditing. So, for example, under Directory Service Access (DS Access), you can enable auditing for everything from AD replication events to accessing AD. For the purposes of tracking changes made to AD, which is what we’re interested in for Group Policy change auditing, you can enable the Directory Service Changes sub-category, and in fact this is the category of events GPAA uses to track the who, what, when and why of AD changes related to Group Policy.

The one thing to note about enabling these advanced audit configuration categories on your domain controllers, is that you have to also tell AD to ignore the legacy auditing categories, if you plan to keep them enabled as well. You can do that by enabling the policy on your DCs, within a GPO under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Once that policy is enabled, then all legacy events categories will be ignored and only advanced audit categories will be logged to the DC’s security event logs.

Configuring AD for Group Policy Change Auditing

In order to get events related to AD changes, you have to do two basic tasks. The first is that you have to enable auditing for AD changes, as I just described above. The second task is that AD objects that you’re interested in auditing changes against, must have their System Access Control Lists (SACLs) configured to enable auditing. By default, Server 2008 does many of these tasks for you, as it relates to Group Policy changes, out of the box. If we take the whole universe of things that can be audited as it relates to Group Policy management, then only deletion of GPOs and the creation and deletion of WMI filters require additional SACLs being put in place to generate audit events.

Once the Directory Service Changes auditing sub-category is enabled on your DCs, and SACLs are configured, then you can start to look at all of the changes that occur in AD related to Group Policy management. AD change events generated by this sub-category generally fall into one of three event IDs:

5136- Changes to AD objects

5137- Creation of new AD objects

5141- Deletion of existing AD objects

And since GPOs are just a special kind of AD object, it follows that creation, deletion and modification of GPOs also generate events of these event IDs. There’s a few things to keep in mind about GPO change events. First, all changes related to GPOs (e.g. creation, deletion, modification) happen within the CN=Policies, CN=System container under a given AD domain (see figure below)

GPO Storage in AD

So when it comes to auditing changes to GPOs, it all happens within this container. As you can see from the screenshot above, that container holds a set of GUID-named GPO containers (of AD object class groupPolicyContainer) that represent each GPO in the domain. Now, creating, deleting or changing GPOs is not the only GP management operation you will be interested in auditing. You will also want to know when GPOs are linked or unlinked from a site, domain or OU. Those actions require auditing of changes (i.e. writes) to the GPLink attribute on those container objects (which is also a default SACL in newer versions of Windows) . In addition, you may want to know when WMI filters are created, modified or deleted. Those occur as creation modification or deletion events against objects under the CN=SOM, CN=WMI Policy,CN=System container within a given AD domain, which is where WMI filters are stored.

Auditing Group Policy Changes

Now that we have an idea about what kinds of GP related stuff we can audit using Windows native auditing, let’s take a look at what events are generated for each type of GP management activity. The following table lays out a  variety of GP management tasks, the event IDs to look for and sample event text from that event operation within, in this case, a Windows Server 2008-R2 DC. Within the sample event column, I show the raw event log entry of an event that gets thrown when that GP operation occurs. In red I highlight the class or attribute that is modified, created or deleted when the task is performed. There’s a couple of things to note in this table. First off, the Change GPO event relates to changes that you make to a GPO. They could be a GPO permission change or a GPO settings change. In the case of the former, you will be able to use the data provided in the event log (namely the change of the ntSecurityDescriptor attribute) to determine the actual GPO permission change. Unfortunately, in the case of a GPO setting change, you won’t see any detail around the actual settings that were changed–you will only see that *something* changed in the GPO, who made the change and that it’s versionNumber was incremented. The before and after values of the actual settings change are one of the things that GPAA fills in, as I discussed above.

In addition, when it comes to making sense of the audit events below, it does require a bit of work. For example, a GPO permission change does record two events–one the before value of the ntSecurityDescriptor attribute on the groupPolicyContainer (GPC) object representing the GPO, and one with the after value. But the data in the audit entry is in the form of the Security Descriptor Definition Language (SDDL), so you’ll have to know how to translate that value in a readable format. In addition, for things like changing or disabling a GPO Link, the audit log reports the before and after values of the gpLink attribute on a given OU, site or Domain container, but it doesn’t tell you what those values (e.g. 0, 1 and 2) mean. All of this is where GPAA can come in handy, because it can take the data out of the raw events and make sense of it in the context of Group Policy changes.

The bottom line for Group Policy Change Auditing, is that while the native audit logs can definitely get you information about some of the changes related to Group Policy within your environment, a product like GPAA can really help make sense of the data as it comes in, and sift through the myriad of values, flags, codes and just downright missing information, that can arise when you are parsing through this data.

Thanks for reading!

Darren