The two halves of a GPO: GPC, GPT, and SYSVOL

1. Core mechanism

A GPO is one logical object formed by Group Policy Container (GPC) metadata in AD and Group Policy Template (GPT) files in SYSVOL. Which client scope includes the GPO is established by link context on a site/domain/OU; the link is not part of the GPC. If one half is updated while the other is stale, the policy view seen by a client can change.

Interfaces and specifications

• The client talks to the directory service on the domain controller for GPC.
• The client reads the path domain\Policies\{GUID} in SYSVOL for GPT.
• GPC and GPT are mapped to the same policy GUID; A single file path or a single LDAP object is not a GPO.
• Policy settings are divided into sub-files such as registry, script or security template; The path of each setting is evaluated separately.
• Replication delay may cause GPC and GPT copies to appear at different times.

Two halves, one identity

GPC is the container on the directory side; GPT is the file tree on the SYSVOL side. The policy GUID binds these.

This distinction fixes taglines like “GPO is a file” or “GPO is just an LDAP object.”

Version and match

The client determines which content to read by comparing the GPC metadata with the version and location information of the GPT content. This is a distributed reading flow, not instantaneous magic.

Replication limit

AD replication carries the GPC; SYSVOL replication carries the GPT through DFSR or, in legacy environments, FRS. The two paths can complete at different times and produce a temporary mismatch.

Reading result

To understand the effect of GPO, it is necessary to examine directory metadata, link and GPT files together; A single export output does not prove that the other half is healthy.

State and data flow

1. Start: the same policy identity has GPC and GPT copies on DC-A and DC-B. This fixture follows a change to an existing GPO.
2. The admin writes changed GPC metadata at DC-A; DC-B’s copy is not yet the same.
3. The policy’s GPT file is updated in DC-A SYSVOL. GPC and GPT are stored and transferred separately.
4. The client finds a candidate GPO from site/domain/OU links. The fixture’s security filter determines applicability separately.
5. The client reads GPC and GPT copies at its selected DC-B separately; freshness depends on the comparison condition.
6. Compare the two versions. Equality does not establish processing success; mismatch does not independently establish CSE failure.
7. Inspect CSE processing and client output for the applicable policy. Success or failure here is an explicit fixture observation only.
8. Compare the configured value, previous client value and observed result. Do not replace missing observations with success or failure.

2. Exploitation

Broken trust assumption

Publishing a GPO is not just saving a setting; directory metadata, SYSVOL content, link and the version that the client can read are required together.

Technical prerequisites

• The GPC object must be accessible in AD.
• The GPT folder must be accessible with the same policy GUID in SYSVOL.
• The client must have the relevant domain/site/OU scope and the necessary read permissions.
• Replication and version information must be consistent.

Exploitation mechanism

The red-side risk is that the GPC and GPT remain at different revisions under the same GUID, or that GPT reads are blocked. Even if the client finds GPO metadata and link context, failure to read GPT content can prevent affected client-side extension settings from being processed; a successful directory write alone does not prove application.

Limit of fault

If the GPC exists but the GPT does not, the client might see metadata but cannot read the policy files. A GPT folder also does not apply by itself without a matching GPC or a link in the client’s scope.

Thoughts of abuse

GPO write and SYSVOL write privileges are separate attack surfaces. Just because an account can read GPC doesn't mean it can modify it or write to GPT.

3. Defense & Detection

Telemetry scope

• Do GPC object and GPT folder match the same GUID?
• Is there AD and SYSVOL replication delay?
• Does the principal who made the change have the expected authority on both the directory and file side?

Events and relevant fields

• For GPO changes, directory service change audit and SYSVOL file access/replication telemetry are examined together.
• The time and GUID correlation of the GPC attribute change and the file change in GPT is searched.
• On the client side, the policy processing result is evaluated together with the error cause of the unapplied setting.
• Event ID or field meaning is not confirmed without verification with the relevant Windows version and audit policy.
• A single successful LDAP write does not indicate that the client is reading GPT.

blue telemetry

The blue side combines GPC metadata and GPT file movement in the same policy GUID and time context. Directory alone or filesystem log alone provides incomplete evidence.

defense limit

The goal is not to say “GPO has changed”; It is to distinguish which half is changed, by whom, for which client scope, and what the client actually reads.

Detection logic · KQL

// Synthetic schema: GUID-only candidate correlation; no time condition.
DirectoryChange | where AttributeName has "gPC" | join kind=inner (FileChange | where Path has "SYSVOL") on ObjectGuid

Query assumptions

• There is no dataset; query was not run.
• Field names are sample schema, not Windows event XML.
• The join matches ObjectGuid only; widely separated changes may match. Validate timestamp fields and add a bounded time comparison before interpreting temporal proximity. A match does not prove client application.

False positives

• Legitimate Group Policy management and replication latency.

Hardening

• Restrict GPO management to separate admin groups and change approval.
• Review read/write permissions separately for GPC and GPT.
• Monitor SYSVOL replication health and policy processing failures regularly.
• Maintain GPO change audit with adequate retention.

Read the examples

<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:00:00.000000000Z"/><EventRecordID>91001</EventRecordID><Channel>Security</Channel><Computer>DC01.outreason.example</Computer><Security/></System><EventData><Data Name="ObjectClass">groupPolicyContainer</Data><Data Name="ObjectGuid">{11111111-2222-3333-4444-555555555555}</Data><Data Name="AttributeLDAPDisplayName">gPCFileSysPath</Data><Data Name="AttributeValue">\\outreason.example\SYSVOL\outreason.example\Policies\{11111111-2222-3333-4444-555555555555}</Data></EventData></Event>

Two reality checks

Assumption: GPO is just a file folder sitting under SYSVOL.

In fact: GPT files are only one half; a GPT folder is not proof of application without the matching GPC and a site/domain/OU link in the client’s scope.

Assumption: If the GPC change is completed, the client will definitely read the new policy.

In fact: GPC and GPT replication can proceed separately; It should also be verified that the client can read the two halves with the same GUID and appropriate version.

Sources

• Microsoft · Group Policy overview
  GPO components and identity: GPC in AD + GPT in SYSVOL; separate GPC and GPT replication paths (AD replication and FRS/DFSR in SYSVOL). Link/scope is established in a site/domain/OU context.
• Microsoft Open Specifications · [MS-ADTS]: Group Policy
  The GPC is the directory-metadata representation of a Group Policy container in AD; link/scope is established by separate link attributes on a site, domain, or OU.
• Microsoft · Group Policy processing
  LSDOU order, inheritance, filtering, and the loopback processing model.
• Microsoft Open Specifications · [MS-GPOL] Cache of GPO Versions
  Separate GPO Container Version (AD) and GPO File System Version (SYSVOL) values are cached per GPO GUID and can be compared during later client processing.