Microsoft password policies: GPO-based vs. fine-grained policies

Microsoft has two solutions for deploying the requirements for Active Directory domain users passwords. The requirements, referred to as the password policy, can be deployed through Group Policy Objects (GPOs) or through Active Directory objects called fine grained password policies (FGPPs). Both solutions have the same list of constraints, such as minimum password length and maximum password age, but the details around the implementation are radically different.

Deploying a password policy using a GPO is the seasoned solution, since it was introduced when Active Directory was released in 2000. By default, the password policy is configured in the Default Domain Policy, which is linked to the domain node. Figure 1 illustrates what the password policy has been for the past ten or more years.

Figure 1. Password policy configurations in the Default Domain Policy.

Although the password policy can be configured in any GPO and linked to any node within Active Directory, the only password policy settings that will be applied to domain users will be in GPOs linked to the domain, containing password policy settings, and with the highest priority. Therefore, there can be only one password policy for all of the domain users in a single domain. To see the resulting password policy, you can run secpol.msc from the command line of any of the domain controllers in your domain. The result can be seen in Figure 2.

Figure 2. Resulting password policy deployed using a GPO as shown by the secpol.msc command.

FGPPs, on the other hand, are not deployed by using a GPO in any way. Instead, FGPPs are defined inside of Active Directory by creating a Password Settings Container. This can be accomplished by using ADSIEdit.msc from a domain controller in the domain. You can see the Password Settings Container in Figure 3.

Figure 3. Password Settings Container allows the creation of FGPPs.

Right-clicking on the Password Settings Container allows you to create a new object, which then walks you through a wizard that helps you define the settings. The settings for FGPPs are the same as for the password policy deployed through a GPO (see Figure 2 for those settings), but instead of directly modifying each setting, the wizard prompts you for each setting.

There can be more than one FGPP, allowing for more than one password policy for domain users in the same domain. To target which users receive the appropriate FGPP, the msDS-PSOAppliesTo attribute of the newly created FGPP object needs to be configured with the appropriate group(s). More than one group can receive a single FGPP. If there is a user that does not receive a FGPP through group membership, the password policy deployed through the GPO linked to the domain will be applied to that user. Each FGPP has a priority configuration, so if a user is part of more than one group listed as the msDS-PSOAppliesTo attribute on the FGPPs, the user will receive only the password settings contained in the highest priority FGPP for which a group they have membership in is listed.

A few clarifying notes:

1. There can be only one password policy if you use the password policy settings in a GPO.
2. A GPO linked to an organizational unit (OU) will not affect domain users located in that OU.
3. No additional settings can be configured for the password policy, except those listed in Figure 2.
4. A new password policy filter can be created and implemented for the domain, but this requires significant development and configuration.
5. FGPPs do not provide any additional password policy controls other than those listed in Figure 2.

As you can see, both Microsoft solutions are a little confusing, but effective. If you want more than the basic password policy configurations, you will need to look at other solutions. In our next blog post, we will compare these two Microsoft solutions to ADSelfService Plus, which offers more granular controls and deployment through OUs. To get your sneak peak at ADSelf Service Plus now, download it here.