Learn Active Directory - Fine-Grained Password Policies

#Introduction

In episode 10 you configured password policy and account lockout via GPO — and you may already be asking: what if admins need a 16-character password but regular users can make do with 10? With regular GPO, password policy applies uniformly to the whole domain because the Default Domain Policy can't differentiate per user. Episode 11 answers this limitation with Fine-Grained Password Policies (FGPP).

We'll cover why FGPP is needed, the domain functional level requirement, what Password Settings Objects (PSOs) are, how to create them with New-ADFineGrainedPasswordPolicy, their attributes, precedence rules, how to link them to users and groups, and a comparison with the Default Domain Policy.

#Why FGPP Is Needed

Classic password policy has one structural weakness: one domain, one policy. Yet the population within a single domain is heterogeneous:

• Admins and service accounts — need long passwords and strict rotation because they're prime attack targets.
• Regular users — need a policy that balances security and convenience.
• Temporary contractor accounts — can be given a looser policy with a limited active period.

The naive solution is splitting into multiple domains — but that's expensive and complex. FGPP gives you several password policies within the same single domain, with no new domains. That's the right answer for most organizations.

#FGPP Requirements

Before starting, make sure the prerequisites are met:

• Domain functional level of Windows Server 2008 or higher — all DCs must run at that level. Check with Get-ADDomain and the DomainMode property.
• PSOs only apply to users and global security groups — they can't be applied to OUs, computers, or universal groups. Application to groups is done via subject links, not via structure.
• Per-domain scope — a PSO in one domain doesn't affect objects in another domain.

#Password Settings Objects (PSO)

The heart of FGPP is the Password Settings Object (PSO) — an AD object holding one complete set of password policy. PSOs are stored in the Password Settings Container (under CN=Password Settings Container,CN=System) and replicate like other AD objects. A PSO is defined by a set of msDS-* attributes, then applied (subjected) to users or groups.

#Creating a PSO with PowerShell

The most practical way to create a PSO is the New-ADFineGrainedPasswordPolicy cmdlet. An example for a stricter admin policy:

$parameter = @{
    Name = "PSO-Admin"
    Precedence = 10
    MinPasswordLength = 16
    ComplexityEnabled = $true
    PasswordHistoryCount = 24
    MinPasswordAge = (New-TimeSpan -Days 2)
    MaxPasswordAge = (New-TimeSpan -Days 90)
    LockoutThreshold = 5
    LockoutDuration = (New-TimeSpan -Minutes 30)
    LockoutObservationWindow = (New-TimeSpan -Minutes 30)
}
 
New-ADFineGrainedPasswordPolicy @parameter

Note the splatting pattern: parameters are collected in a hashtable then called with @parameter — keeping long commands readable and easy to modify. New-TimeSpan is used for duration values like password age.

#PSO Attributes

Each PSO translates to msDS-* attributes in AD:

Understanding these attributes lets you map the GPO policies from episode 10 into PSO form — only now the scope can differ per group.

#Precedence and Application

How does AD decide which PSO applies when a user belongs to several groups with different PSOs? The rules, in order:

1. A PSO applied directly to the user beats all PSOs applied via groups.
2. If the user has no direct PSO, the PSO with the smallest precedence value applied via groups wins.
3. If two PSOs have equal precedence, the one applied to the user's primary group is used.

Linking a PSO to a group is done with Add-ADFineGrainedPasswordPolicySubject:

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Admin" -Subjects "Domain Admins", "Enterprise Admins"

A common strategy: create several PSOs with clear precedence gaps (e.g. 10, 20, 30) and link them to the right groups. New members of an admin group automatically get the stricter policy with no other changes — that's the power of group-based application.

#Comparison with the Default Domain Policy

The Default Domain Policy is the built-in password policy that applies to all users in the domain — it can't be deleted and serves as the fallback when no PSO applies. FGPP works on top of it:

• Users not reached by any PSO > follow the Default Domain Policy.
• Users covered by a PSO > the PSO policy overrides the Default Domain Policy.

Recommended practice: keep the Default Domain Policy as a safety net with sensible values for the general population, then create dedicated PSOs for groups needing different policies (stricter for admins, looser for contractors). Don't rely on the Default Domain Policy as the only policy — FGPP is the complement that makes policy truly match the population.

#Managing and Verifying PSOs

The PSO lifecycle is managed with consistent cmdlets:

Get-ADFineGrainedPasswordPolicy -Filter *
Set-ADFineGrainedPasswordPolicy -Identity "PSO-Admin" -MinPasswordLength 18

To verify which policy actually applies to a user:

Get-ADUserResultantPasswordPolicy -Identity budi.santoso

Get-ADUserResultantPasswordPolicy is the most valuable tool in FGPP troubleshooting: it shows the final result policy after all precedence rules are applied. If a user doesn't get the expected PSO, check the precedence order and group membership. Remove a user from a PSO's subjects with Remove-ADFineGrainedPasswordPolicySubject if needed.

#Conclusion

Episode 11 completes the password policy puzzle: you understand why FGPP is needed when the domain population is heterogeneous, the Windows Server 2008+ domain functional level requirement, what Password Settings Objects are, creating PSOs with New-ADFineGrainedPasswordPolicy, reading the underlying msDS-* attributes, the precedence rules that decide which PSO wins, linking PSOs to users and groups, and verifying with Get-ADUserResultantPasswordPolicy.

Key takeaways:

• FGPP enables multiple password policies in a single domain.
• Smaller precedence wins; a direct PSO on a user beats one via groups.
• PSOs can't be applied to OUs — only users and global security groups.
• The Default Domain Policy remains the fallback for those not covered by a PSO.

Good password policy is just one layer of defense. In episode 12 we cover the rest: Active Directory Security Best Practices — privileged access management, the Protected Users group, the admin tier model, service account security, DC hardening, and auditing. See you in episode 12!