Create Group Policy Objects in Active Directory

In this post, we will create Group Policy Objects (GPOs) in Active Directory (AD). This post is part nine of a home lab that explains how to use Windows Server and Active Directory.

What are Group Policy Objects?

Group Policy is a feature in Windows that allows administrators to centrally manage configuration settings for users, computers, and groups within Active Directory (AD). Group Policy allows Windows administrators to:

• simplify administrative tasks (e.g., software deployment)
• enforce security settings
• tailor policies to specific groups, users, and devices
• apply consistent settings across the organization (e.g., desktop settings)

A (GPO is a collection of Group policy settings organized in a hierarchical structure with varying levels of scope and priority. GPOs can be stored locally and apply to only one computer. Or they can be stored in AD and apply to an entire domain.

Group Policies are separated into two main categories: users and computers. User Group Policies apply to a user regardless of the computer he uses. They control application assignments, logon and logoff scripts, folder redirection, and more. There are around 311 user configuration templates in Active Directory. A user GPO can be applied when a user logs on or off a computer.

Computer Group Policies apply to the computer regardless of who uses it. They control security configurations, application settings, startup and shutdown scripts, system behavior, and more. There are around 312 computer configuration templates in Active Directory. A computer GPO can be applied during system startup or shutdown. Computer policies take precedence over user policies when conflicts arise.

Group Policies in AD operate in a client-server manner. GPOs are stored on a server and applied at the client level (computer or user). When a computer turns on/off or a user logs on/off, the Group Policy engine on the client side checks for applicable GPOs on the server and applies the settings.

GPOs and the Windows Registry

Windows Registry is an integral part of Windows that provides a centralized repository of configuration data. It is a hierarchical database that stores configuration settings for user preferences, hardware, applications, and the operating system.

The Registry consists of two main sections:

• HKEY_LOCAL_MACHINE (HKLM) stores system-wide settings.
• HKEY_CURRENT_USER (HKCU) stores user-specific settings.

The Registry Editor is an application that allows administrators to create, edit, view, or delete registry values within the Windows Registry database. The Registry Editor can be accessed at C:\Windows\regedit.exe.

The Registry Editor can be challenging to navigate and properly apply settings. Group Policy Management provides a more user-friendly interface for interacting with the Windows Registry.

GPOs can read from the Registry or write to it. When applying a GPO (at user login or computer startup), the Group Policy engine writes the policy settings to the Registry.

Group Policy settings are stored in AD and in the SYSVOL folder on DCs, so the settings can be replicated across the network.

When the Group Policy engine applies a GPO:

1. The GPO is downloaded from the SYSVOL folder.
2. The GPO is filtered based on the scope and any applicable filters.
3. Settings are applied to a computer or user profile.
4. Settings are written to the Windows Registry.

Policies vs Preferences

When applying a GPO to a user or computer, you can choose whether the GPO is a policy or a preference.

Policies are enforced settings that the user cannot change. GPO policies are commonly used for security settings (e.g., passwords), system hardening, and compliance enforcement. When the GPO no longer applies the changes made to the Windows registry are reversed.

Preferences are configurable settings that the user can change. GPO preferences are commonly used for drive mappings and user interface (UI) default settings.

User changes to a default GPO preference are reversed at the next GPO refresh interval (e.g., 30 minutes), if the “Apply once” checkbox is disabled. Preferences are useful when users need some control over the setting, yet the administrator wants to also maintain a baseline configuration.

GPO preferences are stored in Windows registry under a lowercase p key. When the GPO is removed any changes made to the Windows registry remain.

How GPOs are Applied

A GPO is applied to a range of users and computers based on:

• GPO scope
• Blocking and enforcing inheritance
• Security filtering
• WMI filters
• Item-Level Targeting (ITL)

GPO Scope

The scope of a GPO is the range of users and computers that are affected by the GPO’s settings. A GPO can be applied (or linked) to different scopes (or levels) within an Active Directory structure:

1. Local
2. Site
3. Domain
4. Organization Unit (OU)

If multiple GPOs configure the same setting, then the higher priority GPO takes precedence. GPOs have greater priority the further they are down the list. GPOs applied at the OU level have the highest priority.

Local Scope

A Local Group Policy applies to a local computer. It is the only scope available if a computer is not connected to a domain. It is the least common scope. It is implemented using gpedit.msc or MMC snap-in for Group Policy.

In AD, GPOs can be applied to Sites, Domains, or OUs.

Site Scope

A Site Group Policy applies to an AD site–a physical location like a branch office that uses one or more subnets. Site Group Policies are mainly used to manage the replication of information between Domain Controllers (DCs) located in different physical locations.

Domain Scope

A Domain Group Policy applies to the entire AD domain. Few Group Policies are linked to the domain level of the organization. A Default Domain Policy is created automatically in AD.

Organizational Unit Scope

OUs are the most common level for applying GPOs. OU GPOs provide for targeted group policies and the delegation of administrative duties.

An OU Scope is the lowest level at which a Group Policy can be applied. A Group Policy linked to an OU applies to all users and computers within the OU. It is not possible to apply Group Policy directly to users, computers, or groups.

A company’s OU structure is heavily influenced by Group Policy. A properly designed OU structure simplifies the application of Group Policies. For instance, GPOs are applied to higher-level OUs and then inherited by lower-level OUs to reduce duplicate configuration settings. Also, users and computers are placed in separate OUs to more easily assign Group Policies.

In an earlier post the OU structure for our example business was created in Active Directory Users and Computers (ADUC). The Nashville Sales users in the right windowpane are part of the following OU structure: techwayfarer.com > Branches > Nashville > Users > Sales.

By default a GPO applies to all users or computers that are part of the scope. For instance, a GPO linked to the Nashville OU applies to all users or computers located within the Nashville branch location.

In the following sections we will discuss the ways of modifying a GPO scope.

Create a GPO Linked to Domain OU

Below is the OU structure of our example business.

• techwayfarer.com OU (domain)
  • Branches OU
    • Dallas OU
    • Kansas City OU
    • Nashville OU
    • San Diego OU

If a GPO that disables access to the Control Panel is enabled at the domain level, then by default it is inherited by the Branches OU and all the individual branch location OUs.

• techwayfarer.com OU (enable “GPO Disable Control Panel”)
  • Branches OU (inherited)
    • Dallas OU (inherited)
    • Kansas City OU (inherited)
    • Nashville OU (inherited)
    • San Diego OU (inherited)

Let’s create a GPO to disable Control Panel and link it to the domain OU.

Open Group Policy Management on your Domain Controller (DC). Open Server Manager, click on Tools, choose Group Policy Management.

In Group Policy Management, right click on your domain name (e.g., techwayfarer.com) and choose “Create a GPO in this domain, and Link it here…”

In the window “New GPO” name the GPO (e.g., GPO Disable Control Panel) and click OK. The new GPO now appears under the domain OU (e.g., techwayfarer.com).

Right click on “GPO Disable Control Panel” and choose Edit. The Group Policy Management Editor opens.

There is an Administrative Template that disables Control Panel. It is located at: User Configuration > Policies > Administrative Templates > Control Panel > Prohibit access to Control Panel and PC settings.

Right click on “Prohibit access to Control Panel and PC settings” and choose Edit.

In the pop-up window “Prohibit access to Control Panel and PC settings” choose Enable and then OK.

Group Policy Management Editor now shows “Prohibit access to Control Panel and PC settings” is Enabled.

We will test that the GPO “Disable the Display Control Panel” is working.

In a prior post we created a Windows 11 virtual machine (VM) and joined it to the Windows domain (techwayfarer.com). Logon to the Windows 11 client computer with a domain user account (e.g., Colin Hay). See an earlier post for instructions on how to add users to Active Directory.

Then try to access Control Panel. You will probably find that you can access the Control Panel. By default, Windows refreshes Group Policy settings every 90 minutes with a random offset up to 30 minutes.

To implement changes to Group Policy Management immediately, on the client device open Command Prompt in Administrator mode. You will be prompted to enter Adminstrator credentials. Then enter in Command Prompt the following:

gpudate /force

After a few seconds you should receive a message in Command Prompt stating “Computer Policy update has completed successfully” and “User Policy update has completed successfully.”

Then recheck whether you can open Control Panel. You should now see a pop-up window titled Restrictions that states “This operation has been cancelled due to restrictions in effect on this computer. Please contact your system administrator.”

Blocking and Enforcing Inheritance

GPOs are organized in a hierarchical manner. By default GPOs linked to an OU are inherited by all child OUs.

If block inheritance is enabled for a child OU, then it does not inherit policies from parent OUs. It may be useful to block inheritance when you want an OU to have its own independent set of policies.

Let’s test whether the GPO created in a prior section “GPO Disable Control Panel” can be blocked by a child OU. The GPO is linked to the domain OU (e.g., techwayfarer.com).

If block inheritance is enabled for the Nashville OU, then policy settings linked to parent OUs (including “GPO Disable Control Panel”) no longer affects the Nashville OU. The result is that users in the Nashville OU can access Control Panel.

• techwayfarer.com OU (enable “GPO Disable Control Panel”)
  • Branches OU (inherited)
    • Dallas OU (inherited)
    • Kansas City OU (inherited)
    • Nashville OU (block inheritance, Control Panel accessible)
    • San Diego OU (inherited)

Open Group Policy Management.

Right click on the Nashville OU and choose “block inheritance.”

A domain administrator can make sure that no site administrators (child OUs) can block a domain level GPO by enforcing inheritance. Then the GPO is inherited by child OUs regardless of whether block inheritance is set for a child OU.

In our lab, block inheritance is still enabled for the Nashville OU. Yet now “GPO Block Control Panel” is configured to enforce inheritance. The result is that computers in the Nashville OU cannot access Control Panel.

• techwayfarer.com (enforce inheritance “GPO Disable Control Panel”)
  • Branches (inherited)
    • Dallas (inherited)
    • Kansas City (inherited)
    • Nashville (block inheritance overwritten, parent GPO inherited, Control Panel not accessible)
    • San Diego (inherited)

Security Filtering for Groups

Administrators in Active Directory can apply security filtering to groups, which then changes the GPOs that are applied to specific users and computers

Let us return to the example used earlier in this post in which “GPO Disable Control Panel” is enabled for the parent domain. We can use security filtering to specify that only the Nashville Sales group receives the block inheritance setting for the Nashville OU. (See an earlier post in which we created a Sales Nashville group and added Sales users to the group.)

The result is that only users in the Nashville Sales group can access Control Panel. All other users in the Nashville OU inherit settings from “GPO Disable Control Panel” and cannot access Control Panel.

• techwayfarer.com OU (enable “GPO Disable Control Panel”)
• Branches OU (inherited)
  • Dallas OU (inherited)
  • Kansas City OU (inherited)
  • Nashville OU (Block inheritance for Nashville Sales group. Parent GPO disabled for Nashville Sales group. Control Panel accessible by users in Nashville Sales group.)
  • San Diego OU (inherited)

Security filtering can be difficult to manage and troubleshoot. It can be difficult to discern how GPOs are applied throughout an OU structure.

Prior to implementing security filtering, an administrator can look at the OU structure to determine GPO inheritance. Now he also needs to look at the group memberships to determine how security filtering influences the application of GPOs.

It is common practice to apply GPOs at various OU levels and minimize the use of security filtering. Extensive use of security filtering is often a sign of a poorly designed OU structure. It may be better to redesign the OU structure than to rely heavily on security filtering.

—additional wording

In the Security Filtering tab of a GPO, the Authenticated Users group is replaced by another security group.

In Group Management tool within Active Directory Group, changes are made to the “Apply Group Policy” permission setting.

WMI Filtering

Windows Management Instrumentation (WMI) filtering uses scripts written in Windows Query Language (WQL) to determine which computers receive policy settings. WMI filtering reviews the operating system (OS), hardware, or software on a computer before a policy setting is applied.

For example, you want to use a GPO to install software on a computer, but only if it uses a 64-bit OS, has at least 8 GB of RAM, and runs Windows 11 Enterprise edition.

GPO Examples

Open Group Policy Management by going to Server Manager > Tools > Group Policy Management.

To see all the domains in your forest, in the left pane click on Forest > Domains. For our lab we created only one domain (e.g., techwayfarer.com).

Under our domain the first listing is “Default Domain Policy” that is created automatically when AD is installed on a Windows Server.

Open Active Directory Users and Computers (ADUC) by going to Server Manager > Tools > ADUC.

In Group

Example: Creating a User GPO

# Block Control Panel for all users in an OU

# 1. Open Group Policy Management Console (GPMC)

# 2. Right-click target OU -> Create GPO and Link

# 3. Name: “User – Block Control Panel”

# 4. Edit: User Configuration -> Policies -> Administrative Templates -> Control Panel

# 5. Enable “Prohibit access to Control Panel”

Example: Password Policy

Use case: Apply a single policy to an entire OU (e.g., enforce password complexity for all users in Sales) instead of changing settings individually.

Example:

1. Create an OU for the Sales department.
2. Add Sales users to a Security Group.
3. Link a GPO to the Sales OU to enforce company-wide security settings for all Sales users.

Example: GPO Security Filtering

Allow a Group to Apply a GPO

1. Open the Group Policy Management Console (GPMC).
2. In the navigation pane, select the GPO you want to modify.
3. In the Scope tab, under Security Filtering, select Authenticated Users and click Remove.
4. Click Add, then in the Select User, Computer, or Group dialog, type the group name.
5. Click Check Names to verify, then click OK.
6. Ensure the group has Read and Apply Group Policy permissions in the Delegation tab.

Prevent a Group from Applying a GPO

1. Open the Group Policy Management Console (GPMC).
2. Select the GPO you want to modify from the navigation pane.
3. In the details pane, click the Delegation tab and then Advanced.
4. Click Add and select the user, computer, or group to restrict.
5. In the permissions list, check Deny for both Read and Apply Group Policy.
6. Click OK, then Yes to confirm.

Conclusion

We are done creating GPOs in Active Directory.

The Windows Server 2022 series of blog posts is complete for now. In the future, we hope to add more content on how to administer a Windows Server.

=== Misc to add

Administrators can create and manage GPOs using tools like the Group Policy Object Editor or Local Group Policy Editor (gpedit.msc).

By structuring OUs logically, applying GPOs at the right level, and using filtering effectively, administrators can ensure efficient and secure policy management across the AD environment.

Best Practices

• Keep GPOs modular (avoid “mega-GPOs”).
• Test in a lab before production deployment.
• Use gpupdate /force and gpresult /r for troubleshooting.
• Document GPO purpose, scope, and linked OUs for maintainability.

Item-Level Targeting (ILT)

• Lets you apply different settings to different users/computers within the same GPO.
• You can add multiple targeting conditions (e.g., “User is in Group A” AND “Computer has 8GB RAM”) and combine them with AND, OR, or NOT logic Microsoft Learn.
• Works for both User Configuration and Computer Configuration settings.

Item-Level Targeting (for Preferences): Applies settings based on attributes like OS version, IP range, or group membership.

Use ILT for granular, per-user or per-computer settings within a GPO.

Group Policy targeting allows domain administrators to determine the users or computers that are affected by a GPO.

See https://www.policypak.com/resources/pp-blog/gpo-item-level-targeting/

In Active Directory, Group Policy targeting lets administrators control exactly which users or computers receive the settings in a Group Policy Object (GPO). Without targeting, a GPO applies to all members of its scope (e.g., all users in an OU) by default 

GPO targeting in Active Directory is about refining the scope of policy application so that settings are applied only to the intended users or computers, improving security, compliance, and operational efficiency.

How Targeting Fits into GPO Processing

• GPOs are linked to sites, domains, or OUs in AD, and the Group Policy service queries AD to determine applicable GPOs.
• Targeting filters the applicability of a GPO to specific users/computers, so only those matching the conditions see the settings.
• Settings are applied at computer startup and user sign-in via the Group Policy Client-Side Extensions

Best Practices

• Use security filtering for group-based targeting (simple and reliable).
• Use WMI filtering for OS or hardware-specific rules.
• Use ILT for granular, per-user or per-computer settings within a GPO.
• Avoid overusing WMI filters to prevent performance issues.
• Test targeting conditions in a lab before deploying in production

How Groups, OUs, and GPOs Work Together

• Groups are used to assign permissions to resources.
• OUs organize users/computers and allow delegation of admin rights. OUs organize users/computers and can be linked to GPOs for policy enforcement.
• GPOs are applied to OUs to enforce policies across groups of users/computers. GPOs apply settings to OUs, so all members of that OU inherit the policy.
• Delegation: OUs can be configured to grant specific admin rights to users/groups without giving them full domain admin access Varonis+1.

Key Takeaways:

• Password and lockout policies are enforced with Group Policy
• Groups = Permission control.
• OUs = Organization and admin delegation.
• GPOs = Policy enforcement.
  Together, they form the foundation of Active Directory’s administrative and security model.

— add as needed

For instance, a GPO linked to an OU also applies to the objects within it (users, computers, other OUs).