In this guide, you will learn how to create a fine grained password policy in Active Directory.
I’ll show you to methods.
The first method will use the Active Directory Administrative Center Console (GUI) and the second will be using PowerShell.
In addition, I’ll show you how to quickly check what password policies you have in your domain.
What is the purpose of Fine Grained Password Policy?
Active Directory is configured with a single password policy that is applied to all user accounts, this policy is defined in the default domain policy.
There are times when you need a group of users to have a different password policy. For example, you might want to have your privileged accounts (domain admins) have a much stronger password than regular user accounts.
With fine grained password policies, you can easily target specific users or groups and assign them a separate password policy.
Method 1: Create Fine Grained Password Policy Using ADAC
Step 1: Install Remote Server Administrator Tools (RSAT)
You may already have this installed, if not you will need it. It will be needed if you use the ADAC console or PowerShell.
If you need install steps then check out my guide -> Install RSAT on Windows 10.
Step 2: Open Active Directory Administrative Center
Step 3: Create a Policy
Follow these steps to create a new policy.
1. In ADAC click on your domain.
2. Click on the System folder.
3. Click the Password Settings Container
Click on the password settings container then New -> Password Settings
You should now be at the Create Password Settings screen.
Now you can configure the policy settings and apply it to a user or group. You have the same password policy settings as you do in the default domain policy.
In this example, I want to set a stronger password for my server administrators.
I named my password policy “Server-Admin-PW-Policy” and the precedence of 1.
Then I changed the minimum password length to 15 and set the account lockout policy.
Now it just needs to be applied to a user or group.
Click on add.
Select users or group. In this example, I’m assigning this to a group called “Server-Admins”
Click OK on the Create Password Settings screen.
Done. You have completed creating a fine grained password policy.
Method 2: Create Fine Grained Password Policy Using PowerShell
The cmdlet New-ADFineGrainedPasswordPolicy is used to create new Active Directory fine grained password policies.
In this example, I’m just changing the minimum password length, gave the policy a name and assigned it precedence 1.
New-ADFineGrainedPasswordPolicy -name "Server-Admins-Policy" -Precedence 1 -MinPasswordLength 15
Now the policy is created it needs to be assigned to users or a group.
Add-ADFineGrainedPasswordPolicySubject -Identity "Server-Admins-Policy" -Subjects "server-admins"
-identity is the name of the policy and -subject is the name of the group or user you want the policy assigned to.
New-ADFineGrainedPasswordPolicy – Complete command syntax
Add-ADFineGrainedPasswordPolicySubject – Complete command syntax
How to View Fine Grained Password Policies
It is pretty strange that you can create the password policy in the console but it provides no way to view the policies. (If there is a way please post it in the comments below).
No problem we can use PowerShell to view all domain password policies.
Check Fine Grained Password Policies
Get-ADFineGrainedPasswordPolicy -filter *
The above command will display all domain fine grained password policies.
Get the Resultant Password Policy for a User
Get-ADUserResultantPasswordPolicy -Identity UserName
Use this command if you have multiple fine grained passwords defined. This will show you which one is being applied to the user.
Get the Default Domain Password Policy
Another option to view the fine grained password policies is by using the Active Directory Reporting Tool.
Click on Reports -> Security -> Fine grained password policy
Click run and you will see a list of all domain fine grained password policies.
You can see above the tool is showing I have 3 fine grained password policies. The Active Directory Reporting tool includes over 200 pre built Active Directory Reports.
Prior to Windows Server 2008, managing multiple password policies was very difficult. With fine grained password policies, you can easily create custom password policies for specific users or groups. This is beneficial so you can stay in compliance with industry regulations (PCI, HIPPA, SOX, etc) or define stronger passwords for a subset of users such as anyone that has privileged rights.
12 thoughts on “Create Fine Grained Password Policy (Step-by-Step-Guide)”
Thank you for this guide, it will help out a lot.
My problem is, trying to convince my colleagues here to do this as opposed to making GPOs for each group. What would happen if they continue to make a GPO for each group? We have multiple sites at my company and they want to put a policy in place for each site for password requirements, so I’d like to know what the main issue with that is so I can try and convince them to do this.
Thanks again for the guide, I just hope my powers of persuasion work well here!
I’m pretty sure you can only have one domain password policy. Even if they create multiple policies and apply them to an OU, only the password policy in the default domain policy will apply. That is why fine-grained password policies should be used to create multiple pw policies.
Will creating password using the tool and assign to AD groups will this over write the password policy already setup under GPO default policy or will I need to turn if off on GPO default Domain policy
and by the way thank you so much for all the information you are providing
it is very helpful better than what MS provides
Any Fine-Grained Password Policy will override the default domain policy on the scope that the Fine-Grained Password Policy is applied to.
Is there any drawback or negative effects to assigning a FGPP to the Domain Users group(everyone basically)? I want the Default Domain Policy(DDP) for all standard user passwords to be above the 14 character limit. I’m below the 2016 DFL which doesn’t have this problem and cannot go up to that level just yet. While using Powershell to set the limit above 14 characters works, I have numerous servers(not all) that complain about this when they run gpupdate and the servers don’t set the local password policies correctly to match the domain policy. They stay with the OOB settings. My thought is to revert the DDP to 14 to make the servers happy then use FGPP to set everyone to 15 characters. This would be in the neighborhood of 20,000 users.
If it was me I would try to fix the servers that are complaining. Google the error, I bet there is a fix for it. If you cannot find a fix then FGPP should work, I can’t think of any negative effects to this but I’ve also never applied it to the entire domain users group. If you go this route to me it’s a workaround and you should get those complaining servers fixed and revert back to using the default domain policy.
Local Policies and domain controller password policies are two separate things.
The domain policy controls the passwords on a domain controller, the FGPP also controls domain accounts.
When you do a GP result, your seeing what the controls are for local passwords on the specific server. Windows allows you to have user accounts on member servers that are not domain wide, and those are controlled by what your seeing in the RSOP for the member server.
Hi There, Thanks for the article… want to remove an FGP that was setup as a test by a previous admin. Is there a safe way to do it? Users will just revert to the Default Domain Policy?
– Remove Group from Policy
– Delete Policy?
I would remote what the FGP policy is applied to but don’t delete the actual policy. It should revert to using the default domain policy, if something goes wrong you can just re-apply the FGP.
Thanks for this article. Very helpful. I have one question/comment. I have setup a fine grained policy with a 20 character minimum that expires ever 365 days and applied it to a group for testing. I know the minimum character portion is working, but I don’t know how to tell if the 365 day expiration setting is taking. When I run net user /domain username, on a user that is the group for the fine grain policy group, it still says that their password will expire in 45 days. Is this normal or did I not set it up properly? When I run Get-ADUserResultantPasswordPolicy -Identity username the MaxPasswordAge is 365. But it would be nice to run a command and see that the password does not expire for 365. Thanks in advance!
See if method two works from this article.
Awesome. Thanks Robert!