How to manage Active Directory password requirements

Password policies are a foundational element of any organization’s security posture, especially in environments managed by Active Directory (AD). These policies help ensure that user credentials meet baseline complexity requirements, reducing the risk of unauthorized access. However, understanding and verifying these requirements—especially with the introduction of fine-grained password policies (FGPP)—can be challenging for IT administrators.

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 guide, we’ll walk through the different ways to check and manage password complexity settings in Active Directory. Whether you’re troubleshooting login issues, auditing security settings, or looking to align with best practices, this article will help you gain clarity and control over your AD password policy landscape.

Understand password policy settings 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).

Find Over 1 Billion Breached Passwords with FREE Password Auditor

Managing password complexity in Active Directory

Active Directory password policies are typically configured through the Default Domain Policy using the Group Policy Management Console (GPMC), or more granularly using Fine-Grained Password Policies (FGPPs). These policies define requirements such as minimum length, complexity, and history.

Password complexity, when enabled, requires that passwords include characters from at least three of the following categories:

• Uppercase letters (A–Z)
• Lowercase letters (a–z)
• Numbers (0–9)
• Special characters (e.g., !, $, #, %)
• Unicode characters (including non-Latin characters)

To check the current domain password policy using PowerShell, run:

powershellCopyEditGet-ADDefaultDomainPasswordPolicy

This command will return key attributes like:

• MinPasswordLength
• PasswordHistoryCount
• ComplexityEnabled
• LockoutThreshold
• MaxPasswordAge

If your environment uses Fine-Grained Password Policies (FGPPs), you can retrieve those settings with:

powershellCopyEditGet-ADFineGrainedPasswordPolicy

These cmdlets provide accurate, domain-level insight into your password settings—unlike older utilities like net accounts, which only report local policy information and can be misleading in a domain environment.

While Active Directory enforces traditional complexity rules by default, it’s worth noting that modern standards, such as NIST 800-63B, no longer recommend complexity requirements due to usability concerns. If you’re aiming to meet current best practices or compliance requirements, consider third-party tools that offer more flexible and user-friendly password policy enforcement.

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.

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:

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.

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.

More control for specific users with FGPP

While traditional domain password policies apply to all users in a domain, Fine-Grained Password Policies (FGPPs) allow you to apply different password and lockout settings to specific users or groups. This is especially useful when you want stricter policies for high-privilege accounts or service accounts.

Viewing FGPPs with PowerShell

To list existing FGPPs, use:

powershellCopyEditGet-ADFineGrainedPasswordPolicy

To see which users/groups a policy applies to:

powershellCopyEditGet-ADFineGrainedPasswordPolicy | Select-Object Name, Precedence, AppliesTo

You can also view detailed policy settings like so:

powershellCopyEditGet-ADFineGrainedPasswordPolicy -Identity "PolicyName" | Format-List

Precedence matters

FGPPs include a precedence value—the lower the number, the higher the priority. If a user is targeted by multiple policies (e.g., they’re in two groups with different FGPPs), the policy with the lowest precedence wins.

Example:

• AdminGroupPolicy (precedence 10)
• ServiceAccountPolicy (precedence 20)

If a user is in both groups, they’ll get the AdminGroupPolicy.

Managing FGPPs in the GUI

You can also manage FGPPs through Active Directory Administrative Center (ADAC):

• Open ADAC
• Navigate to System > Password Settings Container
• From here, you can create, view, or edit FGPPs
• Use the “Applies To” field to assign policies to users or groups

Common pitfalls

• Not enforced unless assigned: FGPPs don’t apply unless explicitly linked to a user or group.
• Domain policy still exists: If a user isn’t targeted by an FGPP, the Default Domain Policy still governs their password settings.
• Confusing results: Use Resultant Set of Policy tools or PowerShell to troubleshoot effective settings.

When should you use FGPPs?

• You want stricter policies for admins, but looser rules for general staff
• You’re managing accounts with service credentials that require longer max ages
• You’re aligning with compliance policies that require segmentation of security controls

Go beyond native AD features with Specops Password Policy

While Active Directory provides basic controls over password complexity and length, its capabilities are limited when it comes to enforcing modern best practices—like banning breached passwords, preventing predictable patterns, or offering dynamic feedback during password creation.

Specops Password Policy extends the native functionality of Active Directory, giving you more powerful, flexible, and compliant password enforcement without complex scripting or infrastructure changes.

With Specops Password Policy, you can:

• Enforce password rules that block leaked, common, or custom blacklisted passwords
• Provide real-time feedback to users as they create passwords
• Meet compliance requirements like NIST, NCSC, and PCI-DSS
• Apply policies based on group membership—without relying solely on FGPPs
• continuousyky scan your AD against our database of over 4 billion compromised passwords

Try Specops Password Policy for free.

Managing AD password requirements: Best practices, pitfalls, & future trends

Best practices:

• Regular reviews & updates:
  Routinely audit AD password policies to ensure they keep pace with evolving security threats and compliance requirements.
• Balance usability and security:
  Strike a balance between password complexity and user convenience to minimize support calls without sacrificing strength. Consider using passphrases instead of passwords.
• Leverage FGPPs:
  Use Fine-Grained Password Policies for high-risk groups (like admin accounts) while retaining simpler rules for general users.
• Implement Multi-Factor Authentication (MFA):
  Complement robust password policies with MFA to enhance overall security.

Common pitfalls:

• Overcomplicating policies:
  Excessively strict or complex rules can frustrate users and lead to increased support issues.
• Policy overlap:
  Conflicts between the Default Domain Policy and FGPPs can cause unintended behavior—regularly validate policy precedence with tools like RSOP.
• Neglecting end-user communication:
  Failing to explain policy changes can create confusion; clear, proactive communication is key. You can find a full guide to communicating policy changes here.

Possible future trends:

• Passwordless authentication:
  Organizations may explore passwordless alternatives like biometrics and one-time codes, which are increasingly adopted to reduce reliance on traditional passwords.
• Adaptive authentication:
  Look into systems that adjust security measures dynamically based on user behavior and contextual risk assessment.
• Enhanced user education:
  As trends shift, empower users with the knowledge to navigate new authentication methods, ensuring smoother transitions and sustained security.

Audit your Active Directory today

While it is definitely good to understand how your Active Directory password settings are put together, Specops Password Auditor is a read-only tool that 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 for free.

FAQs