Group Policy Objects in Active Directory: What Every Security Practitioner Must Know

Blog 12 of "Mastering Active Directory — Simplified" and the first blog of Module 4. Modules 1 through 3 covered AD architecture, Windows authentication, Kerberos, NTLM, DNS, LDAP, and replication. Module 4 covers Group Policy, which is both the configuration backbone of every enterprise Windows environment and one of the most abused attack surfaces when permissions are misconfigured. Read in order for the best experience.

Group Policy is how enterprise IT teams manage thousands of Windows machines without touching each one individually. Password complexity requirements, screen lock timers, software installations, firewall rules, drive mappings, logon scripts — all of it can be pushed from a central location to any subset of machines and users in the domain automatically. In organizations with thousands of endpoints, Group Policy is not optional. It is essential.

It is also one of the most consequential attack surfaces in Active Directory when write permissions on Group Policy Objects land in the wrong hands. An attacker who can modify a GPO linked to the Domain Controllers OU effectively has a mechanism to execute code on every DC in the domain. An attacker with write access to a GPO linked to a workstation OU can push a malicious logon script to every machine in that OU. Neither scenario requires exploiting a vulnerability. Both require only a misconfigured delegation.

This blog covers what Group Policy Objects are, how they are structured, how the processing order works and why it matters, the filtering mechanisms that control who receives a policy, and exactly how GPOs are stored so that you understand the full picture when you see them during enumeration.

What Group Policy Is and Why Enterprises Depend On It

Group Policy is a Windows feature that allows administrators to define and enforce configuration settings across domain-joined machines and users from a central management point. A Group Policy Object, or GPO, is the container that holds those settings. When a machine boots or a user logs in, Windows contacts a Domain Controller, downloads the GPOs that apply to it, and applies the settings they contain.

The breadth of what GPOs can control is significant. On the computer side, GPOs can configure security settings, manage installed software, enforce firewall rules, set startup and shutdown scripts, control Windows Defender settings, and define local user account policies. On the user side, GPOs can map network drives, configure Internet Explorer or Edge settings, push desktop shortcuts, run logon scripts, restrict access to control panel features, and apply folder redirection.

For an IT team managing five thousand Windows machines across multiple locations, GPOs are the difference between a manageable environment and an unmanageable one. For an attacker who has gained write access to the right GPO, they are a force multiplier that turns a single permission into domain-wide code execution.

GPO Structure: Computer Configuration and User Configuration

Every GPO has two main sections inside it. Computer Configuration applies settings to machines regardless of which user is logged in. User Configuration applies settings to users regardless of which machine they log in from.

When a machine boots, Windows processes the Computer Configuration section of every applicable GPO. When a user logs in, Windows processes the User Configuration section. Both happen independently, which means a single GPO can have both computer-level and user-level settings active at the same time, applying to the machine when it starts and to the user when they log in.

Each of the two main sections is further divided into three areas. Software Settings contains software installation policies. Windows Settings contains security settings, scripts, and folder redirection. Administrative Templates contains hundreds of registry-based settings that control almost every configurable aspect of Windows behavior.

For security assessments, the most relevant areas are Windows Settings under Computer Configuration, which contains the Security Settings node where local password policy, audit policy, user rights assignments, and service configuration live, and the Scripts node under both Computer and User Configuration where logon, logoff, startup, and shutdown scripts are defined. These are the locations attackers modify when abusing GPO write access.

GPO Linking: Where a GPO Applies

Creating a GPO does not automatically make it do anything. A GPO must be linked to a container in Active Directory before it takes effect. There are three places a GPO can be linked.

Site links apply the GPO to all machines and users in a specific Active Directory site, regardless of which domain they belong to. Site-linked GPOs are relatively rare in practice because sites span domains and most policy management is done at the domain or OU level.

Domain links apply the GPO to all objects in the entire domain. A GPO linked at the domain level is the broadest possible scope within a single domain. Password policy for the domain is typically configured in a domain-linked GPO. Any user or computer in the domain will receive a domain-linked GPO unless a more specific exception is in place.

OU links apply the GPO to all objects in a specific Organizational Unit and its child OUs by default. This is the most commonly used link level in enterprise environments because OUs represent organizational structure and GPO linking to OUs enables department-specific or role-specific policy application.

A single GPO can be linked to multiple containers simultaneously. A single container can have multiple GPOs linked to it. Both of these facts are important for understanding the processing order, which determines which settings win when multiple GPOs define the same setting with different values.

The LSDOU Processing Order: Which GPO Wins

When a machine or user has multiple GPOs applying to it from different levels, those GPOs are applied in a specific order. The order is remembered as the acronym LSDOU: Local, Site, Domain, OU.

Local policies are processed first. These are settings configured directly on the local machine through the Local Group Policy Editor, not from Active Directory at all. They are applied but have the lowest precedence.

Site policies are processed second. GPOs linked to the AD site the machine belongs to are applied next.

Domain policies are processed third. GPOs linked at the domain level are applied, overwriting any conflicting settings from Local or Site policies.

OU policies are processed last. GPOs linked to the OU containing the object are applied, overwriting conflicting settings from all previous levels. If the object is in a nested OU structure, the parent OU's GPOs are applied first and the child OU's GPOs are applied after, meaning the most specific OU closest to the object wins.

The critical rule is that later-processed GPOs overwrite earlier-processed GPOs when the same setting is defined in both. OU-level GPOs override Domain-level GPOs. Domain-level GPOs override Site-level GPOs. And when multiple GPOs are linked to the same OU, they are processed in the order defined in the link list on that OU, with lower link order numbers processed last and therefore winning.

This last detail matters in practice. If an administrator links three GPOs to the same OU and wants GPO-A to take precedence over GPO-B, GPO-A needs to have a lower link order number, meaning it appears higher in the list. The interface displays them with the lowest number at the top, and the top-listed GPO is processed last, making it the winner.

Enforcement and Block Inheritance

Two mechanisms exist to override the default LSDOU precedence behavior, and both come up frequently in enterprise environments.

Enforcement (previously called No Override) is a setting applied to a GPO link rather than to the GPO itself. When a GPO link is set to Enforced, that GPO's settings cannot be overwritten by any GPO processed later in the chain. An Enforced domain-level GPO will override OU-level GPOs even though OU GPOs are normally processed last. Enforcement is typically used for security baseline GPOs that an organization wants to guarantee apply to every machine in the domain regardless of any OU-level configurations.

Block Inheritance is a setting applied to an OU. When an OU has Block Inheritance enabled, it prevents GPOs linked above it in the hierarchy, at the Domain or Site level, from flowing down into that OU. An OU with Block Inheritance enabled will only receive GPOs that are directly linked to that OU itself, not GPOs from higher levels.

The interaction between Enforcement and Block Inheritance creates a specific rule that is worth knowing: Enforcement always wins over Block Inheritance. An Enforced GPO link will push its settings into an OU even if that OU has Block Inheritance enabled. The only exception is Local Policy, which Block Inheritance does not affect regardless of Enforcement.

In real environments, Block Inheritance is frequently used on OUs containing privileged accounts or sensitive systems to prevent general domain policies from applying to them. When this is misconfigured, security baseline policies that should apply everywhere stop applying to the most sensitive objects in the domain.

Security Filtering and WMI Filtering

By default, every GPO linked to a container applies to all objects in that container. Security Filtering and WMI Filtering are two mechanisms that narrow down which objects actually receive and process a GPO.

Security Filtering controls which security principals, users, computers, or groups receive a GPO. By default, every GPO has Authenticated Users in its security filter, meaning all domain-joined machines and users receive the GPO. Removing Authenticated Users and adding a specific group means only members of that group will process the GPO. A GPO linked to the entire domain but filtered to the Database Servers computer group will only apply to machines in that group regardless of which OU they live in.

Security Filtering works by granting or denying two permissions on the GPO object in Active Directory: Read and Apply Group Policy. A principal needs both permissions to process a GPO. Removing the Apply Group Policy permission from a group effectively excludes that group from receiving the policy.

This is relevant for attacks because Security Filtering also affects whether an attacker who has compromised an account in a specific group will receive a GPO or not. Understanding which GPOs apply to which accounts and machines is part of mapping the environment.

WMI Filtering uses Windows Management Instrumentation queries to conditionally apply a GPO based on properties of the target machine. A WMI filter might check whether the operating system is Windows 10 or Windows 11, whether a specific application is installed, or whether the machine has a certain amount of RAM. If the WMI query returns true for a machine, the GPO applies. If it returns false, the GPO is skipped.

WMI filters add flexibility but also complexity. A misconfigured WMI filter can cause a security-critical GPO to silently fail to apply to machines that do not match the query, creating coverage gaps that are difficult to detect without explicit testing.

How GPOs Are Stored: SYSVOL and the Group Policy Template

Every GPO has two components: an object stored in Active Directory and a folder stored in SYSVOL. Both are required for the GPO to function. Understanding this dual storage model is important for enumeration because SYSVOL is accessible to every domain user over SMB.

The AD object stores the GPO's metadata: its display name, its GUID, its version number, its links, and its access control list. The GUID is the unique identifier that ties the AD object to its corresponding SYSVOL folder.

The SYSVOL folder stores the actual policy content: the Administrative Template settings in registry.pol files, the Security Settings in GptTmpl.inf, scripts referenced by the GPO, and any files that need to be distributed to machines. The SYSVOL share is replicated between all Domain Controllers using either the older FRS mechanism or the newer DFSR mechanism, ensuring every DC has an identical copy of all GPO content.

The SYSVOL path to a GPO's folder follows a predictable format:

\\<domain>\SYSVOL\<domain>\Policies\{GPO-GUID}\

\\<domain>\SYSVOL\<domain>\Policies\{GPO-GUID}\

Inside that folder are two subfolders: Machine for Computer Configuration content and User for User Configuration content. The GptTmpl.inf file inside the Machine\Microsoft\Windows NT\SecEdit\ subfolder contains security settings in plaintext and is frequently worth reading during enumeration.

When a client processes GPOs, it reads the AD object to determine which GPOs apply and their version numbers, then downloads the GPO content from SYSVOL if the version has changed since the last application. This is why Domain Controllers need to be accessible both via LDAP for the AD object query and via SMB for the SYSVOL download.

A Real-World Scenario: GPO Write Access to Domain-Wide Code Execution

A red team is three days into an internal engagement. They have compromised a domain user account called m.bishop, a junior IT support analyst. BloodHound shows that m.bishop is a member of a group called Helpdesk-GPO-Managers. That group has GenericWrite on a GPO called "Workstation Security Baseline," which is linked to the Workstations OU containing 1,200 computer objects.

The team examines what the GPO currently does. It enforces screen lock timers, disables USB storage, and sets some registry values for software update behavior. Nothing harmful in the existing configuration. But with GenericWrite on the GPO object and the ability to write to its SYSVOL folder, the team can add to it.

They add a Computer Configuration scheduled task to the GPO. The task runs at machine startup as SYSTEM and executes a PowerShell script that reaches out to an external IP. The next time any of the 1,200 workstations in the Workstations OU processes Group Policy, which happens at startup and then every 90 minutes by default, it will download and run the task.

They wait. Within two hours, 340 machines have checked in. Each one is running their payload as SYSTEM. With SYSTEM on 340 workstations, they start dumping LSASS on machines where privileged users have active sessions. By end of day they have NT hashes for four members of the IT Operations team, two of whom are Domain Admins.

The entry point was a group called Helpdesk-GPO-Managers that was created to allow the helpdesk team to manage one specific GPO for workstation support. The delegation was never audited after it was created. The GPO it controls happened to be linked to every workstation in the domain.

Cheat Sheet: GPO Processing Quick Reference

Up Next

Blog 13 covers SYSVOL, Group Policy Preferences credentials, and GPO abuse: what sensitive data lives in SYSVOL that every domain user can read, how the historical GPP cpassword vulnerability exposed credentials that were encrypted with a publicly known key, and how attackers with GPO write access abuse Group Policy for privilege escalation and persistence.

Follow the series on Medium to stay in order.

This blog is part of "Mastering Active Directory — Simplified" by w0lfstrong. Aligned with CRT-P, CRTP, red team engagements, and internal penetration testing. Read more at medium.com/@w0lfstrong