How to Configure Fine-Grained Password Policies on Windows Server 2019

Introduction to Fine-Grained Password Policies

The Default Domain Password Policy in Active Directory applies uniformly to every user account in the domain. While this simplicity is convenient, it creates a security problem: a helpdesk technician and a Domain Administrator are held to the same password standard. Fine-Grained Password Policies (FGPPs), introduced in Windows Server 2008 and fully supported on Windows Server 2019, solve this by allowing different password and lockout settings to be applied to specific users or global security groups.

FGPPs are stored as Password Settings Objects (PSOs) in the Password Settings Container within Active Directory. They do not use Group Policy at all—they are AD objects applied directly to users or groups. This tutorial covers creating, applying, and managing PSOs using both the Active Directory Administrative Center (ADAC) and PowerShell.

Prerequisites

Fine-Grained Password Policies require a domain functional level of Windows Server 2008 or higher. Windows Server 2019 domains easily meet this requirement. Verify your current domain functional level before proceeding.

Get-ADDomain | Select-Object DomainMode, Forest

You must be a member of the Domain Admins group or have delegated control over the Password Settings Container to create and apply PSOs. Standard domain administrators have sufficient rights by default.

Understanding Password Settings Objects

A PSO contains all the same settings as the Default Domain Password Policy: password history, maximum and minimum age, minimum length, complexity, reversible encryption, and lockout settings. Each PSO also has a Precedence value—a number from 1 to 65535. When multiple PSOs apply to a single user (through group membership), the PSO with the lowest precedence number wins. Direct user assignments take priority over group assignments when precedence values are equal.

Creating a PSO Using Active Directory Administrative Center

Open Active Directory Administrative Center by running dsac.exe. In the left pane, expand your domain and navigate to System > Password Settings Container. In the Tasks pane on the right, click New > Password Settings. The Password Settings Creation dialog opens, allowing you to fill in all policy values and specify which users or groups the PSO applies to.

dsac.exe

Give the PSO a descriptive name such as “PSO-DomainAdmins” and set a Precedence of 10 (lower numbers take priority, so 10 beats 20). Configure all the password settings fields according to your requirements for privileged accounts.

Creating a PSO Using PowerShell

The New-ADFineGrainedPasswordPolicy cmdlet creates a PSO entirely from the command line. This is ideal for automation or documenting your configuration in scripts. The following example creates a strict PSO for Domain Administrators with a 20-character minimum length and a 5-attempt lockout threshold.

New-ADFineGrainedPasswordPolicy `
    -Name "PSO-DomainAdmins" `
    -Precedence 10 `
    -MinPasswordLength 20 `
    -PasswordHistoryCount 24 `
    -ComplexityEnabled $true `
    -ReversibleEncryptionEnabled $false `
    -MaxPasswordAge (New-TimeSpan -Days 60) `
    -MinPasswordAge (New-TimeSpan -Days 1) `
    -LockoutThreshold 3 `
    -LockoutDuration (New-TimeSpan -Minutes 30) `
    -LockoutObservationWindow (New-TimeSpan -Minutes 30) `
    -Description "Strict policy for Domain Administrators"

Applying a PSO to a Group

After creating a PSO, you must apply it to users or groups. It is best practice to apply PSOs to global security groups rather than individual users. This makes management easier—add a user to the group to apply the policy, remove them to remove it. Use Add-ADFineGrainedPasswordPolicySubject to apply the PSO.

Add-ADFineGrainedPasswordPolicySubject `
    -Identity "PSO-DomainAdmins" `
    -Subjects "Domain Admins"

You can also apply it to a specific user account for testing or exception handling:

Add-ADFineGrainedPasswordPolicySubject `
    -Identity "PSO-DomainAdmins" `
    -Subjects "jsmith"

Creating a PSO for Service Accounts

Service accounts often require passwords that do not expire. Create a separate PSO for service accounts with a very high password complexity and length requirement but with PasswordNeverExpires effectively managed through this policy structure. Note that MaxPasswordAge of 0 means the password never expires within the PSO scope.

New-ADFineGrainedPasswordPolicy `
    -Name "PSO-ServiceAccounts" `
    -Precedence 20 `
    -MinPasswordLength 25 `
    -PasswordHistoryCount 24 `
    -ComplexityEnabled $true `
    -ReversibleEncryptionEnabled $false `
    -MaxPasswordAge (New-TimeSpan -Days 0) `
    -MinPasswordAge (New-TimeSpan -Days 0) `
    -LockoutThreshold 0 `
    -Description "Policy for automated service accounts - no expiry, no lockout"

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-ServiceAccounts" -Subjects "SVC-Accounts"

Viewing All Password Settings Objects

List all PSOs in the domain to audit your fine-grained password policy configuration. The Get-ADFineGrainedPasswordPolicy cmdlet with a wildcard filter returns all PSOs along with their settings.

Get-ADFineGrainedPasswordPolicy -Filter * | 
    Select-Object Name, Precedence, MinPasswordLength, MaxPasswordAge, LockoutThreshold |
    Sort-Object Precedence

Finding the Resultant PSO for a User

When multiple PSOs could apply to a user through group memberships, use Get-ADUserResultantPasswordPolicy to determine which PSO actually governs that user’s account. This is the single most useful troubleshooting command for fine-grained password policies.

Get-ADUserResultantPasswordPolicy -Identity "jsmith"

If no PSO applies, the user falls under the Default Domain Password Policy and this command returns no output. You can also see which PSO applies through ADAC by selecting the user account and viewing the Password Settings property.

Listing PSO Subjects

To see which users and groups are assigned to a specific PSO, use the Get-ADFineGrainedPasswordPolicySubject cmdlet. This is useful for auditing who has elevated password requirements applied.

Get-ADFineGrainedPasswordPolicySubject -Identity "PSO-DomainAdmins"

Modifying an Existing PSO

Update an existing PSO with Set-ADFineGrainedPasswordPolicy. Only specify the properties you want to change—other settings are left untouched. The following example updates the minimum password length of the Domain Admins PSO to 22 characters.

Set-ADFineGrainedPasswordPolicy `
    -Identity "PSO-DomainAdmins" `
    -MinPasswordLength 22

Removing a PSO Subject

Remove a user or group from a PSO using Remove-ADFineGrainedPasswordPolicySubject. After removal, the subject falls back to the next applicable PSO or the Default Domain Password Policy.

Remove-ADFineGrainedPasswordPolicySubject `
    -Identity "PSO-DomainAdmins" `
    -Subjects "jsmith" `
    -Confirm:$false

Deleting a PSO

To permanently remove a PSO, first remove all its subjects, then delete the PSO object. Deleting a PSO that still has subjects assigned means those subjects immediately fall back to the next applicable policy, which could be less restrictive.

Remove-ADFineGrainedPasswordPolicy -Identity "PSO-DomainAdmins" -Confirm:$false

Delegating PSO Management

By default, only Domain Admins can manage PSOs. To delegate this ability to a specific group such as a Tier 1 admin group, grant the group Read and Write permissions on the Password Settings Container in Active Directory. Use ADSI Edit to locate CN=Password Settings Container,CN=System,DC=yourdomain,DC=com and modify the security descriptor.

adsiedit.msc

Navigate to CN=Password Settings Container,CN=System,DC=yourdomain,DC=com. Right-click, select Properties, go to the Security tab, and add the delegation group with Create/Delete PSO Objects and Full Control on PSO objects permissions.

Conclusion

Fine-Grained Password Policies give Active Directory administrators precise control over password requirements for different tiers of accounts. By applying stricter policies to Domain Admins and privileged accounts while maintaining usable policies for standard users, you significantly reduce your attack surface without frustrating everyday users. Always document your PSO hierarchy, review it quarterly, and use PowerShell to audit resultant policies across your user population.