Policies, preferences, scripts, and scheduled tasks: What can centralized configuration change?

1. Core mechanism

A GPO carries policy data through the GPC in AD and the GPT in SYSVOL; client-side extensions (CSEs) process their own data types. Policies, preferences, scripts, and scheduled tasks can be linked to the same GPO, but they are not the same extension, state model, or execution context. That distinction is the boundary of this lesson; GPO link/permission surfaces are covered in 09.03, and the distinction between resultant policy and refresh failures is covered in 09.05.

Interfaces and specifications

• Policy settings: manage the policy-aware setting of a Windows component; the result depends on that component's policy semantics.
• Group Policy Preferences: configuration items processed by a client-side extension; they cannot be assumed to have the same rollback/application semantics as policy enforcement.
• Scripts: a command or script surface configured at specific processing phases such as computer startup/shutdown or user logon/logoff.
• Scheduled Tasks preference: a definition/configuration item for Task Scheduler; a definition being present in a GPO is not proof that the task was successfully registered or ran on every endpoint.
• Computer-side items are evaluated in the context of computer policy processing; user-side items are evaluated in the context of user policy processing. The actual principal of a command is also determined by that extension/Task Scheduler definition.
• The GPC extension list is a configuration hint; client processing success, local Task Scheduler registration, and task execution are separate layers of evidence.

Four tools are not one 'GPO setting'

Policies, preferences, scripts, and scheduled tasks can appear side by side in the same management console, but you cannot transfer the behavior of one to another. A policy-aware Windows component processes a policy setting according to its own rules. Preferences are configuration items applied to the target by separate CSEs.

Scripts place a program at a specific startup/shutdown/logon/logoff phase. A scheduled-task preference gives Task Scheduler a task definition. In both cases, the statement 'the GPO exists' only describes configuration intent; it does not show that the definition reached the endpoint, that registration succeeded, or that the payload ran.

Therefore the question should not be 'what can a GPO do?' but 'which CSE processes which data, in which policy side, through which local service/component, and what state evidence remains?'

Context: separate computer, user, and task principal

Items carried by Computer Configuration are evaluated in the context of computer policy processing, while items carried by User Configuration are evaluated in the context of user policy processing. This distinction is required to understand which endpoint state is targeted, but by itself it does not say which token every child process will run with.

For a scheduled task, the actual run identity is also determined by the principal in the task definition and by Task Scheduler behavior. Therefore universal rules such as 'GPO task = SYSTEM' or 'user policy task = user token' are not reliable. The review must be completed with the relevant task XML and registration/execution evidence on the endpoint.

For preferences, the assumption that 'when deleted, it automatically returns to the old state' is also unsafe. The item's action, CSE behavior, and the state left on the target must be evaluated together; rollback requirements need to be designed explicitly.

Task registration credentials can override credentials in the definition principal. Read back the registered task and inspect execution evidence before attributing a run identity. Policy mode identifies the policy target, not every resulting process token.

Artifact: intent record is not execution evidence

The artifact is a synthetic 5136 event in which a GPO's extension list appears to have been updated in directory metadata. The gPCMachineExtensionNames field shows only the configuration intent on the GPC side. By itself, this field does not validate the scheduled-task item's SYSVOL content, that the client ran the CSE, or that the task was triggered successfully.

This limitation is not a defensive gap; it is the correct correlation rule: directory evidence investigates who changed the GPO and where; client-side operational logs and local task inventory investigate application/registration. Do not let one signal stand in for the other.

State and data flow

1. The administrator prepares GPC metadata and GPT extension content; the author role is not the task run identity.
2. GPC extension lists and GPT task definitions are separate data. A shared GPO GUID does not equate content with execution evidence.
3. Identify user/computer policy target and processing mode. This target is not the task principal.
4. Keep local registration separate when examining the task definition read by the CSE.
5. Read definition principal, registration credentials and logon type separately. Do not infer a token from the author or policy target.
6. Examine registration evidence. Failed registration or registration alone is not successful execution.
7. Compare execution and local-setting observations separately. This synthetic example runs no actual task or program.

2. Exploitation

Broken trust assumption

Any configuration item inside a GPO runs with the same privilege, has the same level of persistence, and appearing in the GPO automatically means execution on the endpoint.

Technical prerequisites

• For a change to affect an endpoint, the GPO must pass link/filter conditions for the target and the relevant user/computer processing must occur.
• The relevant CSE must be able to read the data, and the local component/Task Scheduler must be able to accept the definition.
• To evaluate the effect of a task or script, the execution principal, target scope, and the payload's local security controls must also be reviewed.

Exploitation mechanism

Incorrect delegation or malicious GPO content changes attempt to alter endpoint state according to the configuration type processed by the relevant CSE. The effect is bounded not by the existence of the GPO, but by the full set of link/filter, CSE processing, local registration, and, where needed, execution evidence.

Reduce the attack model to the CSE

GPO write access can be powerful, but the item type determines what effect it can produce. Changing a preference item is not the same mechanism as enforcing a policy-aware setting. A scheduled-task item first depends on the definition reaching the client, then on Task Scheduler's controls for local registration/running.

Therefore the investigation chain is: changed GPO GUID, changed CSE data, target user/computer scope, local state, and execution if present. If one of these links is missing, limit the scope to 'possible configuration effect'; do not claim successful code execution or broad impact.

Reduce the broken assumption

Separate GPO authoring roles functionally: ordinary desktop preference management, startup/logon script management, and scheduled task authoring should not be assigned to the same broad group. Critical task/script changes require review and a narrow pilot target.

Review unexpected script/task changes in SYSVOL independently from GPC metadata changes. Inventory that exposes target scope and the task principal provides a more reliable control than a 'GPO changed' alarm alone.

3. Defense & Detection

Telemetry scope

• Directory Service Changes audit + SACL are prerequisites for observing GPC attribute changes with 5136.
• 5136 shows directory object/attribute changes; it is not the sole telemetry source for GPT/SYSVOL file content, CSE processing, or Task Scheduler execution.
• Client-side validation depends on whether the relevant endpoint's GroupPolicy/CSE and Task Scheduler channels are being collected; no specific Event ID schema is invented here.

Events and relevant fields

• Security 5136: directory evidence of a GPC attribute change such as gPCMachineExtensionNames.
• SYSVOL/GPT file telemetry: a separate evidence surface for file-side changes such as script/task XML.
• Endpoint CSE/Task Scheduler operational channels and local task inventory: separate sources for validating the registration/execution hypothesis.

Put evidence between intent and result

An extension metadata change in the GPC is a directory record of administrative intent. It must match the data on the SYSVOL side for the same GUID and the local state on the target endpoint. Especially for script and task items, execution must not be inferred from the directory event alone.

Ask three separate questions in telemetry design: Who changed the GPO metadata? Which file/payload changed? Which CSE/task result occurred on which endpoint? Each question may be owned by a different log source.

Do not label normal rollout as an attack

A new task or preference deployment can legitimately appear as an extension-list change and client-side registrations. Without context such as the baseline GPO owner, change window, target OU, and task name/payload hash, do not assign high priority to a single event alone.

Conversely, an approved change record does not automatically legitimize an unexpected principal or target scope on the endpoint. Use the gap between directory intent, SYSVOL content, and local resulting state as an investigation signal.

Detection logic · XPath

/*[local-name()='Event']/*[local-name()='EventData']/*[local-name()='Data' and @Name='AttributeLDAPDisplayName' and text()='gPCMachineExtensionNames']

Query assumptions

• The XPath selects only the directory attribute in the synthetic 5136 artifact; in production, Security event XML fields must be preserved during ingest.
• A gPCMachineExtensionNames change alone does not prove that a specific scheduled task was created or ran.
• The client-side evidence collection policy and the availability of the Task Scheduler operational channel must be validated per endpoint.

False positives

• Approved GPO authoring/deployment changes and normal extension additions/removals.
• Metadata updates performed by GPO restore, migration, or management automation.

Hardening

• Inventory policy, preference, script, and scheduled-task authoring permissions separately; manage high-impact items with narrow roles and review.
• Collect GPC/SYSVOL change evidence separately from endpoint CSE/Task Scheduler evidence; explicitly preserve the source gap in the correlation rule.
• Validate new script/task rollout in a small OU with rollback and local resulting-state checks; the GPO being visible is not a success metric.

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:23:00.0000000Z"/><EventRecordID>9042</EventRecordID><Channel>Security</Channel><Computer>dc1.outreason.example</Computer></System><EventData><Data Name="SubjectUserName">workstation-policy-editor</Data><Data Name="ObjectDN">CN={4F3A1A9E-8D25-4B1C-9A06-0C0F0E090304},CN=Policies,CN=System,DC=outreason,DC=example</Data><Data Name="ObjectClass">groupPolicyContainer</Data><Data Name="AttributeLDAPDisplayName">gPCMachineExtensionNames</Data><Data Name="AttributeValue">{synthetic-scheduled-task-extension}</Data><Data Name="OperationType">%%14674</Data></EventData></Event>

Two reality checks

Assumption: Policy, preference, script, and scheduled task entries visible under a GPO are applied the same way and rolled back the same way when removed.

In fact: These are different CSE and state models. A policy-aware setting, a preference item, a script in a processing phase, and a Task Scheduler definition do not share the same semantics; rollback/persistence behavior must be validated in the context of the relevant item and extension.

Assumption: If a scheduled-task setting appears in a GPO, the task has run on the target machines.

In fact: The GPO/GPC record shows only configuration intent. Link/filter, client CSE processing, local task registration, and, when needed, execution are separate evidence steps; a directory 5136 event does not replace them.

Sources

• Microsoft Open Specifications · [MS-GPOD]: Group Policy: Core Protocol
  GPC/GPT components and the placement of Group Policy data in Active Directory/SYSVOL.
• Microsoft Open Specifications · [MS-GPOL]: Group Policy: Core Protocol
  GPO version and client-side extension processing concepts; distinction between computer/user policy mode.
• Microsoft · Group Policy preferences in Windows
  Preferences are not policy-enforced settings; CSEs process them on each refresh. Scheduled-task preferences can create/modify/delete Task Scheduler tasks; principal and action are configured separately.
• Microsoft · 5136(S): A directory service object was modified
  Directory Service Changes audit; ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType, and Subject fields.
• Microsoft Group Policy Application
  User/computer policy mode and CSE invocation
• Microsoft Task Security Contexts
  Definition versus registration credentials and logon type