Creating Fine Grained Password Policies
Creating Fine Grained Password Policies In this post we will see the steps for Creating Fine Grained Password Policies (FGPP). In Microsoft Windows 2000 and Windows Server 2003 Active Directory domains, you could apply only one password and account lockout policy, which is specified in the domain’s Default Domain Policy, to all users in the domain. As a result, if you wanted different password and account lockout settings for different sets of users, you had to either create a password filter or deploy multiple domains. Both options were costly for different reasons. Starting from Windows Server 2008, you can use fine-grained password policies to specify multiple password policies and apply different password restrictions and account lockout policies to different sets of users within a single domain.
Creating Fine Grained Password Policies
In this post we will see the steps for creating fine grained password policies on Windows Server 2012 R2 domain controller. Once we create FGPP we would be applying it to a group named Laptop Users. This is a test group that consists of few users. I found it very easy to configure a FGPP on domain controller running on Windows Server 2012 R2 than Windows server 2008 R2.
To create FGPP, login to the domain controller using a domain admin account and click on Server Manager. To enable Fine-Grained Password Policies (FGPP), you need to open the Active Directory Administrative Center (ADAC), switch to the tree view and navigate to the System, Password Settings Container. Right-click the Password Settings Container object and select New and click on Password Settings.
Provide a name to the password policy. Set the Precedence attribute value to 2. For the remaining settings fill all of them with appropriate data.
[vc_row][vc_column][TS_VCSC_Info_Notice panel_type=”warning” panel_icon=”ts-awesome-hand-o-right” panel_title=”Note” font_title_family=”Default:regular” font_content_family=”Default:regular” el_file1=””]As per Microsoft, a lower value for the precedence attribute indicates that the PSO has a higher rank, or a higher priority, than other PSOs. For example, suppose an object has two PSOs linked to it. One PSO has a precedence value of 2 and the other PSO has a precedence value of 4. In this case, the PSO that has the precedence value of 2 has a higher rank and, hence, is applied to the object.[/TS_VCSC_Info_Notice][/vc_column][/vc_row]
Now you need to apply this PSO to a group called Laptop Users. Click on Add and browse the group and click OK.
To view the resultant PSO for a user open Active Directory Users and Computers. On the View menu, ensure that Advanced Features is checked. In the console tree, click Users. In the details pane, right-click the user account for which you want to view the resultant PSO, and then click Properties. Click the Attribute Editor tab, and then click Filter. Ensure that the Show attributes/Optional check box is selected. Ensure that the Show read-only attributes/Constructed check box is selected. Locate the value of the msDS-ResultantPSO attribute in the Attributes list.
You can also view the resultant PSO for a user from the command line using dsget command. Open a command prompt & type the following command, and then press ENTER.
dsget user <User-DN> -effectivepso
In the below screenshot we see that the FGPP is applied. The user tries changing the password to a simple password but he gets the error because we did specify in the policy that the password must meet complexity requirements.
Thanks for the post, but how do you apply it for a group in a child domain?
Do you have to remove the policy under the Default domain policy? I cannot get this to work, I made Precedence 1 and have a min password of 10 characters. I pointed this policy to a test user with a password of 8 characters. Signing out and back in and restarting still allowed login with the 8 character pw. I have confirmed the test policy shows up in the account in Attribute editor.
Or does this only take effect the next time a user tries to change their password?
I think here you need to use PSO (Fine grain password setting) going through ADSIedit console.
I did get it to work but only after I set this test account to require change password at next logon. At that point with a log off/on it did get my test policy and not the normal default domain policy. I am more interested in what users will experience so that is the focus of my testing.
I will do another test and simply let it sit for a few days to see if it ever expires on its own. But it’s pretty clear at least in my domain (2012r2) that setting a fine grain policy does not immediately disconnect users if they don’t meet the new requirements.
Using AD Admin Centre, what’s the correct value if I want to set the fine grained password policy so that passwords never expire? Is that 0 here? I’m finding conflicting answers for that. Thanks.
If I add a password policy, where there was none, will it affect users “immediately” or only the next time they try to change their password. Does it depend on which policy is applied? For example, a user has a 6 character password and we implement a minimum of 8 characters. We would like it not to affect users right away, but rather tell users to change their passwords and at that time follow the new password policy. Thanks
I know this is a bit late, but I just had this issue. If the current password is shorter than the new policy stipulates it will force the user to change their password the next time they login and will disable things like access to network shares. The policy makes too short passwords immediately expire.