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. Show
Understanding Password Policy Setting in Active DirectoryTo 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 PolicyThis 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: 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:
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 DirectoryIf 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 OUIf 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 PoliciesIn 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: 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. Specops Password AuditorWhile 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. Jul 20, 2020 (Last updated on August 17, 2022) Darren SiegelDarren Siegel is a cyber security expert at Specops Software. He works as a lead IT engineer, helping organizations solve complex challenges within IT security. Darren has more than 15 years’ experience within Active Directory, IT security, servers, storage, virtualization, cloud, and identity and access management. What password must meet complexity requirements?Best practices. Set Passwords must meet complexity requirements to Enabled. This policy setting, combined with a minimum password length of 8, ensures that there are at least 218,340,105,584,896 different possibilities for a single password. This makes a brute force attack difficult, but still not impossible.
What are the requirements for a password?CHARACTERISTICS OF STRONG PASSWORDS. At least 12 characters (required for your Muhlenberg password)—the more characters, the better.. A mixture of both uppercase and lowercase letters.. A mixture of letters and numbers.. Inclusion of at least one special character, e.g., ! @ # ? ]. What makes a complex password?Complex passwords should contain a good mixture of upper/lower case letters, numbers, and symbols. Passwords should also not be based on dictionary words and should contain at least seven characters (the longer the better).
How do you fix this password does not meet the length complexity age or history requirements of your corporate Password Policy?In the Local Security Policy console, navigate to Account Policies > Password Policy. On the right pane, double-click Password must meet complexity requirements. Select Disabled > click Apply > click OK and close the Local Security Policy console.
|
