Fine Grained Password Policies

Fine Grained Password Policies (FGPP) are an awesome feature that was introduced with Windows Server 2008. To use FGPPs you will need to ensure that your domain function level is at least Windows Server 2008.

Prior to the introduction of FGPP, you could only have one password policy across the entire domain. To facilitate multiple policies you needed to have multiple domains. This meant that your service accounts, your admin accounts and your standard accounts all had the same policy. If you remember from my post about PingCastle you will remember it highlighted that we didn’t have a FGPP for our service accounts specifying a password of at least 20 characters. We are now going to fix this.

The easiest way to create and manage FGPPs is with Active Directory Administrative Center. FGPPs are known as Password Setting Objects within Active Directory. PSOs are applied to a security group, so we will first create a group to apply the PSO to. You can apply a policy directly to a user, but using groups is easier to delegate access to, and as can be included with RBAC models easily.

Within ADAC, navigate to your domain, then System and look for Password Settings Container. This is where your PSOs live.

Then, in the screen above, click New followed by Password Settings. This will open up the screen for configuring a PSO

In the above example, you can see that I have named the PSO (pso_ServiceAccounts), I have given a precedence of 10. Precedence is used when multiple PSOs apply to a user, settings from each will apply, however if there is a conflict (password length for example), the policy with the lowerst precedence wins.

When you have configured your PSO, click OK. Now any users that are part of the group it applies to have that password policy. PSOs will override the Default Domain Policy, so if you want a setting to match the default domain policy you have to configure it, not leave it unticked. If you re-run PingCastle now, you should notice that the weak password is no longer blue and you should see the PSO listed under Password Policies

If you have changed the expiry of a password (never in the example above for my service account) by using the following PowerShell

Get-AdUser “UserID” -Properties  SamAccountName,PasswordLastSet,"msDS-UserPasswordExpiryTimeComputed" |  Select-Object  SamAccountName,PasswordLastSet,@{Name="ExpiryDate";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}}   

Other use cases for FGPP include for administrative accounts, set a longer password, for those with MFA enabled you will want to reduce the frequency of expiry. Ultimately, FGPPs are invaluable. Your admins should have a much longer password than generic user accounts. Your service accounts should be forced to use longer still passwords, I chose 25 in my example. Password rotation is not a great defense because users are predictable (changing last numerical value for example by incrementing) and if you’re using MFA, blocked legacy authentication methods, why not allow users to only change a password on suspected breach?