Auditing policy changes misunderstanding

Reading Time: 3 minutes

This topic is probably familiar for most of peoples who are playing with Windows systems for a while, but maybe some newbie will get here so here’s the post. Today I responded in some thread on Polish web portal regarding how to audit changes in GPOs and why audit policy changes setting is not doing this as it should be?
The answer to the second part of question is simple – audit policy changes setting is not supposed to audit changes made by someone to GPO itself. It enables auditing of successes or failed (depends on configuration) attempts to apply changes to system policy configuration, being result of changes made to the policy which is affecting this system.
To be more specific this will reflect with appropriate event in security log changes made to user rights assignment policies, audit policies, or trust policies. That’s it. You should not look for events containing information who made what changes to particular GPO.

But first part of a question still remains unanswered – how to audit changes being made by someone to particular GPO? First of all – be sure that only users who really needs to make these changes are allowed to do this. Security settings at your GPO are the way You can restrict this rights. But on some occasions You want to know who changed what in specific moment in time.

The answer is, unfortunately, that there is no such built in mechanism in Windows system which will allow You to gather such data. What we can catch is information that someone made some changes to policy, but not what changes was being made.
How to audit events related to changing policy? This can be done by enabling directory object access audit category (for success, failure or both) and setting appropriate SACL (auditing of Write Property) on GPO object in directory itself. As a result of such configuration we will see events with ID 566 for successful object update as presented below:

Event Type: Success Audit
Event Source: Security
Event Category: Directory Service Access
Event ID: 566
Date: 8/17/2006
Time: 9:12:19 PM
User: W2K\Administrator
Computer: ROOTDC
Object Operation:
Object Server: DS
Operation Type: Object Access
Object Type: groupPolicyContainer
Object Name:
Handle ID:
Primary User Name: ROOTDC$
Primary Domain: W2K
Primary Logon ID: (0x0,0x3E7)
Client User Name: Administrator
Client Domain: W2K
Client Logon ID: (0x0,0xBF136)
Accesses: Write Property

Write Property
Default property set

Additional Info:
Additional Info2:
Access Mask: 0x20

GPO is made of two parts – directory part, which stores GPO directory objects and lets us assign this to containers in directory and files which are stored on SYSVOL volume. If we want to audit also this file part we may use object level auditing to audit access to these files. But … auditing may have strong impact on system performance if many events will be generated from it, and with many events meaningful information is easier to miss in this data. So we have to be very carefully when we choose to set some SACLs on GPO files. I think that this may be useful only when we have some suspects and we want to track their actions in system or to track failed events when somebody wanted to access GPO file and has been rejected.

So … we know that change was made, and who made this – we still don’t know what was changed, and unfortunately with standard Windows tools we are not able to get this information.
Such functionality is available only in third party tools like NetPro’s products. What we can do is that we can put in place some process of GPOs documentation using GPMC on regular basis or after some changes being made. Then we can use it to compare content of GPO at the last time that report was generated and after the change being made. Not perfect solution but always something that we can use.

So that’s all for now about auditing.