Monitoring Group Policy Changes with Windows Auditing

  • Article

I spent some time a while back analyzing logs, figuring out what you can do with group policy auditing on Windows Server 2003. I did not test Windows 2000; I suspect that much of this applies but YMMV.

GP editing does leave an auditable trail of directory accesses and file accesses. Here is how to enable auditing for Group Policy, and how to interpret the results.

  • To get the audit trail from AD, you must do the following:
    • Using AD Users and Computers, create an auditing ACE in the SACL as follows:
      • Object to set SACL on: domain (ex: contoso.com)
      • Principal: everyone
      • Type: success
      • Accesses: Create groupPolicyContainer Object, Delete groupPolicyContainer Object
      • Scope: This container and all sub-containers and objects
    • Using AD Users and Computers, create an auditing ACE in a SACL as follows:
      • Object to set SACL on: domain (ex: contoso.com)
      • Principal: everyone
      • Type: success
      • Accesses: all "write" type accesses including deletes, but no "read" type accesses
      • Scope: groupPolicyContainer objects
    • Enable Directory Service Access Success auditing in the Default Domain Controllers Policy.
  • To get the audit trail from the file system, you must do the following:
    • Using Explorer, navigate to: \\<domainname>\sysvol\<domainfqdn>
      (ex: \\contoso\sysvol\contoso.com)
    • Set the following SACL on the \policies directory in that location
      • Directory to set SACL on: \\<domainname>\sysvol\<domainfqdn>\policies
      • Principal: everyone
      • Type: success
      • Accesses: all "Write" accessess, but no "Read" accesses.
        Note: Do not audit Write Attributes or Write Extended Attributes
      • Scope: This container and all sub-containers and objects
    • Enable Object Access Success auditing in the Default Domain Controllers Policy.

Here are the Audit records that are generated if you do this. The fields to pay special attention to are underlined. My comments are in red.

  • DS Access audit records.
    Whenever GPEdit.msc is opened when targeted at an existing group policy object,
    an audit record similar to the following will be generated. I have added notes in red,
    these don't appear in the log.

Type: Audit Success
Event ID: 566
Time: 4/3/2005 7:39:13 PM
Source: Security
Computer: ACSDEMO-COLL
Category: Directory Service Access
User: CONTOSO\Administrator
Description:
Object Operation:
Object Server: DS
Operation Type: Object Access
Object Type: %{f30e3bc2-9ff0-11d1-b603-0000f80367c1} (this GUID means that the object is of type groupPolicyObject)
Object Name: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com
(policy objects are always have GUIDs for common names- use GPMC to find the friendly name)
(the Default Domain policy and Default Domain Controllers policy have well-known GUIDs; all others are random)
Handle ID: -
Primary User Name: ACSDEMO-COLL$ (primary user is always the machine, since DS runs as localsystem)
Primary Domain: CONTOSO
Primary Logon ID: (0x0,0x3E7)
Client User Name: Administrator (client user is the user who made the change, being impersonated by DS)
Client Domain: CONTOSO
Client Logon ID: (0x0,0x2F6C8)
Accesses: Write Property
Properties: Write Property
%{771727b1-31b8-4cdf-ae62-4fe39fadf89e}
%{bf967a76-0de6-11d0-a285-00aa003049e2}
%{f30e3bc2-9ff0-11d1-b603-0000f80367c1}
Additional Info:
Additional Info2:
Access Mask: 0x20

  • Variations on DS Access Events
    • For creation of group policy objects, event 566 is logged for the parent object, indicating the "Create Child" access, and one or more 566 events are generated for the new group policy container object as the objects' properties are initialized.
    • For deletion of group policy objects, event 566 is logged for the policy object, indicating the "Delete" access.
  • File Access Audit Records
    • When group policy objects are edited, there will be telltale traces in the file system audit trail on sysvol.  The typical event will look like:

Type: Audit Success
Event ID: 560
Time: 4/3/2005 7:39:14 PM
Source: Security
Computer: ACSDEMO-COLL
Category: Object Access
User: CONTOSO\Administrator
Description:
Object Open:
Object Server: Security
Object Type: File
Object Name: C:\WINDOWS\SYSVOL\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\GPT.INI

What file name you see here depends on which settings were edited. Note that for security policy GPEdit works on a temp file and then writes the original:
C:\WINDOWS\SYSVOL\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.tmp
C:\WINDOWS\SYSVOL\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf
I've described most of the file names you're likely to see, further down in this post.

 Handle ID: 2600
Operation ID: {0,1741006}
Process ID: 4
Image File Name:
Primary User Name: ACSDEMO-COLL$
Primary Domain: CONTOSO
Primary Logon ID: (0x0,0x3E7)
Client User Name: Administrator
 Client Domain: CONTOSO
Client Logon ID: (0x0,0x1A8F5C)
Accesses: READ_CONTROL
SYNCHRONIZE
ReadData (or ListDirectory)
WriteData (or AddFile)
AppendData (or AddSubdirectory or CreatePipeInstance)
ReadEA
WriteEA
ReadAttributes
WriteAttributes
Privileges: -
Restricted Sid Count: 0
Access Mask: 0x12019F

We cannot audit exactly which setting changed. I have bugged the group policy team any number of times about this but I think due to resource issues this won't improve much in the forseeable future. The bottom line is that GPEDIT.MSC edits the policy file directly; there's no intervening trusted service to instrument for audit. In a future release of Windows I hope to fix this.

However, you can narrow changes down to settings groups [security vs. non-security] depending on the file that was touched on sysvol. If security policy is touched, then GptTmpl.inf will change. If the list of adms used to construct the policy changes, admfiles.ini will change. If the registry-based settings outside security policy change, then registry.pol will change.

Here's my brief key of which directory\file names refer to which settings group. Given the directory structure for a single policy (\\domain\sysvol\domain.fqdn\policies\{policyguid}\):

  • In the root of the policy directory is a GPT.INI file containing the version number of the associated GPO. Every time GPEdit is used to edit this object, GPT.INI can be expected to change.
    • \Machine - This directory includes a Registry.pol file that contains the registry settings to be applied to computers. When a computer boots up and establishes its secure channel to a domain controller, this Registry.pol file is downloaded and applied to the HKEY_LOCAL_MACHINE portion of the registry. The Machine folder can contain the following subfolders (depending on the contents of the GPO):
      • \Scripts\Startup - Contains the scripts that are to run when the computer starts up.
      • \Scripts\Shutdown - Contains the scripts that are to run when the computer shuts down.
      • \Applications - Contains the application advertisement files (.aas files) used by the Windows installer.
      • \Microsoft\Windows NT\Secedit - Contains the Gpttmpl.inf file, which includes the default security configuration settings for a Windows Server 2003 domain controller.
      • \Adm - Contains all of the .adm files for the GPO. The adm files are the files which control the Group Policy editor user interface.
    • \User - This directory includes a registry.pol file that contains the registry settings to be applied to users. When a user logs on to a computer, this registry.pol file is downloaded and applied to the HKEY_CURRENT_USER portion of the registry. The User folder can contain the following subfolders (depending on the contents of the GPO):
      • \Applications - Contains the advertisement files (.aas files) used by the Windows installer. These are applied to users.
      • \Documents and Settings - Contains the Fdeploy.ini file, which includes status information about the Folder Redirection options for the current user's special folders.
      • \Microsoft\RemoteInstall - Contains the OSCfilter.ini file, which holds user options for operating system installation through Remote Installation Services.
      • \Microsoft\IEAK - Contains settings for the Internet Explorer Maintenance snap-in.
      • \Scripts\Logon - Contains all the user logon scripts and related files for this GPO.
      • \Scripts\Logoff - Contains all the user logoff scripts and related files for this GPO.

The User and Machine folders are created at install time, and the other folders are created as needed when policy is set.

Here is some additional information on the structure of group policy: https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/eb0042e3-699b-4c49-abcc-e3526dbecc0e.mspx

I can't solve all your group policy monitoring woes, I just wanted to document what you'll see in the logs. There are at least three products on the market that can monitor which specific settings changed that you can buy if you need more functionality than what I've described here.

Best regards,
Eric