Part 8 — Group Policy Basics: First GPOs, Password Policies, and Basic Hardening

LSDOU Processing Order and Architecture

Think of Group Policy processing as an optical filter stack: every layer adjusts the final image, and the last filter applied dictates what the computer or user ultimately experiences.

Active Directory evaluates Group Policy Objects in a strict order known as LSDOU: Local, Site, Domain, and Organizational Unit. Local security policy runs first, followed by policies linked to the Active Directory Site, then policies linked at the Domain root, and finally policies linked to specific OUs and sub-OUs. When settings conflict, the last policy evaluated wins by default.

In enterprise production environments, admins frequently break this architecture by making direct modifications to the Default Domain Policy or Default Domain Controllers Policy. Modifying default policies introduces unmanageable drift, makes recovery during disaster recovery scenarios nearly impossible, and risks locking out operational infrastructure during Active Directory functional level upgrades. A far worse failure pattern is creating a single, massive GPO linked to the root of the domain containing hundreds of unrelated security and preference settings. This bloats SYSVOL replication, causes severe logon delays, and hides conflicting registry writes.

Group Policy evaluation supports precedence overrides through Link Order, Enforce, and Block Inheritance settings. If two GPOs are linked to the same OU, the GPO with Link Order 1 takes precedence over higher-numbered links. Enabling the Enforce setting on a GPO forces its application down the hierarchy, preventing lower OUs from overriding its settings or blocking it via Block Inheritance. Use Enforce sparingly; overusing it turns policy troubleshooting into an expensive forensic audit.

Fine-Grained Password Policies vs Default Domain Policy

Think of the Default Domain Policy as the baseline building security code, and a Fine-Grained Password Policy (PSO) as the biometric vault lock reserved strictly for high-privilege administrators.

In Active Directory, the account lockout and password policies configured in the Default Domain Policy apply globally to every user object in the domain. Attempting to create a second standard GPO to enforce a 16-character password policy on an admin OU will fail silently. The Windows Security accounts subsystem (SAM/LSASS) only reads domain-level password policies from the domain head object linked via the Default Domain Policy.

To enforce stricter password standards for high-privilege accounts without creating separate domain trees or forcing 20-character complex passwords onto standard end-users, Active Directory provides Fine-Grained Password Policies (FGPP), implemented as Password Settings Objects (PSOs) stored in the System container. PSOs target global security groups directly rather than OUs, ensuring domain administrators and service accounts adhere to rigorous security baselines.

Deploying PSOs via PowerShell ensures consistent, repeatable configuration across environments without relying on administrative GUI wizards:

# Create a Fine-Grained Password Policy for Domain Admins
New-ADFineGrainedPasswordPolicy -Name "Admin-PSO-Policy" `
    -Precedence 1 `
    -ComplexityEnabled $true `
    -MinPasswordLength 16 `
    -PasswordHistoryCount 24 `
    -MinPasswordAge "1.00:00:00" `
    -MaxPasswordAge "90.00:00:00" `
    -LockoutThreshold 5 `
    -LockoutObservationWindow "0.00:15:00" `
    -LockoutDuration "0.00:30:00"

# Apply the policy to the Domain Admins security group
Add-ADFineGrainedPasswordPolicySubject -Identity "Admin-PSO-Policy" -Subjects "Domain Admins"

Organizational Unit Structure and Baseline Hardening

Think of an Organizational Unit hierarchy as a multi-tier tool rack: each tier holds specific equipment with clear functional boundaries so you never accidentally apply industrial power tools to delicate diagnostic instruments.

A resilient Active Directory environment relies on a structured OU hierarchy designed around administrative tiering models (Tier 0 for identity control systems like Domain Controllers, Tier 1 for member servers and enterprise applications, Tier 2 for workstation endpoints). Decoupling user objects from computer objects into distinct OUs prevents policy loopback confusion and simplifies scope targeting for Group Policy Preferences.

With an organized OU layout, baseline hardening GPOs can be created as discrete, single-purpose objects linked to computer OUs. One critical security baseline involves neutralizing legacy, unauthenticated network name resolution protocols: Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name over TCP/IP (NBT-NS).

When a Windows workstation fails to resolve a hostname via DNS, it falls back to broadcasting LLMNR and NBT-NS requests across the local broadcast domain. Attackers on the local network running tools like Responder listen for these broadcasts, spoof responses, and force client endpoints to send NetNTLM hashes for authentication. Disabling these legacy protocols domain-wide effectively eliminates an entire class of lateral movement attack vectors.

# Query resultant password policy applied to an administrative user
Get-ADUserResultantPasswordPolicy -Identity "adm_skaranth"

# Force Group Policy refresh on remote endpoints
Invoke-GPUpdate -Computer "WKSTN-001" -Target "Computer" -Force

To disable LLMNR via Group Policy, navigate to Computer Configuration -> Administrative Templates -> Network -> DNS Client and enable Turn off multicast name resolution. To disable NBT-NS, set NetBIOS options to disabled via Group Policy DHCP settings or push dynamic registry updates targeting HKLM\System\CurrentControlSet\Services\NetBT\Parameters\Interfaces.

Final Thoughts

Group Policy governance requires disciplined OU structure and modular GPO design. Isolating configuration scope prevents policy collision and keeps Active Directory manageable.

Always build small, single-purpose GPOs named logically (e.g., Sec-WKS-Disable-LLMNR) rather than bloated monolithic policies. Validate policy execution regularly using command-line diagnostic tools to guarantee your endpoint hardening baselines remain active.