How to Audit GPO and SYSVOL Permissions in Active Directory

Context

During security assessments and GPO governance reviews, it is common to find environments with mature tooling: change management, auditing, approval workflows, versioning, and formalized processes.

The critical point is almost never the tool itself.

The risk appears when delegation is implemented poorly, when an operational group grows without control, or when an urgent fix broadens permissions beyond necessity and remains permanent.

In these situations, one question becomes decisive:

What happens if an unauthorized user can modify the content distributed through SYSVOL?

The answer is simple: you can have a GPO that looks secure in the console, while its operational payload is alterable on the file system.

If your goal is to understand not only who can alter a GPO's content, but also how to separate who should receive the policy from who is allowed to administer it, a useful companion read is GPO Security Filtering vs Delegation in Active Directory: critical differences for audits and hardening.

Scope and evidence

This article focuses on a precise scope: operational GPO security on the SYSVOL side (GPT), not only delegation visibility in GPMC.

Evidence in this guide is practical and verifiable:

• real assessment scenario patterns;
• controlled lab demonstration with no offensive payload;
• PowerShell-based audit and remediation checklist;
• production-ready least-privilege principles.

Objective of this article

This article does not claim that GPO governance products automatically introduce vulnerabilities.

On the contrary, in most cases the issue is implementation:

• excessive delegation;
• NTFS or Share ACLs that are too permissive;
• unmanaged inheritance;
• security groups reused over the years;
• service accounts without least-privilege boundaries.

The goal is to show how to identify and fix this risk in a practical way.

5-minute quick audit

If time is limited, validate these 5 points first:

1. SHARE ACLs on SYSVOL and NETLOGON: no Change/Full for broad groups.
2. NTFS ACLs on Policies\{GUID}: no Modify/Write for unauthorized identities.
3. Effective remote SMB access: validate NTFS+SHARE intersection.
4. GPT inheritance chain: no unintended historical inheritance.
5. Delegated group membership: no oversized legacy groups.

If one of these checks fails, treat the GPO as exposed until remediation is complete.

Repeatable GPC/SYSVOL comparison and change audit

For a repeatable review, the report exports the GPC permission levels returned by Get-GPPermission, the GPT copy's SYSVOL NTFS ACEs, and recent events associated with GPOs to a CSV file. It also generates a local HTML report with visual summaries, search, and pagination; the CSV retains all columns and remains the complete evidence file. The GPO keys let you review both sides together and highlight trustees present on only one side or ACLs with inheritance enabled.

Important limitation: GPO permission levels (GpoApply, GpoRead, GpoEditDeleteModifySecurity) and NTFS rights (ReadAndExecute, Modify, FullControl) are not directly equivalent values. The report compares trustees and shows rights separately; a trustee found on both sides still requires semantic review. AD permissions such as List Object have no one-to-one file-system mapping. This is a read-only report and does not repair ACLs. For the GPMC message “The permissions for this GPO in the SYSVOL folder are inconsistent with those in Active Directory,” use the supported check and synchronization described in Microsoft: Permissions for this GPO are inconsistent. Do not synchronize permissions before saving and reviewing the ACLs.

The script reads Security logs from the domain controllers for the last 30 days. 5136 records GPC attribute changes only when Audit Directory Service Changes and a matching SACL allow them; do not treat it alone as proof of a DACL change (Microsoft Event 5136). 4662 with WRITE_DAC (0x40000) is the signal for AD DACL operations and requires Audit Directory Service Access plus a SACL auditing WRITE_DAC on the GPC (Microsoft Event 4662). 4670 reports permission changes on file-system objects: it requires Audit File System and a SYSVOL SACL auditing Change Permissions or Take Ownership; it is not generated when the SACL itself is changed (Microsoft Event 4670). Configure auditing and SACLs narrowly because they can generate high event volumes.

Execution requirements: PowerShell 7 or later and the RSAT ActiveDirectory and GroupPolicy modules are required; this script is not compatible with Windows PowerShell 5.1. In PowerShell 7, it loads the RSAT modules through the Windows PowerShell compatibility layer. Run it as an administrator with read access to the Security log on every listed domain controller.

Interpreting and validating "Trustee only" signals

Trustee only in GPC/GPT means that the SID is missing from the counterpart list; it is not automatic proof of a vulnerable ACL. GPC permissions and GPT NTFS rights are different models and cannot be compared one-to-one. CREATOR OWNER with ContainerInherit, ObjectInherit, and InheritOnly applies to files and subfolders; it does not grant direct access to the GPT root. On default GPOs, Domain Admins/Enterprise Admins may correspond to BUILTIN\Administrators, and Server Operators may have read-only access; still validate the group's direct members. The standard BUILTIN\Administrators ACE grants real write access: a user added directly to that group can modify the GPT even without GpoCustom on the GPC. Do not assume every group member is equivalent to Domain/Enterprise Admins; validate and approve direct user members individually.

For the GPO under review, compare its GPC permission, GPT ACEs, and full inheritance flags; also check membership in BUILTIN\Administrators. The inspection does not change the domain; the final commands only create local backup files. Run it in PowerShell 7 and adjust $moduleRoot if RSAT manifests are installed elsewhere.

$moduleRoot = Join-Path $env:WINDIR "System32\WindowsPowerShell\v1.0\Modules"
Import-Module (Join-Path $moduleRoot "ActiveDirectory\ActiveDirectory.psd1") -SkipEditionCheck
Import-Module (Join-Path $moduleRoot "GroupPolicy\GroupPolicy.psd1") -SkipEditionCheck

$domain = Get-ADDomain
$gpoName = "Default Domain Policy"
$gpo = Get-GPO -Name $gpoName -Domain $domain.DNSRoot -Server $domain.PDCEmulator
$gpcPermissions = Get-GPPermission -Guid $gpo.Id -All `
    -DomainName $domain.DNSRoot -Server $domain.PDCEmulator
$gptPath = "\\$($domain.PDCEmulator)\SYSVOL\$($domain.DNSRoot)\Policies\{$($gpo.Id)}"
$gptAcl = Get-Acl -LiteralPath $gptPath

$gpcPermissions | Select-Object Trustee, Permission, Inherited
[pscustomobject]@{ GptDaclProtected = $gptAcl.AreAccessRulesProtected }
$gptAcl.Access | Select-Object IdentityReference, FileSystemRights, AccessControlType, `
    IsInherited, InheritanceFlags, PropagationFlags
Get-ADGroupMember -Identity "CN=Administrators,CN=Builtin,$($domain.DistinguishedName)" `
    -Server $domain.PDCEmulator | Select-Object Name, ObjectClass, SID

$backupPath = Join-Path $PWD ("GPO-ACL-Backup-" + (Get-Date -Format "yyyyMMdd-HHmmss"))
New-Item -ItemType Directory -Path $backupPath -ErrorAction Stop | Out-Null
Backup-GPO -Guid $gpo.Id -Path $backupPath -Domain $domain.DNSRoot -Server $domain.PDCEmulator
$gptAcl | Export-Clixml -Path (Join-Path $backupPath "gpt-acl-before.xml")

The GPO backup and XML file provide recovery/evidence points; the code creates the directory before calling Backup-GPO.

In GPMC, inspect Delegation > Advanced and compare trustees, rights, and membership with the approved baseline. On a default GPO, use Restore Defaults only when deliberately restoring standard permissions. If GPMC reports an inconsistency and offers to align SYSVOL with Active Directory, do not confirm blindly: the operation rewrites the GPT NTFS ACL and removes inheritance (Microsoft KB 2838154). For a custom GPO, change delegation through GPMC; do not manually copy the GPC ACL onto the GPT ACL.

If a user who is not authorized to administer DCs is a direct member of BUILTIN\Administrators, treat that membership as an effective SYSVOL write path even if the report finds no matching GPC permission. Check both direct BUILTIN\Administrators members and the user's nested groups, then compare them with Get-GPPermission: Domain Admins and Enterprise Admins are expected administrative delegations, while an account outside those delegations needs explicit approval. If membership is unintended, correct it through change control; do not remove the BUILTIN\Administrators ACE from a default GPT, because authorized administrators rely on it too. If the user only needs to manage specific GPOs, use scoped GPMC delegation rather than granting DC administration. After remediation, recheck GPMC, NTFS and Share, rerun the report, and test policy application on a pilot client.

Products that often require additional delegation or access

In enterprise contexts, it is common to find solutions that require dedicated accounts, approval workflows, or access to GPO/SYSVOL content.

Product	Vendor	Purpose
Advanced Group Policy Management (AGPM)	Microsoft	Versioning, approvals, and GPO change management
GPOADmin	Quest	GPO governance and change control
Recovery Manager for Active Directory	Quest	GPO and SYSVOL backup and restore
PolicyPak	Netwrix	Advanced extensions to Microsoft policies
ADManager Plus	ManageEngine	Administrative management of GPOs
ADAudit Plus	ManageEngine	Policy change auditing
Cayosoft Administrator	Cayosoft	Active Directory governance and administration
Cayosoft Guardian	Cayosoft	Change auditing and monitoring
Change Manager for Group Policy	SDM Software	Approval workflows and change control
Group Policy Automation Engine	SDM Software	GPO automation and deployment
Group Policy Auditing and Attestation	SDM Software	Auditing and compliance
Group Policy Compliance Manager	SDM Software	Compliance controls

Their presence does not imply weakness, but it should trigger a focused review of:

• NTFS ACLs;
• Share ACLs;
• delegated groups;
• service accounts;
• inherited permissions on GPT paths.

Where a Group Policy really lives

A GPO is made of two distinct elements.

Group Policy Container (GPC)

The Active Directory part:

CN={GUID}
CN=Policies
CN=System
DC=domain
DC=local

It stores metadata, versions, and linking information.

Group Policy Template (GPT)

The SYSVOL part:

\\domain.local\SYSVOL\domain.local\Policies\{GUID}

It stores the files that clients actually consume:

• scripts;
• Registry.pol;
• preferences;
• computer/user settings;
• distributed content.

The GPT is the operational impact point.

The control that almost everyone skips

Many audits correctly focus on:

• delegation in GPMC;
• GPO ownership;
• GPO creation and linking rights;
• GPO-side edit permissions.

Much less frequently, NTFS and Share ACLs on SYSVOL GPT paths are analyzed with the same depth.

Yet that is where clients read what they must apply.

If the GPT is writable by unauthorized identities, the policy is compromised even when GPMC appears clean.

Why wrong NTFS ACLs can allow writes (and when they do not)

This is a key point: on SMB paths, effective permissions are the intersection of NTFS ACLs and SHARE ACLs.

In practice:

• if NTFS grants Modify but the SHARE grants only Read, remote write via \\domain\SYSVOL should not pass;
• if both NTFS and SHARE grant write, GPT content can be altered;
• if access happens locally on the Domain Controller (local path), SHARE permissions are out of scope.

So when an assessment finds effective write access on GPT, you must always validate both layers: NTFS and SHARE.

What SHARE defaults you should expect on SYSVOL/NETLOGON

Details can vary slightly by baseline and hardening profile, but in a healthy setup the principle is:

• authenticated users with read-only access;
• administrators with full control;
• no Change or Full assigned to broad groups (Everyone, Authenticated Users, Domain Users).

Recommended quick check:

Get-SmbShareAccess -Name SYSVOL
Get-SmbShareAccess -Name NETLOGON

Or:

net share

Lab demonstration (without commercial tools)

You do not need third-party software to isolate the issue.

Scenario

Domain:

MGLAB.LOCAL

GPO:

MGWP - Logon Script Demo

Configuration:

User Configuration
 └ Windows Settings
    └ Scripts (Logon)

Initial script:

echo %USERNAME% logged on >> C:\Temp\Users.log

No offensive payload: demonstration behavior only.

Initial state

• correct ACLs;
• standard users with read-only access;
• administrators with full control.

Typical administrative mistake

During delegation or troubleshooting, permissions such as the following are assigned, for example:

Authenticated Users = Modify

or:

Everyone = Modify

or:

GPO-Operators = Modify

on a GPT folder in SYSVOL.

Practical effect

A standard user (for example, Test Account), with no GPMC rights and no administrative GPO delegation, can still modify the file distributed by GPT if they have Modify on that path.

From an AD/GPMC perspective, everything can look normal:

• no GPO delegation changed;
• no obvious permission changes in the console;
• policy apparently secure.

But on the next policy application cycle, clients consume the modified GPT content.

Pippo does not modify the GPO in the console.

Pippo modifies what the GPO distributes.

This difference is the core risk.

Why this is high risk in assessment frameworks as well

Many Active Directory security assessment methodologies classify as high risk any GPO-distributed content that is modifiable by standard users or groups that are not strictly authorized.

The principle is the same used by many AD posture analysis platforms: logical delegation governance is not enough, strong control is also required on the SYSVOL file system layer.

Quick verification checklist

1) GPO inventory

Get-GPO -All

2) GPO delegation review

Get-GPPermission -All -Name "MGWP - Logon Script Demo"

Note: in production, it is best to export all delegations and filter unexpected identities.

3) SYSVOL ACL analysis

icacls \\domain\SYSVOL\domain\Policies

or:

Get-Acl "\\domain\SYSVOL\domain\Policies\{GUID}" | Format-List

Look for critical indicators on GPT paths:

• Modify;
• Write;
• Full Control;
• unexpected inheritance;
• generic groups (Everyone, Authenticated Users) with permissions above Read/ReadAndExecute.

4) SHARE ACL analysis on SYSVOL and NETLOGON

Get-SmbShareAccess -Name SYSVOL
Get-SmbShareAccess -Name NETLOGON

Critical indicators on SHARE ACLs:

• Change or Full granted to broad groups;
• SHARE delegation not aligned with least-privilege model;
• unexpected differences between SYSVOL and NETLOGON.

Operational remediation

Immediate priorities

1. Remove unnecessary write permissions from GPT in SYSVOL.
2. Verify Share ACLs as well, not only NTFS ACLs.
3. Check inheritance on Policies folders and GUID subfolders.
4. Revalidate delegated groups and effective membership.

Governance to stabilize

1. Use dedicated groups for GPO delegation with clear naming and limited scope.
2. Separate operational accounts from service accounts.
3. Introduce periodic SYSVOL ACL reviews (for example, monthly or quarterly).
4. Set expiration for every exception, with owner and rationale.
5. Add a specific SYSVOL control to GPO change processes.

Recommended detection controls

• alerts on ACL changes in Policies{GUID} folders;
• monitoring of SYSVOL file changes not tied to approved change records;
• correlation with GPO modification events and maintenance windows.

Quick FAQ (search intent)

What is the difference between GPO Security Filtering and Delegation?

Security Filtering controls who applies the policy. Delegation controls who can administer the policy or its content. These are different planes: filtering can be correct while SYSVOL ACLs still expose GPT write paths.

What default permissions should you expect on SYSVOL?

In a healthy baseline, authenticated users are read-only and administrators keep full control. You should not see broad-group Change/Full on SHARE, or unjustified Modify on GPT NTFS paths.

GPC vs GPT: where is the operational risk concentrated?

GPC covers metadata and logical governance; GPT contains the payload clients execute. If GPT is writable by unauthorized identities, operational risk is immediate even if GPMC looks clean.

How do you restore SYSVOL permissions safely?

Start with ACL backup and a controlled change window. Remove unnecessary write rights on NTFS/SHARE, validate inheritance and delegated-group membership, then test GPO application on a pilot before broad rollout.

Is it enough to check only delegation in GPMC?

No. GPMC delegation covers the logical governance layer of the GPO, but by itself does not guarantee GPT content integrity in SYSVOL. You must always verify NTFS and Share ACLs as well.

Recurring mistakes to avoid

• Trusting only the delegation view in GPMC.
• Fixing incidents by temporarily opening Modify and never removing it.
• Reusing legacy groups without membership review.
• Delegating to overly broad groups to simplify urgent operations.
• Assessing only logical AD risk while ignoring file system risk.

Related deep dives

• RC4 deprecation in Active Directory
• Fallback Kerberos -> NTLM in Active Directory
• SPN in Active Directory: practical guide with KCD and RBCD
• Active Directory RC4 remediation: service accounts from RC4 to AES without password reset

Conclusions

When assessing Group Policy security, do not stop at this question:

Who can modify the GPO?

Always add the decisive question:

Who can modify what the GPO distributes?

If you do not protect SYSVOL with the same discipline used for GPMC delegation governance, an apparently solid policy can become an unreliable distribution vector for the entire domain.

---

Need help?

If you are running AD security assessments or GPO/SYSVOL hardening and want a quick but concrete review of ACLs, delegations, and real operational risk, we can analyze your scenario together and define a prioritized remediation plan.

• Contact me for a focused technical review of your environment.
• Support the project on PayPal if these contents help you in day-to-day work.

---