What is Group Policy in 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.

Both computer and user policies are further divided into three more buckets:

• Software settings and Windows settings configure local DLL files on the machine.
• Administrative templates are settings that configure the local registry of the machine. You can add more options to administrative templates by right clicking it and choose .ADM files. Many programs that are installed on the computer add their .ADM files to %systemroot%/inf folder so you can add them to the Administrative Templates folder.

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.

Group Policy terminology

Here are some basic terms you need to be familiar with before drilling down into Group Policy:

• Local policy – Refers to the policy that configures the local computer or server, and is not inherited from the domain. You can set local policy by running gpedit.msc from the Run command, or you can add “Group Policy Object Editor” snap-in to MMC. Local Policies also exist in the Active Directory environment, but have many fewer configuration options that the full-fledged Group Policy in AD.
  
• GPO – Group Policy Object – Refers to the policy that is configured at the Active Directory level and is inherited by the domain member computers. You can configure a GPO – Group Policy Object – at the site level, domain level or OU level.
  
• GPC – Group Policy Container – The GPC is the store of the GPOs; The GPC is where the GPO stores all the AD-related configuration. Any GPO that is created is not effective until it is linked to an OU, Domain or a Site. The GPOs are replicated among the Domain Controllers of the Domain through replication of the Active Directory.
  
• GPT – Group Policy Templates – The GPT is where the GPO stores the actual settings. The GPT is located within the Netlogon share on the DCs.
  
• Netlogon share – A share located only on Domain Controllers and contains GPOs, scripts and .POL files for policy of Windows NT/98. The Netlogon share replicates among all DCs in the Domain, and is accessible for read only for the Everyone group, and Full Control for the Domain Admins group. The Netlogon’s real location is: C:\WINDOWSSYSVOL\sysvoldomain.com\SCRIPTS.
  
  When a domain member computer boots up, it finds the DC and looks for the Netlogon share in it.
  
  To see what DC the computer used when it booted, you can go to the Run command and type %logonserver%\Netlogon. The content of the Netlogon share should be the same on all DCs in the domain.

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 GPO with the lowest link order is processed last and therefore has the highest precedence, winning 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.

How GPOs are updated on computers

GPO inherited from AD is refreshed on the computers by several ways:

1. Log on to computer (If the settings are of “user settings” in GPO)
2. Restart of the computer (If the settings are of “computer settings” in GPO)
3. Every 60 to 90 minutes, the computers query their DC for updates.
4. Manually by using gpupdate command. You can add the /force switch to force all settings and not only the delta.

gpupdate /target:user /force

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!