← Back to Active Directory Foundations

Group Policy Objects Brief


What It Is

A GPO is a collection of configuration settings stored in AD and applied to users and computers based on their location in the directory hierarchy. GPOs are linked to sites, domains, or OUs and deliver security policies, scripts, software deployments, and registry changes. They are processed in LSDOU order (Local, Site, Domain, OU) with more specific policies overriding broader ones.

Dual Security Significance

GPOs matter for two reasons. First, they define security baselines — password policy, audit policy, user rights assignments, firewall rules — so weak GPO settings weaken every system in scope. Second, GPOs are AD objects with their own DACLs, so anyone who can edit a GPO can push configuration changes (including scripts and scheduled tasks) to every system that GPO applies to.

Key Concepts

  • Linkage determines scope — a GPO must be linked to a site, domain, or OU to take effect; an unlinked GPO does nothing
  • LSDOU order — Local, Site, Domain, OU; later policies override earlier ones for conflicting settings
  • SYSVOL — shared folder on DCs storing GPO scripts and templates; readable by all authenticated users
  • GPO permissions — whoever has write access to a GPO can push arbitrary configuration to every system in its scope
  • Background refresh — most settings re-apply every 90-120 minutes without requiring reboots

Interview Phrasing

GPOs are the centralized configuration mechanism in AD that pushes settings to users and computers based on hierarchy. They are processed in LSDOU order. From a security perspective, GPOs define security baselines across their entire scope, and GPO edit rights are effectively code execution rights — anyone who can modify a GPO linked to the Domain Controllers OU can push a scheduled task to every DC.

Common Pitfalls

  • Thinking GPOs only manage wallpapers — they control password policies, user rights, audit settings, firewall rules, and script execution
  • Conflating GPO creation with application — creating a GPO does nothing until it is linked to a scope
  • Ignoring SYSVOL as an attack surface — GPO scripts may contain hardcoded credentials and are readable by any user
  • Not recognizing GPO edit rights as a security concern separate from the settings the GPO delivers