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
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.
Resources
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
Get-ADDefaultDomainPasswordPolicy
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.
Conclusion
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.
Hi Robert,
Cool.
One question, we used to use the cmd command “net user” to check the password expired date. once we configured above (eg: password expired dat from 90 -> 30) then net user the account but still show old expired day.
May I know is any way to check the update expired day after the changed?
Hi Alex,
See the article below for steps.
powershell get password expiration date
We have implemented this for our company and it is working great. The one problem is that we sometimes get users who get blocked al the time because they have wrong credentials on and old device that tries to log in automatically. Is there any way to see logs of the login attempts of the user? If we know the device name of the attempt the search would be much easier.
Hi,
See the article below for details and steps.
https://activedirectorypro.com/account-lockout-event-id/
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.
https://activedirectorypro.com/how-to-get-ad-users-password-expiration-date/
Awesome. Thanks Robert!
We have the exact same problem here, we have a FGPP set to expire after 365 days for specific accounts and when I run your method two report, I can see that they are all expiring after 180 days (which is the truth… I received many complaint about it) so FGPP are not working as expected from the Maximum Password Age stand point.
I can confirm that it is working for the password complexity parameter
We had a standard GPO forcing 180 days previously but we decided to get rid of password settings from every GPO and keep only the FGPP method to simplify troubleshooting… it looks like we have a sticky parameter somehow
Any idea?
I just tested this with the following settings.
– GPO password policy maximum password age is set to 42
– Created a FGPP and set the maximum password age to 2. I applied this policy to a specific account.
After 2 days the targeted account was prompted to change their password. So my test worked as expected.
Where do you see they are all expiring after 180 days?
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?
Thanks
Eric
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.
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.
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
Hi, Alexander
Any Fine-Grained Password Policy will override the default domain policy on the scope that the Fine-Grained Password Policy is applied to.
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.