Until not long ago if you wanted to assign different passwords policies to different users, you were forced to create a new domain in the forest. Starting with Windows Server 2008, Microsoft came with fine-grained password policies (FGPPs) a functionality that will let you have different passwords policies in a single domain. This means you can have complex passwords for your admins, not so complex passwords for your users, and extremely complex passwords for your enterprise admins in a single domain. Fine-grained password policies you create are represented by password settings objects (PSOs) within Active Directory which are standard Active Directory objects stored under the System container in the domain partition. An awesome thing is that you can create a global security group for each PSO and place the users to whom the PSO will apply in this group. You can also use the existing global security groups, but is recommended that you create new groups dedicated just to application of PSOs. In order for this to work your domain functional level needs to be at the Windows Server 2008 or better domain functional level. Windows Server 2003 and earlier versions of Windows domain controllers are not capable of enforcing this functionality. While you can create and manage PSOs before your domain is running at this functional level, the policies will have no effect on users. In Windows Server 2008/R2 there was no graphical interface to configure fine-grained password policies, you had to use the ADSI Editor. In server 2012 you can do this from the Active Directory Administrative Center and off course PowerShell.
From the Active Directory Administrative Center go to System > Password Settings Container
Complete the boxes with the values you think are right for your environment then add a user or group to apply this PSO to. As you can see I added a global security group and not a user which is the recommended approach.
Things to remember:
– You can’t apply fine-grained password policies to OUs.
– Only global security groups are applicable for applying a PSO to a user. If you link a PSO to a universal or domain local group, it will be ineffective and not actually be considered for application to the user in the resultant PSO calculation.
– If you assign multiple PSOs to a user and that user is a member of multiple groups linked to different PSOs, the PSO with the lowest precedence will win.
– In the case of multiple PSOs with the same precedence, the PSO with the smallest GUID will win.
– If a user has PSOs applied to him both by groups and directly to his user object, the PSO applied to the user object will always win.
When done, click OK and your PSO should be created and visible in the Active Directory Administrative Center.
If you want to use PowerShell, this can be accomplished with the New-FineADGrainedPasswordPolicy command:
New-ADFineGrainedPasswordPolicy -Name “Local IT Support PSO” -Precedence 20 -ComplexityEnabled $true -Description “Domain password policy for local IT support team”-DisplayName “Local IT Support PSO” -LockoutDuration “0.15:00:00” -LockoutObservationWindow “0.00:30:00” -LockoutThreshold 5 -MaxPasswordAge “20.00:00:00” -MinPasswordAge “1.00:00:00” -MinPasswordLength 5 -PasswordHistoryCount 3 -ReversibleEncryptionEnabled $false
“Windows cannot complete the password change for “user” because: The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.”
If the actual user tries to change his password and the password does not comply with the password policy, the operation will also be unsuccessful. Here my username had a password of “a” before the new PSO was applied to the user. Once the policy was in effect I tried to change the user password with “123” but I get an error message since the password does not meet the password policy requirements:
“Unable to update the password. The value provided by the new password does not meet the length, complexity, or history requirements of the domain.”
So it’s working, and we didn’t have to create different domains for this. As you can see in server 2012 creating fine-grained password policies is a piece-of-cake, since Microsoft provided a nice and elegant GUI for this.
Want content like this delivered right to your