GPO security: edit rights, delegation and passwords left behind in SYSVOL

A GPO is an administration path

A GPO can deploy a scheduled task running as SYSTEM, add an account to the local Administrators group, run a startup script or change a registry key. Anyone who can write to a GPO therefore gains the rights of every machine it targets. For a GPO linked to the domain root or to the Domain Controllers OU, that means full domain compromise.

The risk is not limited to the GPO object itself. The right to write the gPLink attribute of an OU lets someone link a GPO they already control. And the GPO files in SYSVOL carry their own ACLs, which must stay consistent with the directory object.

Permissions to review

For every GPO linked to a sensitive scope, the question is simple: who, apart from domain administrators, can modify it? The situations we see most often:

• a "Support" or "Helpdesk" group delegated Edit settings on workstation GPOs, and then on a GPO that is also linked to the root;
• the named account of a former administrator still owning GPOs they created;
• members of Group Policy Creator Owners who should no longer be there;
• write access to gPLink granted on OUs holding sensitive servers;
• widened NTFS ACLs on the SYSVOL Policies folder.

Get-GPO -All | ForEach-Object {
  Get-GPPermission -Guid $_.Id -All |
    Where-Object { $_.Permission -match 'Edit' } |
    Select-Object @{n='GPO';e={$_.DisplayName}}, Trustee, Permission
}

Compare the output with a written delegation model: GPOs applying to domain controllers and the domain root should only be editable by the top tier of administrators.

Group Policy Preferences cpassword (MS14-025)

Group Policy Preferences used to allow setting a password for a local account, a service, a scheduled task or a mapped drive. That password was stored in an XML file in SYSVOL, in a cpassword attribute, encrypted with an AES key that Microsoft published. Any authenticated user can read and decrypt it.

The MS14-025 update removed the ability to enter those passwords in the console, but it does not delete existing files. Older domains still contain them, sometimes holding the local administrator password for the entire fleet.

findstr /S /I cpassword \\contoso.local\SYSVOL\contoso.local\Policies\*.xml

Scripts and files in SYSVOL

SYSVOL is readable by all authenticated users. Yet we regularly find logon scripts containing a service account in clear text, .bat files mapping a share with net use /user:, or forgotten configuration exports. A keyword search (password, pwd, /user:, ConvertTo-SecureString) across the whole share takes a few minutes and often turns up surprises. For every secret found: rotate the password first, then remove the file.

What an audit checks

• Write delegations on GPOs linked to the domain root and domain controllers.
• Link rights (gPLink) on sensitive OUs.
• Any cpassword left in SYSVOL XML files.
• Clear-text credentials in scripts and shared files.
• Consistency between directory ACLs and SYSVOL NTFS ACLs.