How to check password complexity requirements in Active Directory
Active Directory password policies are not always what they seem – often there are discrepancies on settings such as password length, 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.
Understanding Password Policy Setting in Active Directory
To ensure password polices are correctly implemented, the sysadmin must first understand the available password policy settings. In Active Directory, there are six available policies.
Enforce password history – with an eye to preventing password reuse, this policy determines how many previous passwords are stored in Active Directory and thus prevented from being set as a password in future.
Maximum password age – sets the maximum length of time a user may go between password resets.
Minimum password length – while the minimum recommended password length is 8 characters, it may also be set at 0. If set at 0, no password will be required.
Minimum password age – prevents users from resetting their password too frequently, perhaps in an attempt to cycle back to an easily remembered password used before.
Password must meet complexity requirements – if the policy is enabled, a user cannot use the account name in a password; 3 types of symbols must be used in the password. Those symbols include: numbers (0–9), uppercase letters, lowercase letters and special characters ($, #, %, etc.).
Store passwords using reversible encryption – user passwords are stored encrypted in the AD database, but in some cases you have to grant certain apps access to user passwords. If this policy setting is enabled, passwords are less protected (almost plain text).
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*
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.
How to enable multiple password policies in Active Directory
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:
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.
Note: Fine-Grained Password Policies can only be applied to individual users or Active Directory Global groups. The Active Directory admin tools will happily allow you to add a Universal or Domain Local group to the list of groups the policy applies to, however those groups will be ignored when it comes to actual enforcement of the fine-grained policy. If you find a fine-grained password policy is not applying to a group as expected, double-check the group scope in Active Directory Users and Computers and ensure it is set to Global.
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.
Frequently Asked Questions
You can find your current AD password policy for a specific domain either by navigating to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Password Policy via the management console, or by using the PowerShell command Get-ADDefaultDomainPasswordPolicy.
Windows Server password policy controls passwords for accessing Windows servers.
Locate the GPO through the Group Policy Management Console and click Edit.
There are six available policies to change in Active Directory: Enforce password history, Maximum password age, Minimum password age, Minimum password length, Password must meet complexity requirements, and Store passwords using reversible encryption.
Yes, although if multiple linked Group Policy Objects (GPOs) have a different password policy setting, the GPO with the highest link order will take precedence.
Microsoft introduced the Fine-Grained Password Policies (FGPP) feature in Windows 2008. FGPP lets administrators configure different password policies based on their Active Directory security groups. FGPP objects are stored under the System\Password Settings Container in Active Directory.
(Last updated on August 22, 2023)