Understanding GPO Hierarchy and Workflow: Discover how Group Policy is processed in Windows environments. Learn the GPO hierarchy—Local, Site, Domain, and OU—and how each level affects policy application.
In Part I of our Group Policy Introduction series, we explored the basics of Group Policy and its role in Windows environments. In Part II, we delve into the hierarchy of Group Policy processing—a fundamental concept every system administrator must master. Understanding this hierarchy ensures that policies are applied as intended and helps prevent unexpected behavior due to policy conflicts.
Hierarchy of Group Policy
Group Policy follows a top-down processing model that applies settings from four levels in a specific order:
- Local Policy
- Site-Level Policy
- Domain-Level Policy
- OU-Level Policy
This sequence determines how policies are inherited and which settings take precedence in case of conflicts.
Levels of GPO processing
Here are the four unique levels of hierarchy for Group Policy processing as: Local, Site, Domain, and OU. Let’s dig a little deeper into each of them.
1. Local Policy
We have previously discussed Local Group Policy and the use of gpedit.msc to access these settings. Local Policy refers to the computer’s specific policy, and any settings configured in Local Policy will be processed first when Windows starts. These settings have a system-wide impact, irrespective of the logged-in user. However, it is uncommon for companies to rely on Local Policy to enforce settings because it would require manually configuring each workstation, which can be time-consuming.
It is crucial to understand that settings defined at the local policy level may not always remain in effect. Although Local Policy is the first to be applied, any Active Directory Group Policy levels that we will cover shortly take precedence over Local Policy. In other words, your computer might initially apply the Local Policy settings, but moments later during the boot process, these settings could be overwritten by AD policy settings.
2. Site-Level Policies
Within an Active Directory environment, the installation of a tool called AD Sites and Services is automatic on your domain controllers (DCs). This tool serves the purpose of defining the physical locations, or “sites,” within your network. In many cases, small businesses operate with a single site and may never need to access this tool since all resources are connected within the same location. This simplicity is understandable.
However, when a business expands and establishes a second location, the network infrastructure becomes more intricate. At this point, there are typically different IP subnets assigned to each site. Active Directory Sites are determined by the IP address space or subnet in which a computer is currently located. When a computer interacts with Active Directory, its site membership is automatically determined based on its IP address.
Once your environment reaches a significant size and you have configured your Sites using the AD Sites and Services tool, you enable Group Policy to assign settings to computers and users based on their respective site affiliations. In this scenario, users align with the computers they log in from. For example, if a computer account logs in and Group Policy identifies it as belonging to the Washington site, all GPO settings associated with the Washington site will be applied. The same principle applies to any users who log into that computer. Since the computer is currently located in Washington, any user-specific policies targeted for Washington will also be applied.
Note: Keep in mind that computers only receive site-based Group Policy settings while they physically reside in that site. If a computer moves to a new site, any site-level GPOs that were being applied will stop, and new site-level GPOs from the new site will apply.
3. Domain-level Policies
Certain policies and settings are intended to be applied to all machines or users within the entire domain, and the appropriate location for such settings is at the domain level using domain-level GPOs. It’s important to emphasize that the GPOs themselves do not differ when discussing these various policy levels—a GPO remains the same. The distinction lies in the level at which the GPO is linked within the hierarchy.
Up until now, we haven’t delved into GPO links as that topic requires dedicated attention and will be extensively covered when we explore the process of filtering GPO settings in upcoming chapters. For now, it is essential to comprehend that certain GPOs will contain settings that need to be applied across the entire domain, and these GPOs will be linked at the domain level.
When a policy is linked at the top of the domain, that particular GPO will propagate down to every user account and device account within the domain where it is linked. In theory, it should apply to all workstations, servers, and users. However, there are circumstances where a domain-level GPO might not be effectively applied to everything within the domain. Two reasons for this are worth noting.
Firstly, the GPO could have been filtered to exclusively apply to specific machines or groups. This topic will be explored in much greater detail in Chapter 4, which covers Advanced Filtering of Group Policy Objects.
Secondly, certain locations within Active Directory, known as Organizational Units (OUs), may have inheritance blocking enabled. This configuration prevents GPOs from being applied to any objects contained within those specific OUs. These OUs represent the next level of GPO processing, and their impact will be discussed further.
4. OU-level Policies
Organizational Units (OUs) serve as containers or folders that hold computer and user accounts associated with your domain. These OUs are effectively managed and manipulated using the Active Directory Users and Computers tool, which is commonly employed by domain administrators to organize their objects. In a straightforward environment, you might have OUs designated for Users and Computers. As the complexity of your environment increases, you may opt for separate OUs for specific departments like Accounting, Finance, Human Resources, and so forth. Leveraging the full potential of OUs often leads to the creation of multiple OUs nested within larger-scope OUs.
For instance, you could have an OU dedicated to Accounting user accounts, along with a separate OU for Accounting computer accounts. Alternatively, you may choose to establish distinct OUs for desktop computers, laptops, tablets, and even multiple OUs for servers. The possibilities for organizing OUs are extensive and can be tailored to suit your specific needs.
By default, our primary approach for applying Group Policy is at the OU level, as it is the most commonly utilized tier for deploying settings. Linking GPOs to specific OUs offers exceptional flexibility in delivering distinct settings to different groups of users or machines. In contrast to the domain-level GPO mentioned earlier, the provided screenshot depicts a GPO being linked exclusively to a single OU, specifically the Human Resources OU. Despite the presence of numerous other OUs with their respective objects, the settings within the Firewall Settings GPO will solely apply to the machines residing within the Human Resources OU.
GPO Workflow
The order in which the four types of policy processing are listed serves a specific purpose. It reflects the sequential workflow that Group Policy follows when implementing its tasks. During computer boot, Group Policy processes the settings in the following order:
- Local Policy
- Site-level Policies
- Domain-level Policies
- OU-level Policies
The machine progresses through these policies in a top-to-bottom fashion, which is a helpful way to conceptualize the process. When examining GPMC (Group Policy Management Console), maintaining a top-to-bottom perspective will aid in understanding the order of policy application. It’s important to note that the settings within these policies are applied cumulatively, and they have the potential to conflict with one another. In cases where conflicting policy settings exist across different tiers of GPOs, one policy will take precedence while the other will be overridden. Referring to this list will assist in determining which settings will be effective at the conclusion of the GPO processing cycle.
Looking at the processing order list brings to mind a few examples that may be helpful to round out your understanding on this topic:
- Since Local Policy goes first, anything inside any Active Directory Policy has the potential to nullify or change that local policy setting.
- Site-level policies received by a computer will change based on what physical location they are plugged into, so it is important to keep in mind that these settings can be fluid.
- If there is a domain-level policy setting that contradicts a site-level policy setting, the domain-level policy applies last, and therefore wins the day. That setting will be the one that ends up on the client workstation.
- If an OU-level policy applies that conflicts with a site-level or domain-level policy, the OU-linked policy will win every single time.
OUs introduce additional complexities as multiple GPOs can be linked to the same OU, potentially leading to conflicts between them. In such cases, one GPO will take precedence over the others, and the winning GPO may not always be the same in different situations. This can be confusing, making it crucial to carefully plan the filtering of GPOs during their creation.
The nesting of OUs adds another layer of complexity to this scenario. As a general rule, Group Policy processes settings from top-level OUs down the hierarchy. Therefore, GPOs linked to a nested OU are likely to have more influence than GPOs linked at higher-level OUs.
When a machine receives a GPO setting from a tier above the OU where it resides, it is said to inherit that GPO. The concept of inheritance will become important when we discuss inherency blocking and the reasons behind it. Let’s consider an example based on previous screenshots: Computers within the Human Resources OU will receive settings from the Firewall Settings GPO since it is directly linked to that OU. Additionally, computers within the Human Resources OU may also inherit settings from the Default Domain Policy, which is applied at the domain level.
Other series: