Windows · Password Policy

Fine-Grained Password Policies (PSOs)

Fine-grained password policies let a single Active Directory domain apply different password and lockout rules to different groups of users — stricter for admins, standard for everyone else — without the second domain that used to be the only alternative.

By K Shankar R Karanth Windows Active Directory

Quick idea: A Password Settings Object (PSO) is an Active Directory object that holds one complete set of password and lockout rules and can be linked to a global security group or a specific user. When more than one PSO applies to the same person, a precedence value — not the order they were created — decides which one wins.

PSO

A Password Settings Object — one full set of password and lockout rules, stored as its own directory object.

Precedence

An integer on every PSO. Lower always wins when two PSOs apply to the same user.

Shadow Group

A global security group that stands in for an OU, since a PSO can’t be linked to an OU directly.

What Are Fine-Grained Password Policies?

Before Windows Server 2008, a domain had exactly one password policy and one account lockout policy, both set in the Default Domain Policy, and every account in the domain lived under them whether that made sense or not. Fine-grained password policies removed that constraint: a domain can now hold several password policies at once, each one packaged as a Password Settings Object and linked to whichever users or groups it’s meant for.

Think of the Default Domain Policy as the floor everyone stands on by default, and a PSO as a platform that lifts one specific group of accounts onto stricter — or occasionally looser — ground. Service accounts, help desk staff, and Domain Admins rarely belong on the same floor as a general user population, and PSOs are the mechanism that lets them not be.

Important: A PSO applies only to user objects and global security groups. It cannot be linked to an organizational unit directly. To scope a policy to “everyone in this OU,” create a global security group that mirrors the OU’s membership — commonly called a shadow group — and link the PSO to that group instead.

Why Not Just the Default Domain Policy?

Before this feature existed, an organisation that wanted two different password regimes in one domain had exactly two options: write a custom password filter DLL, or stand up a second domain purely to get a second policy. Both carry real cost — a password filter is code running on every domain controller, and a second domain is an entire additional AD infrastructure to patch, back up, and secure.

Default Domain Policy

One policy, applied to the whole domain. Simple, but can’t treat privileged accounts differently from everyone else.

Custom Password Filter

Code deployed to every domain controller. PSOs don’t interfere with one if it’s already in use.

Fine-Grained Password Policy

Multiple policies in one domain, applied by group or by user, with no extra infrastructure.

A PSO doesn’t replace the Default Domain Policy — it overrides it for whichever accounts it’s linked to. Any account with no PSO applied, directly or through group membership, simply falls back to the Default Domain Policy exactly as before.

How PSO Objects Work

Every PSO lives in the Password Settings Container, a container created automatically under the domain’s System container as soon as the schema supports it. It isn’t visible in Active Directory Users and Computers unless Advanced Features is turned on, and it can’t be renamed, moved, or deleted. You can create additional containers elsewhere in the directory, but only PSOs inside the default Password Settings Container are considered when AD works out which policy applies to a user — so there’s rarely a reason to.

A PSO has nine mandatory attributes covering every setting that would otherwise live in the Default Domain Policy’s password and lockout sections — password history, maximum and minimum password age, minimum length, complexity, reversible encryption, lockout duration, lockout threshold, and the lockout observation window — plus the link to the users or groups it applies to, and its precedence value. Every one of the nine has to be set; a PSO can’t leave a setting undefined and quietly inherit it from the Default Domain Policy underneath.

Key point: Kerberos policy settings are not part of a PSO. Those stay controlled exclusively by the Default Domain Policy, regardless of how many PSOs exist in the domain.

Version Boundaries

Fine-grained password policies were introduced in Windows Server 2008, available in every edition, and originally required the domain functional level to be raised to Windows Server 2008 before any PSO could be created. For that first several years, there was no built-in graphical tool — administrators created and linked PSOs with ADSI Edit or command-line utilities like ldifde.

The Active Directory Administrative Center gained a dedicated Password Settings interface starting with Windows Server 2012 R2, which is the tool covered below. Current Microsoft documentation lists a domain functional level of Windows Server 2012 or higher as the prerequisite for that workflow — worth knowing if this is being applied to an older domain that hasn’t been raised past 2008 or 2008 R2 functional level.

Creating a PSO

Both paths below end up setting the same nine attributes. The GUI is friendlier for a one-off policy; PowerShell is the only practical option once there are more than a couple to manage, or when creating them from a script.

In Active Directory Administrative Center (dsac.exe), open the System container, then Password Settings Container. Choosing New > Password Settings opens a property page where Name and Precedence are required fields, alongside the same password and lockout settings found in the Default Domain Policy. The Directly Applies To section on that same page is where the target group or user gets added — there’s no separate linking step in the GUI.

# Create a fine-grained password policy for privileged accounts, stricter than the domain default
New-ADFineGrainedPasswordPolicy -Name "AdminsPSO" -Precedence 100 `
  -ComplexityEnabled $true -Description "Password policy for privileged accounts" `
  -DisplayName "Domain Administrators PSO" -MinPasswordLength 16 `
  -MaxPasswordAge "60.00:00:00" -MinPasswordAge "1.00:00:00" `
  -PasswordHistoryCount 24 -ReversibleEncryptionEnabled $false `
  -LockoutDuration "0.00:30:00" -LockoutObservationWindow "0.00:30:00" -LockoutThreshold 5

# Link the new policy to the group it should apply to
Add-ADFineGrainedPasswordPolicySubject AdminsPSO -Subjects "Domain Admins"

Parameter	Purpose
`-Name`	Required. The PSO’s object name in the Password Settings Container.
`-Precedence`	Required. Lower value wins when more than one PSO applies to the same account.
`-MinPasswordLength`, `-ComplexityEnabled`, `-ReversibleEncryptionEnabled`	Same meaning as the equivalent Default Domain Policy settings, scoped to this PSO only.
`-MaxPasswordAge`, `-MinPasswordAge`	Take a `TimeSpan` in `D.H:M:S` format — `"60.00:00:00"` is 60 days.
`-LockoutDuration`, `-LockoutObservationWindow`, `-LockoutThreshold`	Lockout duration must be greater than or equal to the observation window, or the cmdlet rejects the values.

Practical rule: Assign precedence values in round numbers — 100, 200, 300 — rather than 1, 2, 3. A gap between values is what makes it possible to insert a new PSO later (150, say) without renumbering every policy that already exists.

Precedence and the Resultant PSO

A user can end up in scope for more than one PSO at once — directly linked to one, and a member of a group that another PSO targets. Only one PSO is ever actually applied; their settings are never merged. Active Directory resolves this with a fixed set of rules, in order:

Situation	Result
A PSO is linked directly to the user	That PSO always wins, regardless of any other PSO the user’s groups carry.
No direct link, but the user belongs to one or more groups with a PSO applied	The PSO with the lowest `Precedence` value among those applies.
Two or more applicable PSOs share the same precedence value	The PSO with the numerically smallest GUID applies — effectively arbitrary, which is exactly why unique precedence values matter.
No PSO applies, directly or through any group	The Default Domain Policy governs the account, same as before PSOs existed.

Every user object carries an attribute called msDS-ResultantPSO that stores the distinguished name of whichever PSO the rules above actually landed on — or nothing, if the Default Domain Policy applies. That attribute is what both the GUI and PowerShell read to answer “which policy actually governs this account,” rather than trying to re-derive the answer by walking every PSO and every group membership by hand.

# Check which PSO actually applies to a specific user, if any
Get-ADUserResultantPasswordPolicy -Identity jsmith

# List every user and group a given PSO is currently linked to
Get-ADFineGrainedPasswordPolicySubject -Identity AdminsPSO

Healthy output: Get-ADUserResultantPasswordPolicy returns the full PSO object when one applies, including its Precedence and password settings. An empty result means the account is on the Default Domain Policy, not that the command failed.

Managing PSOs Over Time

# Change one setting on an existing PSO without recreating it
Set-ADFineGrainedPasswordPolicy AdminsPSO -PasswordHistoryCount 30

# Remove deletion protection before a PSO can be deleted
Set-ADFineGrainedPasswordPolicy -Identity AdminsPSO -ProtectedFromAccidentalDeletion $false

# Delete a PSO once it's no longer needed
Remove-ADFineGrainedPasswordPolicy AdminsPSO

Important: By default, only members of Domain Admins can create, link, or even read the settings inside a PSO — Authenticated Users has no read access to a PSO’s contents by default. A non-admin querying msDS-ResultantPSO for their own account sees which PSO applies, but not what its settings actually are, unless that read permission has been explicitly delegated.

PSO Configuration Issues

Symptom	Likely Cause	Fix
`New-ADFineGrainedPasswordPolicy` fails with a terminating error about precedence	The specified precedence value is already assigned to another PSO in the domain.	Query existing values first with `Get-ADFineGrainedPasswordPolicy -Filter * \| Select Name,Precedence`, then pick an unused one.
A user’s password still follows the Default Domain Policy despite an expected PSO	The PSO is linked to a distribution group or a domain local/universal security group rather than a global security group, or to the user directly through a group that isn’t actually global-scoped.	Confirm the group’s scope is Global with `Get-ADGroup -Identity <group> -Properties GroupScope`; only global security groups and direct user links are evaluated for RSOP.
A PSO applied to an OU seems to have no effect	PSOs cannot link to an OU directly — this is expected behaviour, not a bug.	Create a shadow group containing the OU’s members and link the PSO to that group instead.
Two PSOs both seem to be in scope and the wrong one wins	Both PSOs share the same `Precedence` value, so GUID comparison — not administrator intent — decided the winner.	Re-run `Set-ADFineGrainedPasswordPolicy` on one of them with a unique `-Precedence` value.
`Remove-ADFineGrainedPasswordPolicy` fails	The PSO still has `ProtectedFromAccidentalDeletion` set to `$true`, its default state when created through ADAC.	Clear the flag first with `Set-ADFineGrainedPasswordPolicy -Identity <name> -ProtectedFromAccidentalDeletion $false`, then remove it.

Final Thoughts

Fine-grained password policies solved a problem that used to force a real infrastructure trade-off: either every account lived under one policy, or the organisation stood up an entire second domain to get a second one. A PSO is a single directory object with nine attributes and a precedence number, and that’s the whole mechanism — no filter DLL, no additional forest.

The part most worth getting right on day one is precedence spacing. A domain with PSOs numbered 100, 200, and 300 can absorb a new policy at 150 without touching anything that already exists; a domain that started at 1, 2, 3 eventually has to renumber existing policies to make room, which is exactly the kind of maintenance that gets postponed until it causes a genuine conflict.

Key takeaway: Before relying on a new PSO, confirm it took effect with Get-ADUserResultantPasswordPolicy -Identity <user> against a real account in its scope — not just Get-ADFineGrainedPasswordPolicy, which only confirms the PSO exists, not that any particular user actually resolves to it.

Next in this series

Windows LAPS tackles a related but separate gap: PSOs control the rules a domain password has to meet, while LAPS controls the local administrator password that never touches those rules at all.