What is Active Directory Group Policy?

Active Directory Group Policy is an infrastructure feature in Active Directory that allows IT pros to manage their users’ Windows environments and servers. In this article, I will explain in detail what is Group Policy, what is a Group Policy Object (GPO), and how to adjust the policy settings to meet your security needs and compliance requirements. Creating a streamlined and consistent user experience is a beautiful plus.

What is Group Policy in Active Directory?

Group Policy was released with Active Directory back in 1999 with the release of Windows 2000 Server. It was developed to provide enterprises with a secure and streamlined method to facilitate a consistent desktop experience for users (and servers).

You use Group Policy to control the environment of user and computer accounts. This is the most important distinction of how Group Policy was developed – User (based) policies and Computer (based) policies.

• User policies (user configuration) are applied when a user logs in to a computer on the domain.
• Computer policies (computer configuration) are applied during computer startup.

Separating these two core buckets allows IT admins to target specific user settings and computer settings, separately, including group policy preferences.

What is a Group Policy Object (GPO)?

A Group Policy Object (GPO) is a collection of Group Policy settings and configurations. Essentially, they are a prettier front-end to modify the registry in Windows.

We all know how cumbersome, unintuitive, and dangerous it can be to modify the registry with Registry Editor. For these impactful reasons, Group Policy was developed.

The most basic functions a GPO modifies are password policies, allowing only specific users to connect to a specific group of servers via the Remote Desktop Protocol (RDP), and blocking or restricting users from specific shares. These settings manipulate how a system will look, how it will operate, and how it will behave for a somewhat granular group of users.

GPOs are generally created to target organizational units (OUs). Every user and computer object in a specific OU will apply these policy settings. There is a somewhat staggering number of flags and switches you can set to make sure what order these settings are used. I’ll get to that later.

What is the purpose of Active Directory Group Policy?

There are a dizzying number of settings that Group Policy supports. Let me give you some examples:

• Deploying operating systems and other software to all or specific groups of computers/servers.
• Running computer startup scripts and user logoff scripts.
• Changing everyone’s desktop background wallpaper.
• Adding a disclaimer after user login explaining unauthorized use is prohibited.
• Configuring the local Windows Defender Firewall policies and settings.
• Restricting access to Control Panel and Settings.
• Block the command prompt.

How do you access Group Policies?

To manage the local group policy objects on a single computer, you can use the Local Group Policy Editor. To manage Group Policies at the Active Directory domain level, the default common native tool is the Group Policy Management Console.

The Local Group Policy Editor

Generally, you can open the Start Menu and search for ‘group policy‘ to access the Local Group Policy Editor. This a snap-in for the Microsoft Management Console (MMC) that you can use to configure and modify Group Policy settings within Group Policy Objects.

The Group Policy Management Console

To access the Group Policy Management Console, you can use the Microsoft Management Console (MMC) to access it. Even though you can log in to a domain controller to access this tool, that’s generally a ‘No-no.’ It’s best to install it on a local computer or workstation running Windows 10 or Windows 11.

I have a separate article explaining how to install the Group Policy Management Console to manage GPOs.

Permissions and delegation for GPOs

You need to be a member of the Administrators group in an Active Directory domain to create and edit GPOs. There is also a global group called Group Policy Creator Owners. They can also create GPOs; however, they can only modify policies that they have created themselves.

To avoid IT pro burnout, or if your company has more robust compliance requirements around duty ownership, you can delegate these permissions using the Delegation feature in the Group Policy Management Console. This also helps to segment certain admins so they only have the keys to a specific OU or group of OUs.

As an example, a specific desktop support group could get delegated access to the ‘Workstations’ OU levels to handle all the Office and application-specific settings on your desktops.

GPO processing and linking

A key aspect of how Group Policy works is how they are linked in Active Directory and in what order they are processed. The complexity here can vary wildly. This starts the discussion on ‘who wins when a conflict occurs?’

This is the order that GPOs are applied to users and computers:

1. Local GPOs (single computer) or local policies
2. Site
3. Domain
4. Organizational Unit (OU)

The settings further down in the list will win any conflicts. This means that GPOs linked to an OU will get final precedence. Also, each GPO has what’s called a Link Order. The lowest link order is processed last and wins any conflicts that arise.

Troubleshooting issues after linking a GPO to an OU

Another thought around troubleshooting – you can create a new GPO, link it to an OU, go to a workstation to update Group Policy, and then validate the outcome. If the desired outcome is NOT found, a quick tip is to ‘unlink’ the GPO.

Right-click on it and click the ‘Link Enabled‘ checkbox to uncheck it. After you click the ‘Link Enabled’ checkbox/toggle, the GPO is not linked. It will NOT be processed!

Child OUs and GPO inheritance

Unless you make any changes when creating your GPOs, child OUs will inherit all GPOs from their parent. To offer some granularity here, you can block inheritance to stop a GPO from applying to a child OU.

This is as simple as right-clicking on the OU/container and selecting ‘Block Inheritance.’ This will tell Group Policy not to process GPOs further up in the hierarchy.

If there are any GPOs linked at the domain level, they will not be processed in the ‘Citrix Test Users’ OU. This provides a clean environment for, you guessed it, testing!

Enforcing a GPO

Another important topic in GPO processing is enforcement. By default, the settings in parent OUs are overwritten by settings in GPOs from child OUs.

If you right-click on a specific GPO and click Enforced, that GPO’s settings will be the end all, be all. This will make sure these settings get processed even if ‘Block Inheritance’ is in effect.

You can use the Group Policy Modeling wizard at the bottom of the menu to simulate GPOs to troubleshoot this very topic. This is where you enter a specific user container or user account and a specific computer container or computer object, and tell Group Policy to simulate what the end result is and what GPOs would apply. This will show all GPOs that apply, why some GPOs would not apply (permissions, WMI Filtering, etc.), and what the ‘winning GPO’ is for each group policy setting.

Group Policy loopback

The last item I want to mention is lookback processing of Group Policy. This is a specific type of group policy setting that allows you to apply user policies to computers.

When this is enabled, Group Policy processes settings to a computer as if a user was logged in. It’s an excellent troubleshooting tool when you are trying to determine why a specific setting is not applying as expected.

Security and change control for GPOs

A very important part of the process when implementing Group Policy is to keep it robust and under control. This should include some sort of security framework, on paper and in action.

1. You need to be aware of who can create, modify, and delete certain GPOs.
2. Educate your IT pros on how GPOs are created and saved.
   • When you modify a specific setting in GPMC, it goes ‘live’ immediately. A computer or server could conceivably see that and incorporate that setting within seconds or minutes!
   • Be firm about leaving the Default Domain policy and Default Domain Controllers policy objects.
3. Change Control platform. Incorporate auditing on your domain controllers using the security event log to audit changes to Group Policy Object changes.
4. Invest in a software solution that ‘takes control’ over Group Policy administration, such as GPOADmin from Quest Software.

Group Policy is an integral aspect of your IT infrastructure

Group Policy has been near the top of the heap of IT pros’ biggest headache lists for many years. If Group Policy is generally straightforward in design and nature, it can be extremely difficult to troubleshoot due to the mishandling of complex frameworks of GPOs.

Hopefully, you’ve gained a greater understanding of how it works and what the basics of Group Policy entail. Please feel free to leave a comment or question below and thank you very much for reading!