Active Directory · Part 6

Active Directory — Part 6 — Group Policy (GPO)

Group Policy is one of the most powerful tools in Active Directory. It allows administrators to enforce configuration, security, and behaviour across users and computers from a central place.

By K Shankar R Karanth Active Directory Concept Guide

Quick idea: If Kerberos verifies who you are, Group Policy defines what your domain-joined computer and user session should look like once you are inside the environment.

Configure

Set Windows, security, desktop, browser, firewall, and system behaviour.

Enforce

Apply rules automatically to users and computers in the domain.

Control

Target settings using sites, domains, OUs, security filtering, and WMI filters.

Introduction

In the previous parts we covered users, groups, Organisational Units, and how Kerberos handles authentication under the hood. Now we get to one of the most powerful and most misunderstood tools in the Active Directory toolkit: Group Policy.

If Kerberos is the lock on the door, Group Policy is everything else: the rules about what the room looks like, what software is waiting for you, what settings are enforced, and what users are not allowed to change.

Done well, Group Policy is elegant. Done carelessly, it is one of the fastest ways to break an entire organisation before your morning coffee.

What Is Group Policy?

Group Policy is a feature of Active Directory that allows administrators to define and enforce settings across users and computers in a domain.

These settings are stored in objects called Group Policy Objects, or GPOs. A GPO can be linked to a site, domain, or Organisational Unit. Any users or computers in that scope can then receive the settings inside the GPO.

A GPO is essentially a collection of configuration rules. It can control something broad, such as password complexity across the domain, or something specific, such as the desktop restrictions for machines in a single department.

What Group Policy Actually Controls

Group Policy has two major sections: Computer Configuration and User Configuration.

Computer

Applies to the machine, regardless of which user logs in.

User

Applies to the user account, usually wherever that user logs in.

Preferences

Can map drives, deploy shortcuts, configure registry values, and more.

Computer Configuration

Computer Configuration settings apply to the computer itself. They are processed during startup and apply regardless of who signs in later.

Common Computer Configuration examples:

- Password and account lockout policies
- Windows Firewall rules
- Windows Update / WSUS configuration
- BitLocker enforcement
- Audit policy settings
- Startup and shutdown scripts
- Software deployment
- Disabling USB storage
- Security baseline settings

User Configuration

User Configuration settings apply to the user account. These settings usually follow the user as they sign in to domain-joined machines.

Common User Configuration examples:

- Logon and logoff scripts
- Drive mappings
- Printer mappings
- Desktop restrictions
- Browser proxy settings
- Start menu and taskbar restrictions
- Folder redirection
- Software restriction policies

How Group Policy Flows: LSDOU

Group Policy does not apply randomly. It follows a strict processing order commonly remembered as LSDOU.

Order	Level	Meaning
1	Local	Policy configured directly on the computer using local policy.
2	Site	GPOs linked to an Active Directory Site.
3	Domain	GPOs linked at the domain level.
4	OU	GPOs linked to OUs, from parent OU down to child OU.

Key rule: Policies applied later have higher precedence. If two GPOs configure the same setting, the more specific GPO lower in the structure usually wins.

Visualising the Flow

Local Policy
  ↓
Site-level GPO
  ↓
Domain-level GPO
  ↓
Top-level OU GPO
  ↓
Child OU GPO
  ↓
Object: User or Computer

Where there is no conflict, settings accumulate. Where there is a conflict, the setting processed later takes precedence.

Default Domain Policies

Every Active Directory domain includes two important GPOs by default.

Default Domain Policy

Linked at the domain level. Best kept for password policy, account lockout policy, and Kerberos policy.

Default DC Policy

Linked to the Domain Controllers OU. Used for settings specific to Domain Controllers.

Best Practice

Create separate purpose-specific GPOs instead of dumping unrelated settings into the defaults.

When Group Policy Applies

Group Policy is applied during foreground processing and then refreshed in the background.

Computer Configuration settings are processed during computer startup. User Configuration settings are processed during user logon.

After that, clients and servers refresh Group Policy in the background every 90 minutes by default, with a random offset of up to 30 minutes. Domain Controllers check for Group Policy changes every 5 minutes by default.

# Force an immediate Group Policy refresh
gpupdate /force

# Force refresh and log off if required
gpupdate /force /logoff

# Force refresh and reboot if required
gpupdate /force /boot

# View resultant policy summary
gpresult /r

# Generate an HTML report
gpresult /h C:\temp\gpresult.html

Synchronous vs Asynchronous Processing

Group Policy can process synchronously or asynchronously.

In asynchronous processing, the computer can continue booting or the user can continue logging in while some policy processing continues in the background. This is faster, but some settings may not be fully applied before the desktop appears.

In synchronous processing, Windows waits for policy processing to complete before continuing. This is slower, but it ensures required settings are applied before the user starts working.

Practical note: Synchronous processing is useful where security or configuration consistency matters more than login speed.

Loopback Processing

Normally, User Configuration settings follow the user. Loopback processing changes that behaviour by applying user settings based on the computer’s OU.

This is useful for kiosks, call centre machines, classrooms, shared terminals, jump servers, or any machine where you want the user experience to be controlled by the computer location rather than the user location.

Mode	Behaviour
Replace	Only user settings from the computer’s GPO list apply. The user’s normal GPO list is ignored.
Merge	User GPOs apply first, then computer-linked user settings apply afterward and win conflicts.

GPO Inheritance Controls

Group Policy inheritance can be modified using Block Inheritance, Enforced links, Security Filtering, and WMI Filtering.

Block Inheritance

Block Inheritance is applied to an OU and prevents GPOs from parent containers from flowing down into that OU.

It can be useful in special cases, but it should be used carefully. Blocking inheritance can make troubleshooting harder and may accidentally prevent security policies from applying.

Enforced

Enforced, also known as No Override, is applied to a GPO link. It forces that GPO to apply even if a child OU has Block Inheritance enabled.

This is useful for non-negotiable settings such as security baselines, audit requirements, or compliance controls.

Security Filtering

Security Filtering controls which users, computers, or groups can apply a GPO within its linked scope.

For example, a GPO linked to the IT OU could be filtered so it applies only to members of SG_Developers, rather than every object in the OU.

WMI Filtering

WMI filters allow a GPO to apply only when a machine matches a query condition.

This can target settings based on operating system version, hardware details, laptop versus desktop, or other system properties. WMI filters are powerful, but they can slow processing and should be kept simple.

Common Group Policy Mistakes

Group Policy problems are often design problems, not tool problems.

Common mistakes:

- Editing Default Domain Policy for unrelated settings
- Linking too many GPOs at the domain level
- Using Block Inheritance everywhere
- Forgetting that lower OU policies can override higher policies
- Applying user settings to computer-only OUs without loopback
- Using WMI filters for everything
- Not documenting what each GPO is for
- Not testing GPOs before broad deployment

Practical Best Practices

Keep GPOs purpose-specific. A GPO named Disable USB Storage is easier to understand than a GPO named IT Settings with fifty unrelated configurations inside it.

Test new GPOs on a small OU before linking them broadly. Use clear naming, document the purpose of each GPO, and avoid changing default policies unless the setting truly belongs there.

For troubleshooting, use gpresult, Resultant Set of Policy, Group Policy event logs, and the Group Policy Management Console to confirm what actually applied.

Quick Reference Summary

Term	Meaning
GPO	Group Policy Object containing configuration settings.
LSDOU	Policy processing order: Local, Site, Domain, OU.
Computer Configuration	Settings that apply to the machine.
User Configuration	Settings that apply to the user account.
Loopback	Applies user settings based on the computer’s OU.
Enforced	Forces a GPO link to apply despite Block Inheritance.
Security Filtering	Targets a GPO to specific users, computers, or groups.
WMI Filtering	Applies a GPO only if a machine matches a WMI query.

Final Thoughts

Group Policy is one of the most powerful parts of Active Directory. It allows administrators to enforce standards, improve security, automate configuration, and control the user and computer experience across the domain.

But that power cuts both ways. Poorly planned GPOs can slow logons, break applications, weaken security, or apply settings far beyond the intended scope.

Key takeaway: Group Policy is central control. Design it carefully, test it before broad rollout, and document every GPO so future administrators understand why it exists.

Next in this series

Next, we can cover Group Policy troubleshooting in depth: gpupdate, gpresult, RSOP, event logs, replication delays, and how to prove which GPO actually applied.