Which policy applies? LSDOU, filtering, inheritance, and loopback

1. Core mechanism

Policy processing selects and combines GPOs from site, domain, and OU link context into a result on the client. The baseline LSDOU order is Local → Site → Domain → OU; security/WMI filtering, inheritance, and loopback change which candidates are processed and how. Within one site, domain or OU, link order is a separate precedence dimension: the lowest number has the highest precedence by default.

Interfaces and specifications

• The client processes the Local GPO first, then site/domain/OU links (OU links from parent to child). Within the same container, distinguish link order from the processing sequence; order 1 has higher precedence than order 2.
• Security filtering limits principal scope and requires both Read and Apply Group Policy permissions on the GPO.
• WMI filtering can remove the GPO from scope based on the result of the query evaluated by the client.
• Inheritance block and enforced change the merge behavior of parent and child links.
• Loopback merges or replaces the user GPO list using computer scope; it does not change the signed-in user identity. Merge puts the user list first and appends the computer list at higher precedence; Replace uses only the computer-scope list.

LSDOU is a starting order

Local → Site → Domain → OU is the baseline processing direction for linked GPOs. Settings from a child OU are usually processed later and can win a conflict, but filtering and inheritance modify this picture.

For a simple conflicting scalar setting, suppose two eligible GPOs are linked to OU=Finance. GPO-A has link order 2 and value 5; GPO-B has order 1 and value 15. The default sequence processes A then B, so B has precedence. Swapping their link orders changes the predicted source. This example holds filtering and CSE behavior constant; it does not generalize to every extension or prove a client changed.

Filtering and inheritance

The presence of a link does not mean the GPO applies. Security filtering uses Read + Apply Group Policy permissions on the GPO; WMI filtering uses a query evaluated on the destination client. Block inheritance and Enforced affect how parent/child links combine.

The different context of loopback

Loopback adds GPOs from computer scope to the user settings list or replaces the user’s normal list with it. In Merge mode, the user GPO list from the user OU path is processed first, then the list from the computer OU path; the computer list has higher precedence. In Replace mode, the user’s normal GPO list is not gathered and only User Configuration portions from the computer-scope list are processed.

In both modes the signed-in user identity remains the same; loopback does not bypass authorization or erase GPO filtering conditions. On special-use computers such as kiosks or RDS hosts, it selects user settings according to computer scope.

Effective policy evidence

"The GPO is listed" and "the setting became effective" are not the same claim. The result is tested by checking the client's processing log together with the setting's actual value.

State and data flow

1. The client processes the Local GPO.
2. Gather site, domain and parent-to-child OU candidates; within one container, lower-priority links precede the default highest-precedence link, order 1.
3. Keep Read and Apply Group Policy as independent checks. In this fixture, a missing permission or a false client WMI result excludes that candidate.
4. Compare block inheritance with the separate enforced-link rule; an enforced parent link survives the block in this bounded example.
5. Build the eligible computer list and predicted scalar-setting source; this is not evidence of CSE execution.
6. Loopback Merge appends the computer-scope list after the normal user list; Replace uses the computer list alone. The signed-in identity remains unchanged.
7. Verify processing outcome, observed client value and source GPO independently. This comparison does not execute Windows processing or invent a resulting value.

2. Exploitation

Broken trust assumption

Linking a GPO to an OU does not mean it will apply to every user or computer; scope, principal, client state, and inheritance are determined together.

Technical prerequisites

• The GPO link must exist at the relevant site/domain/OU.
• The principal must have Read and Apply Group Policy permissions on the GPO; absence of either can change the security-filtering result.
• If a WMI filter exists, the client must satisfy the query condition.
• Inheritance and enforced/block rules must be explicitly known.

Exploitation mechanism

From the red perspective, if filtering is left on the wrong target, a policy can reach an unexpected computer or exclude a required computer. If loopback is misunderstood, the ownership of user policy can appear to have changed; in reality, the evaluation context has shifted to the computer.

Narrowing the scope

Filtering is a decision gate, not a label. The same GPO can produce different effective policy on two clients, so a single sample client result should not be generalized.

Loopback boundary

Loopback does not erase the user identity and does not bypass authorization. It only changes which computer scope user policy will be merged with.

3. Defense & Detection

Telemetry scope

• What is the site/domain/OU chain for the expected user and computer?
• Who has Read and Apply Group Policy permissions on the GPO?
• What are the WMI filter result, inheritance/Enforced behavior, and loopback mode?
• Effective setting hangi GPO’dan geliyor?

Events and relevant fields

• The client-side policy processing log is used to explain which GPO was applied and which one was skipped because of filtering or access.
• Resultant Set of Policy or an equivalent report should show the effective setting and the source GPO together.
• GPO link, security filtering, and WMI filter changes are correlated as separate administrative events.
• Loopback activity is not interpreted without examining the computer OU scope together with the user session context.
• Because Event ID and field names depend on version and audit configuration, this lesson does not claim a definitive event number.

Blue karar izi

Defense monitors not only the number of linked GPOs, but also the processing decision and reason data. "Denied" and "not evaluated" do not have the same root cause.

Review method

Checking the scope tree first, then filtering, and then the effective setting is safer than treating the default LSDOU narrative as evidence by itself.

Detection logic · KQL

// Counts only Applied/Denied rows in a synthetic schema; skipped or unevaluated rows are excluded.
PolicyProcessing | where Decision in ("Applied", "Denied") | summarize count() by Computer, User, GpoGuid, Reason

Query assumptions

• No dataset; the query was not run.
• PolicyProcessing is an example schema.
• Only Applied and Denied values pass this predicate. Other decisions require a separate view after validating the real schema and value vocabulary; no production decision enum is claimed.

False positives

• Normal OU moves, WMI result changes, or planned GPO revisions.

Hardening

• Constrain link and filtering changes with change control.
• Test computer and user scopes separately; explicitly document OUs where loopback is used.
• Keep WMI filters small and observable; monitor failed results.
• Periodically compare effective policy reports against trusted sample clients.

Read the examples

O:DAG:DAD:(A;;LCRPLORC;;;AU)(OA;;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)

Two reality checks

Assumption: If a GPO is linked to an OU, it applies to everyone in that OU.

In fact: A link is only candidate scope; security/WMI filtering, read/apply permissions, and inheritance determine the decision.

Assumption: Loopback transfers user privilege to the computer and bypasses authorization.

In fact: Loopback reprocesses the evaluation scope of user policy through the computer context; it does not remove identity or authorization checks.

Sources

• Microsoft · Group Policy overview
  Group Policy objects, the GPC/GPT distinction, and the centralized configuration model.
• Microsoft Open Specifications · [MS-ADTS]: Group Policy
  Directory service objects and the representation of attribute values in AD; for this lesson, only the GPC connection context.
• Microsoft · Group Policy processing
  Local → Site → Domain → OU baseline, Read + Apply Group Policy security filtering, client-side WMI query, inheritance/Enforced, and Merge/Replace loopback modes.
• Microsoft · Loopback processing of Group Policy
  Loopback user GPO list is based on computer scope; Merge adds the computer list after the user list; Replace skips gathering the normal user list.
• Microsoft Open Specifications · [MS-GPOL] GPO Processing Order
  §3.2.5.2: Local GPO, Site, Domain, then OU links from parent to child; default non-enforced processing order.
• Apply-Group-Policy extended right · Microsoft Learn
  Rights-GUID / Applies-To Group-Policy-Container