Active Directory Fine-Grained Password Policies: How to Deploy Password Settings Objects That Actually Override the Default Domain Policy

Before creating PSOs, understand the constraints:

Domain functional level: PSOs require Windows Server 2008 domain functional level or higher. Verify: Get-ADDomain | Select-Object DomainMode

Applies to: PSOs can be applied to global security groups or directly to user/inetOrgPerson objects. They cannot be applied to OUs, computer objects, or distribution groups. This is the most common misconfiguration -- admins apply PSOs to OUs expecting all users in the OU to inherit the policy, but OU application is ignored.

Shadow groups for OU-based targeting: To effectively apply a PSO to all users in an OU, create a global security group (shadow group) and use a scheduled script or dynamic group mechanism to keep the shadow group membership synchronized with the OU contents:

# Synchronize shadow group with OU contents (run via scheduled task)
$ouUsers = Get-ADUser -Filter * -SearchBase "OU=ServiceAccounts,DC=domain,DC=com"
$groupMembers = Get-ADGroupMember -Identity "PSO-ServiceAccounts-Shadow"

# Add users in OU but not in group
$toAdd = $ouUsers | Where-Object { $_.SamAccountName -notin $groupMembers.SamAccountName }
$toAdd | ForEach-Object { Add-ADGroupMember -Identity "PSO-ServiceAccounts-Shadow" -Members $_ }

# Remove group members no longer in OU  
$toRemove = $groupMembers | Where-Object { $_.SamAccountName -notin $ouUsers.SamAccountName }
$toRemove | ForEach-Object { Remove-ADGroupMember -Identity "PSO-ServiceAccounts-Shadow" -Members $_ -Confirm:$false }

The AD Administrative Center GUI supports PSO creation, but PowerShell is more reliable for documenting and reproducing configurations:

# PSO for privileged admin accounts: 20+ char, strict lockout
New-ADFineGrainedPasswordPolicy -Name "PSO-PrivilegedAdmins" `
    -Precedence 10 `
    -MinPasswordLength 20 `
    -PasswordHistoryCount 24 `
    -ComplexityEnabled $true `
    -ReversibleEncryptionEnabled $false `
    -MinPasswordAge (New-TimeSpan -Days 1) `
    -MaxPasswordAge (New-TimeSpan -Days 365) `
    -LockoutThreshold 3 `
    -LockoutObservationWindow (New-TimeSpan -Minutes 30) `
    -LockoutDuration (New-TimeSpan -Minutes 0) `
    -Description "Password policy for Tier 0 and Tier 1 admin accounts. Ticket: CHG-1234"

# Apply PSO to group
Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-PrivilegedAdmins" `
    -Subjects "Domain Admins","PSO-PrivAdmins-Shadow"

# PSO for service accounts: 30+ char, no expiry, no lockout
New-ADFineGrainedPasswordPolicy -Name "PSO-ServiceAccounts" `
    -Precedence 20 `
    -MinPasswordLength 30 `
    -PasswordHistoryCount 12 `
    -ComplexityEnabled $true `
    -ReversibleEncryptionEnabled $false `
    -MinPasswordAge (New-TimeSpan -Days 0) `
    -MaxPasswordAge (New-TimeSpan -Days 0) `
    -LockoutThreshold 0 `
    -LockoutObservationWindow (New-TimeSpan -Minutes 30) `
    -LockoutDuration (New-TimeSpan -Minutes 30) `
    -Description "Password policy for service accounts. No expiry, no lockout, high complexity."

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-ServiceAccounts" `
    -Subjects "PSO-ServiceAccounts-Shadow"

Note that LockoutThreshold 0 means lockout is disabled. For service accounts, this is appropriate because lockout creates an availability risk for critical services. Pair with PAM vault credential management instead.

When a user is a member of multiple groups that each have a PSO applied, the PSO with the lowest msDS-PasswordSettingsPrecedence value applies. Lower number = higher priority.

Conflict resolution order:

1. PSO applied directly to the user object beats any PSO applied via group membership (regardless of precedence value)
2. Among group-applied PSOs, the one with the lowest precedence number wins
3. If two PSOs have the same precedence number, AD resolves the tie by comparing the PSO GUID (deterministic but unpredictable from an admin perspective -- avoid duplicate precedence values)

Best practice: assign precedence values in gaps of 10 to allow future policies to be inserted between existing ones:

• 10: Tier 0 Admins (Domain Admins, Schema Admins, Enterprise Admins)
• 20: Tier 1 Admins (server admins, backup operators)
• 30: Service accounts
• 40: Standard users (usually handled by default domain policy, so this PSO is only needed if the default domain policy cannot be changed)

Verify precedence is correct by checking the resultant PSO for a sample of users in each category:

Get-ADUserResultantPasswordPolicy -Identity "admin-username" | Format-List Name, Precedence, MinPasswordLength, LockoutThreshold

This reads the msDS-ResultantPSO attribute and returns the fully resolved policy settings in effect for that user.

After creating and assigning PSOs, verify that each user has the correct policy applied:

# Check the resultant PSO for a specific user
Get-ADUserResultantPasswordPolicy -Identity "jsmith"

# If no PSO is applied, this returns nothing and the default domain policy applies
# The user's msDS-ResultantPSO attribute will be null

# Bulk check: show which PSO is applied to each user in a group
Get-ADGroupMember -Identity "Domain Admins" | ForEach-Object {
    $user = Get-ADUser -Identity $_.SamAccountName
    $pso = Get-ADUserResultantPasswordPolicy -Identity $_.SamAccountName
    [PSCustomObject]@{
        User = $_.SamAccountName
        ResultantPSO = if ($pso) { $pso.Name } else { "Default Domain Policy" }
        MinLength = if ($pso) { $pso.MinPasswordLength } else { (Get-ADDefaultDomainPasswordPolicy).MinPasswordLength }
    }
} | Format-Table -AutoSize

For service accounts specifically, run this query regularly (monthly) to detect any service account that lost its PSO assignment (e.g., due to shadow group membership desync) and reverted to the default domain policy with password expiry enabled -- which would cause the service to fail at expiry.

Service account lockout is an operational risk. A service account locked out due to a brute-force or password spray attack causes the dependent service to fail immediately. The correct approach for service accounts differs from user accounts:

Option 1: Disable lockout for service accounts (PSO LockoutThreshold = 0) The tradeoff is that brute-force attacks against the service account credential succeed eventually if the password is weak. Mitigate with high-complexity passwords (30+ characters, managed by a PAM vault) that are immune to practical brute force.

Option 2: Very high lockout threshold (50-100 failures) Allows detection of a brute-force attempt (via Event ID 4625 surge) before lockout occurs. The service continues operating while the attack is detected and the source IP is blocked.

Option 3: Migrate to gMSA (Group Managed Service Account) The definitive solution. gMSAs are managed by AD, rotate their own passwords automatically every 30 days, and are not subject to user password policies at all. Services running as gMSAs cannot be brute-forced because no human or attacker ever knows the password. Deploy gMSA for every service account that supports it:

# Create a gMSA
New-ADServiceAccount -Name "svc-webapp" `
    -DNSHostName "svc-webapp.domain.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "WebAppServers"

# Install the gMSA on the target server
Install-ADServiceAccount -Identity "svc-webapp"

# Verify installation
Test-ADServiceAccount -Identity "svc-webapp"