Editing, linking, and applying a GPO: Separate permissions, separate impact domains

1. Core mechanism

A GPO is split into two peer components: the GPC in Active Directory and the GPT in SYSVOL. The relationship that applies a GPO to a target does not live on the GPO; it lives in the gPLink attribute of the target Site/Domain/OU (SOM) object. This lesson is limited to the effect of delegation in these three places: the LSDOU/filtering result is covered in 09.02, and diagnosis of why the client did not apply it and version/CSE diagnosis are covered in 09.05.

Interfaces and specifications

• GPC: the directory object in Active Directory under CN={GPO-GUID},CN=Policies,CN=System,DC=outreason,DC=example; GPO metadata and extension lists are stored here.
• GPT: the Policies\{GPO-GUID} directory in SYSVOL; policy files and GPT.INI live on this file system surface.
• gPLink: an attribute of the Site, domain, or OU (SOM) object; the relationship that links a GPO to the target is stored here, not on the GPC.
• Write rights on the GPC DACL cover only the directory side; the GPT/SYSVOL ACL is evaluated separately.
• A principal that can write gPLink on an OU's DACL can change the scope of an existing GPO by linking it to that OU, even without editing the GPO content.
• The existence of an ACE alone is not the effective access result; AccessCheck evaluates it together with the token, inherited ACEs, the requested right, and other ACEs.

One GPO, three separate control points

Thinking of a GPO as a single file or a single AD object leads to delegation mistakes. The GPC is the metadata face in Active Directory; the GPT is the file face in SYSVOL. When the client processes policy, it needs to read a consistent version of these two components.

The third surface is the link. Even if a GPO's content does not change, scope changes if that GPO is added to the gPLink attribute of the finance OU. Conversely, a GPO editor can change the GPC/GPT but cannot choose a new target if it lacks the right to write gPLink on the OU.

This distinction is practical for both change control and incident response: the question "who changed the GPO?" investigates the GPC and SYSVOL, while "who caused this to apply to this OU?" investigates gPLink on the OU.

Edit, link, and apply are not the same permission

Edit effect is completed on two surfaces. A principal that can write the GPC can change directory metadata; however, if it cannot write to the GPT/SYSVOL side, it cannot manage the policy file in the same way. Therefore, instead of looking only at the delegation label shown in GPMC, you need to examine the GPC DACL together with the ACL of the related GPT directory.

Link authority is found in the DACL of the target SOM. Because gPLink is an attribute of that OU, broad rights on the GPO object do not automatically grant the right to add a link to a new OU. In contrast, a principal that can change gPLink on the OU can change the scope of an existing GPO for which it has no edit rights.

Apply is a different question: whether the GPO applies to the relevant user/computer depends on conditions such as the link, inheritance, security filtering, WMI filter, and client-side processing. Being able to link a GPO does not mean that a specific user definitely receives the policy or that a CSE ran successfully.

Artifact: a GPC DACL is not an OU DACL

The first artifact is a synthetic GPC DACL fragment. The ACE that grants Generic Write to the Gpo-Editors group represents only the directory write surface on the example GPC object. The parser shows the ACE and the right token; it does not resolve real schema GUIDs, calculate inheritance, or make an effective access decision.

The second artifact is a synthetic 5136 envelope for a gPLink change on a separate OU object. ObjectDN showing the OU and AttributeLDAPDisplayName showing gPLink explain that the change is on the link surface. 5136 is an observation point only when appropriate Directory Service Changes auditing/SACL scope exists; it is not proof of a SYSVOL file change.

State and data flow

1. Identify the three surfaces: GPC in AD, GPT in SYSVOL and gPLink on the target SOM. The link object is separate from GPO content.
2. Select an example role. Its rights on each surface are authored independently; the model does not calculate AccessCheck from a token.
3. Compare GPC and GPT write authority. A grant on one surface does not grant the other, and no write operation is executed.
4. Inspect link authority on OU=Finance independently. Link-only authority does not grant content editing; content editing does not grant a new target link.
5. Keep Read/Apply, WMI and CSE outcome as separate client conditions. Role authority is not evidence of application.
6. Compare directory-attribute, SYSVOL-file and client-result observations. A 5136 event addresses a directory change; it does not prove the other two.

2. Exploitation

Broken trust assumption

GPO delegation can be reduced to a single 'edit GPO' permission, and the principal that changes the GPO can also link it to the target OU.

Technical prerequisites

• A principal must have effective access that provides write capability on the relevant GPC, GPT, or target SOM; the result cannot be inferred from the group name alone.
• For an effective policy change, GPC/GPT integrity and the client's normal policy processing conditions must also be satisfied.
• For link effect, a gPLink change on the target OU is required; changing GPO content alone does not create new scope.

Exploitation mechanism

When the authority surface is expanded incorrectly, a principal produces a different result depending on the surface it controls: a GPC/GPT editor changes policy content, while a principal that can write gPLink on an OU changes the target scope of an existing GPO. If these two mechanisms can be combined, the impact may be broader; this lesson does not claim that this is automatic domain compromise.

Constrain the impact chain by surface

Write authority on the GPC or GPT changes the trust boundary of policy content; however, its effect depends on where that GPO is linked, which filters it passes, and which setting the relevant CSE processes. For that reason, do not use the shortcut 'GPO write = entire domain'.

Writing gPLink on an OU can link an existing GPO to that OU or remove the link. Even if the GPO's content ACL has not changed, this is a separate change-control event that changes the target population. First evaluate the GPO GUID, then the GPC/GPT content for that GUID and the target OU scope together.

Controls that stop the broken assumption

Grant GPO edit delegation through at least separate groups/roles for GPC and GPT; also restrict link delegation to only the correct OU owners. This prevents a single help desk group from choosing both content and target.

Before removing broad inherited write ACEs and general-purpose administration groups directly from GPO/SOM surfaces, examine effective access and operational need in a pilot OU. A raw SDDL parse result is not proof of which user is allowed.

3. Defense & Detection

Telemetry scope

• The Directory Service Changes audit subcategory and the relevant SACL are separate prerequisites for observing GPC or SOM attribute changes as Security 5136.
• 5136 carries the ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType, and Subject fields; these contextualize the directory change.
• A SYSVOL/GPT file change is a separate file system/replication observation surface; 5136 does not prove it by itself.

Events and relevant fields

• Security 5136: a monitored attribute change on a directory object such as a GPC or OU.
• For a GPC, look for CN={GPO-GUID},CN=Policies,CN=System under ObjectDN; for a link, look for the distinction of the target OU under ObjectDN and AttributeLDAPDisplayName=gPLink.
• The absence of Event 5136 does not support the conclusion 'no change occurred' unless the auditing/SACL or collection scope is known.

What a directory event says, and what it does not say

The strength of 5136 is that it shows which directory attribute changed on which object and under which subject context. In a GPC metadata change, you can look for the GPO GUID; in an OU link change, you can look for AttributeLDAPDisplayName=gPLink.

However, the file surface of the GPO is in SYSVOL. A GPC event does not prove that GPT content changed at the same time, and an OU gPLink event does not show that the client applied the policy. Correlate events while preserving these boundaries.

Build the boundary first, then the anomaly

For high signal, first inventory normal GPO editors, normal deployment windows, target OUs, and automation accounts. Then look for the combination of unexpected subject + critical GPO GUID + broad OU scope.

The detection decision should be supported by the change record, GPC/GPT version and file trail, gPLink change, and client-side results. An ACE or a single 5136 event alone does not prove failed or successful policy application.

Detection logic · XPath

*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=5136] and EventData[Data[@Name='AttributeLDAPDisplayName']='gPLink']]

Query assumptions

• Candidate selector for the Windows Event Log XPath subset on the Security channel. It returns matching event elements, not a Data node. The browser parser reads XML; it does not execute this selector. No native Windows query was run.
• In production, collecting only 5136 is not enough: GPC/SOM SACL scope and SYSVOL file telemetry must also be verified.
• Without ObjectDN/GPO GUID context, a gPLink change is not a risk label.

False positives

• Legitimate link changes made during approved OU reorganization or rollout.
• Changes performed by GPO management automation that match a change ticket.

Hardening

• Inventory GPC, GPT, and gPLink delegation separately; review the same principal's effective access across all three surfaces under change control.
• Design targeted SACL for GPC/SOM and appropriate file telemetry for SYSVOL; measure volume, retention, and privacy impact in a pilot.
• Use two-person approval, narrow role membership, and a rollback plan for high-impact GPOs and critical OU links.

Read the examples

O:BAG:BAD:(A;;GW;;;S-1-5-21-1109110911-2202220222-3303330333-6703)

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>5136</EventID><Version>0</Version><Level>0</Level><Task>14081</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime="2026-10-01T10:15:00.0000000Z"/><EventRecordID>9031</EventRecordID><Channel>Security</Channel><Computer>dc1.outreason.example</Computer></System><EventData><Data Name="SubjectUserName">gpo-link-operator</Data><Data Name="ObjectDN">OU=Finance,DC=outreason,DC=example</Data><Data Name="ObjectClass">organizationalUnit</Data><Data Name="AttributeLDAPDisplayName">gPLink</Data><Data Name="AttributeValue">[LDAP://cn={4F3A1A9E-8D25-4B1C-9A06-0C0F0E090303},cn=policies,cn=system,DC=outreason,DC=example;0]</Data><Data Name="OperationType">%%14674</Data></EventData></Event>

Two reality checks

Assumption: A person with permission to edit a GPO can also link it to any OU they want.

In fact: GPO content resides on the GPC/GPT surfaces, while the link relationship resides in the gPLink attribute of the target SOM. GPO edit delegation and delegation to write gPLink on an OU are separate access checks on different objects; they combine only if both were granted separately.

Assumption: If I see Security 5136, I have proven the entire GPO change and that it was applied to clients.

In fact: 5136 shows a directory attribute change within the scope of appropriate auditing/SACL. The SYSVOL/GPT file side and client-side extension result are separate evidence surfaces; a gPLink change alone is also not an applied policy result.

Sources

• Microsoft Open Specifications · [MS-GPOD]: Group Policy: Core Protocol
  The GPC being in Active Directory, the GPT being in SYSVOL, and the GPO link being stored in the gPLink attribute on the SOM.
• Microsoft · 5136(S): A directory service object was modified
  Directory Service Changes audit; ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType, and Subject fields.
• Microsoft · Access control
  Evaluation of DACL/ACEs in the object access check context; the synthetic SDDL artifact is not an effective access result.
• Consuming Events / XPath limitations · Microsoft Learn
  Event selectors / XPath1.0 limitations