Active Directory password policies are not always what they seem – often there are discrepancies on settings such as password complexity, maximum password age, or long-forgotten Fine-Grained Password Policies configured in the domain. In this blog post we will review how to check password requirements in Active Directory, including where password policies are configured, and stored.
Active Directory Default Domain Password Policy
This password policy is the default (and prior to Windows 2008 and the introduction of Fine-Grained Password Policies, the only) password policy for users in the domain.
Typically (and by default in a new AD Domain) the built-in Default Domain Policy GPO is used to set the Active Directory password policy as shown in the screenshot above.
However, an important distinction to note is that this GPO only sets the policy in Active Directory. When user passwords are being set AD is not looking at Group Policy but rather at attributes of the root domain object in AD; it is always a good idea to double-check these values to ensure the password policy is set properly.
Let’s look at these attributes using PowerShell. The first command looks at the actual attribute names; the second looks at the same attributes but gives us clearer names and translates the time values e.g. maxPwdAge to a format we can easily understand:
get-addomain | get-adobject -properties * | select *pwd*
Get-ADDefaultDomainPasswordPolicy
In most environments the output here will match what is in the Default Domain Policy. In case they do not, we must fully unpack what AD is doing here:
The password policy is read from Group Policy and applied to these attributes by the domain controller holding the PDC emulator role when it runs gpupdate. But the settings do not have to come from the built-in Default Domain Policy. In reality, these are the criteria for a password policy GPO:
- The GPO must be linked to the root of the domain
- The GPO must be applied to the PDC emulator computer account
If your domain password policy does not line up with the Default Domain Policy GPO, look for another GPO linked at the domain root with password policy settings, and blocked Inheritance on the Domain Controllers OU.
Another GPO linked at the domain root with password policy settings
If multiple GPOs linked at the root have a password policy setting, the GPO with the highest link order will take precedence for that particular setting. Check all GPOs linked at the root for Password Policy settings. For example, here we have added a second GPO called ‘Domain Password Policy’ with a higher link order than the Default Domain Policy and password policy settings. Password Policy settings in this GPO will override those in the Default Domain Policy.
After making this change and running a gpupdate on the PDC, we can see password complexity is now enabled as per the Domain Password Policy GPO:
Blocked Inheritance on the Domain Controllers OU
If Inheritance is blocked on the domain controllers OU, password policy settings from policies linked at the root of the domain will be ignored. In this example we have blocked inheritance on the domain controllers OU and can confirm the Default Domain Policy are not in the Group Policy Inheritance list – this means password policy settings changes in that GPO will be ignored and whatever the current password policy is will be ‘tattooed’ on the domain.
Oddly enough, linking the GPO directly to the domain controllers OU has no effect. The solutions here are either to remove the blocked inheritance on the domain controllers OU or set the link at the root of the domain to ‘enforced’ (which overrides blocked inheritance) – just be mindful of other settings in these GPOs when making changes to inheritance/enforced links. Either way, as long as the policy appears in the Group Policy Inheritance list the settings should take effect.
Keep in mind when troubleshooting password policy GPOs in AD you must run gpupdate on the PDC emulator for each change to take effect.
Fine-Grained Password Policies
In Windows 2008 Microsoft introduced the Fine-Grained Password Policies (FGPP) feature, enabling administrators to configure different password policies based on Active Directory security groups.
Note: We sometimes find administrators attempting to set multiple password policies in AD by creating additional GPOs with Password Policy settings and applying them to user OUs. This does not work in Active Directory; GPOs with Active Directory Password Policy settings linked anywhere but the root of the domain have no effect whatsoever on user password requirements. The reasoning makes sense in some way – Password Policy settings appear under the ‘computer settings’ scope and thus have no bearing on user objects. Still, it is at best a counterintuitive design by Microsoft. Specops Password Policy, on the other hand, uses user-based GPO setting and does directly apply password policy setting objects to user objects where it is applied, making for a much more intuitive administrative experience.
To create or view fine-grained password policies, you can use ADSIEdit, PowerShell, or the Active Directory Administrative Center.
Fine-grained password policy objects are stored under System\Password Settings Container in AD. As fine-grained password policies are not in Group Policy there is no gpupdate required when making changes; they take effect as soon as the settings are configured (excluding any delays in replication among your domain controllers).
Here we have a domain with a single fine-grained policy applied to the Domain Admins group:
To view the policy in PowerShell:
get-adfinegrainedpasswordpolicy -filter *
For members of the groups listed in the ‘applies to’ attribute of the fine-grained password policy, both the password policy and account lockout settings in the fine-grained policy will replace those in the default domain password policy. In case of multiple fine-grained policies applied to any particular user, the precedence value set within each FGPP determines which policy would win.
To confirm which fine-grained policy is applied to a user, search for them in the Global Search in the Active Directory Administrative Center then choose ‘view resultant password settings’ from the tasks menu.
Or using PowerShell:
Get-ADUserResultantPasswordPolicy username
Note if this command does not return any results the user is affected by the default domain password policy and not a fine-grained policy.
Specops Password Auditor
While it is definitely good to understand how your Active Directory password settings are put together, Specops Password Auditor can offer a view into your current Active Directory password policies, their scope, and how they stack up against a number of compliance requirements or recommendations. Password Auditor is available as a free download.
Download Specops Password Auditor from to quickly check password requirements in Active Directory here.
Read a review of Specops Password Auditor here.