How to check password requirements in Active Directory

According to Verizon's 2026 Data Breach Investigations Report, credential abuse still shows up in 39% of breaches when you account for every stage of the attack chain, making it the single most common technique across the full breach life cycle. Active Directory (AD) password requirements are the rules that determine whether a user's chosen password is acceptable inside a Windows domain. They cover the length, history, age, complexity, lockout behavior, and reversible encryption. Misconfigured settings typically surface as a credential stuffing incident.

This guide covers every method a domain admin can use to read those settings: the Default Domain Policy, the Group Policy Management Console (GPMC), PowerShell, and Active Directory Administrative Center (ADAC) for fine-grained password policies (FGPPs). It also explains how ADSelfService Plus extends those rules with dictionary, pattern, and breach checks that the native tools do not perform.

Where are the password requirements in AD?

AD enforces password requirements at two levels: The Default Domain Policy sets a baseline that applies to every domain-joined account, and FGPPs override that baseline for specific users or groups (which is useful when domain admins, service accounts, or other privileged roles need stricter controls than the rest of the domain). Both policy types control the same eight settings:

• Assign the Authentication Policy Administrator role to the account performing the configuration. This role provides the permissions needed to manage SSPR policies, authentication methods, and registration settings without granting full Global Administrator access.
• Enable at least one authentication method, such as Microsoft Authenticator, SMS, voice call, email OTP, or OATH tokens for password reset verification.
• If you use a hybrid environment and want password changes to sync back to on-premises AD, configure password writeback through Entra Connect.
• Ensure users are licensed appropriately based on your SSPR and password writeback requirements:

The Default Domain Policy applies these settings domain-wide. To enforce stricter rules for specific groups, domain admins, service accounts, and executives, use FGPPs as a per-group override.

Here's what Password must meet complexity requirements actually means:

• The password cannot contain the user's sAMAccountName or any three-or-more-character substring of the display name.
• The password must be at least six characters long, regardless of the Minimum password length value. The higher value takes precedence.
• The password must include characters from at least three of the five categories below:
  • Uppercase letters (A–Z)
  • Lowercase letters (a–z)
  • Numbers (0–9)
  • Non-alphanumeric special characters (!, @, #, $, etc.)
  • Unicode characters categorized as alphabetic but not ASCII uppercase or lowercase

This setting will not block Password123! because that string satisfies three categories. It has no awareness of keyboard walks, palindromes, or known breached password lists.

NIST SP 800-63B (referenced from SP 800-53 Ccontrol IA-5) takes a different position. The guidance recommends the following:

• 15 characters minimum for memorized, single-factor passwords
• Screening every new password against a list of known breached passwords
• No forced periodic rotation unless there is evidence of compromise
• Discouraging composition rules mandating specific character types
• A maximum length of at least 64 characters so passphrases are supported

ADSelfService Plus helps enforce a compliance- and security-aligned policy that extends these native rules. The Password Policy Enforcer adds dictionary word blocking, pattern detection for sequential numbers and keyboard walks, palindrome detection, restrictions on using AD attributes within the password, and a compromised password check against known breach databases.

How to check the Default Domain Policy using the GPMC

The GPMC is the visual route to viewing and editing the Default Domain Policy.

1. Open the GPMC: On a domain controller (DC), open Run, type gpmc.msc, and press Enter. You can also launch it from Server Manager > Tools > Group Policy Management. On a Windows 10 or 11 workstation, install Remote Server Administration Tools (RSAT) first, without which gpmc.msc will not be available.
2. Navigate to the policy: Navigate to Forest > Domains, select your domain, then click Default Domain Policy.
3. Open the editor: Right-click the policy and select Edit. The Group Policy Management Editor will open in a new window.
4. Find the password settings: Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy. The right pane will display the eight settings from the table above, each with its current value.
5. Read or change a value: Double-click a setting to view its description and edit the value. For the length, enter a number. For the complexity, toggle to Enabled or Disabled. Click OK to save.

Changes apply domain-wide and take effect after Group Policy refreshes on each DC—90 minutes by default with a 30-minute offset. Run gpupdate /force on the target machine to apply the changes immediately.

A note on OU-linked GPOs

If your domain has multiple GPOs linked at different OUs, the password policy must still come from a GPO linked at the domain level. Linking a password policy GPO to an OU has no effect on domain user passwords. The only way to vary password rules below the domain root is through an FGPPs.

How to view FGPPs in ADAC

FGPPs let you enforce stricter rules for specific users or groups, such as longer passwords for domain admins or no expiration for service accounts, without affecting the rest of the domain. Each FGPP is stored as a Password Settings Object (PSO) and contains the same eight settings as the Default Domain Policy, plus two additional fields:

• Precedence: This determines which PSO wins when more than one targets the same user. The lowest value takes priority. Tied precedence resolves to the lowest GUID. A PSO always overrides the Default Domain Policy for any user it covers.
• AppliesTo: This identifies the users or global security groups that the PSO targets. PSOs cannot be applied to OUs; add a security group instead.

To view the FGPPs:

1. Open the console: Launch ADAC by running dsac.exe or opening it from Server Manager > Tools.
2. Switch to the tree view: On the left pane, select Tree View and expand your domain.
3. Navigate to the Password Settings Container: Navigate to System > Password Settings Container. All PSOs in the domain will be listed on the right pane.
4. Inspect a PSO: Double-click any PSO to view its full settings, its precedence value, and the users or groups to which it applies.
5. Check the resultant policy for a specific user: To see which policy actually governs a given account, open the user object in ADAC, scroll to the Extensions section, and select the Resultant Password Settings tab. This resolves all PSO precedence logic and shows the effective policy for that user. If no PSO applies, the user inherits the Default Domain Policy.

PSO limitations to be aware of

FGPPs add granularity, but they don't extend what AD's password engine can evaluate. Neither the Default Domain Policy nor a PSO can screen a candidate password against a breach corpus, block dictionary words, or reject keyboard walks or sequential patterns. Those checks require enforcement that runs at the moment the user enters a new password—something that neither the GPMC nor ADAC provides but that can be achieved with ADSelfService Plus.

How do you check password requirements for AD in PowerShell?

Here is a quick guide to using PowerShell to check the AD password requirements.

Prerequisite: Install the AD PowerShell module

To install the module in Windows Server 2012 R2 or later

Use this PowerShell script:

• Install-WindowsFeature: Installs server roles and features; requires elevation
• RSAT-AD-PowerShell: The AD PowerShell module feature name

To install the module in Windows 10 (version 1809 and later) or Windows 11

Use this PowerShell script:

• Add-WindowsCapability: Installs an optional Windows capability
• -Online: Targets the running OS
• -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0: The RSAT AD tools capability name for which the tildes and version string are required

To install the module in Windows 10 versions before 1809

From the Microsoft Download Center, download the RSAT package matching your Windows 10 version and architecture, then enable the Active Directory Domain Services (AD DS) tools via Control Panel > Programs > Turn Windows features on or off > Remote Server Administration Tools > Role Administration Tools > AD DS and AD LDS Tools.

To install the module in Windows 8.1 or below

Download RSAT for Windows 8.1 from the Microsoft Download Center, then enable it via Control Panel > Programs > Turn Windows features on or off > Remote Server Administration Tools > Role Administration Tools > AD DS and AD LDS Tools > Active Directory Module for Windows PowerShell.

To load the Active Directory module after installation

Use this PowerShell script:

• Import-Module: Loads the module into the current session; runs automatically in Windows Server 2012 R2 and later; must be run explicitly in older systems
• ActiveDirectory: The module name

How to get the default domain password policy using PowerShell

To get the eight values from the Default Domain Policy, use this PowerShell script:

Here is a sample of the output you will receive:

• ComplexityEnabled: Whether the Windows complexity requirement is enforced (three of five character types; no username segments)
• DistinguishedName: The LDAP path of the domain object the policy is attached to; confirms which domain was read—useful in multi-domain forests
• LockoutDuration: How long an account stays locked after hitting the threshold (hh:mm:ss), with 00:00:00 meaning locked until an admin manually unlocks it
• LockoutObservationWindow: The rolling window in which failed attempts count toward the threshold; resets after this period of no failures
• LockoutThreshold: The failed attempts before the lockout, with 0 disabling the lockout
• MaxPasswordAge: The days before a password expires (days.hh:mm:ss), with 0 disabling expiration
• MinPasswordAge: The minimum days before a user can change their password again; prevents rapid cycling to a previous password
• MinPasswordLength: The minimum character count, with 0 disabling the requirement
• PasswordHistoryCount: The number of previous passwords blocked from reuse
• ReversibleEncryptionEnabled: Stores passwords in reversible (effectively plaintext) format; should always be False

How to view FGPPs using PowerShell

To get every PSO in the domain, use this PowerShell script:

• -Filter *: This returns every PSO. Narrow with -Filter {Name -eq "AdminPSO"} for a specific policy.

Here is a sample of the output you will receive:

• Name: This is the PSO's display name.
• Precedence: This determines which PSO applies when multiple PSOs target the same user. No two PSOs should share a value.
• MinPasswordLength, PasswordHistoryCount, and ComplexityEnabled: These are the same fields as in the Default Domain Policy, scoped to the users or groups in AppliesTo.
• AppliesTo: This defines the users or global security groups the PSO is linked to. PSOs cannot be applied directly to OUs.

This returns the effective policy for a named user after FGPP resolution. If the user is covered only by the Default Domain Policy, this cmdlet returns $null. That is expected behavior—run Get-ADDefaultDomainPasswordPolicy to confirm what policy they inherit.

Quick check tools beyond the GPMC

• secpol.msc opens Local Security Policy, which is useful on stand-alone or non-DC machines.
• net accounts prints a compact summary of the current domain password and lockout settings from any joined workstation.
• gpresult /h report.html produces an HTML report of every GPO applied to the current machine and user. Open the file to identify which GPOs are delivering the password policy.

Account lockout settings

The lockout settings are located alongside the password policy under Account Policies. Three settings are relevant:

• LockoutThreshold: The failed attempts before the account locks, with 5 being a common value
• LockoutDuration: How long the account remains locked; typically set equal to the observation window
• LockoutObservationWindow: The window within which failed attempts are counted

PSOs are effective but carry administrative overhead: schema-aware ACLs, per-PSO precedence calculations, and no OU inheritance. ADSelfService Plus provides the same targeting granularity with less complexity—policies can be set at the OU or group level from a single console, without PSO configuration or precedence management.

Troubleshooting password policy issues in AD

• Policy changes have not reached every DC: Run repadmin /replsummary to assess the replication health across the forest. If a DC is lagging, run repadmin /syncall /AdeP to force synchronization. Until replication completes, users authenticating against an out-of-date DC will see the previous policy.
• Get-ADDefaultDomainPasswordPolicy term not recognized: The RSAT AD PowerShell module is not installed. Install the module.
• Get-ADFineGrainedPasswordPolicy returns nothing: Either no PSOs exist in the domain, or the account does not have read access to the Password Settings Container. Check the ACLs on CN=Password Settings Container,CN=System,DC=....
• Get-ADUserResultantPasswordPolicy cannot find an object with the identity: The username or DN is incorrect. Use the sAMAccountName exactly as it appears in Active Directory Users and Computers (ADUC) or the full distinguished name.
• The policy is not applying as expected: Check for a PSO with a lower precedence value covering the same user, verify that the Default Domain Policy is linked at the domain root and set to enforced, and run gpresult /h report.html on the affected machine to confirm which GPOs are in effect.

Enforce advanced password requirements with ADSelfService Plus

The native AD password policy is limited to length, history, age, complexity categories, lockout, and reversible encryption settings. It does not evaluate dictionary words, recognize palindromes, or reference breach data. Those gaps are where most weak password compromise originates.

ADSelfService Plus addresses this with the Password Policy Enforcer, an enforcement layer applied at every point where a password is created or changed. Where native policy reaches its limits, ADSelfService Plus adds:

• A dictionary filter that blocks passwords containing common words.
• A pattern checker that rejects sequential numbers, keyboard walks, and palindromes.
• A compromised password detector that validates new passwords against known breach lists.
• AD attribute restrictions that prevent users from incorporating their name, username, or email address into the password.
• Per-OU and per-group policy targeting without PSO configuration.
• Character-type minimums that go beyond the native three of five rule (for example, requiring at least two digits).
• Real-time complexity feedback displayed to users as they type, reducing failed reset attempts.

These rules apply at the Windows Ctrl+Alt+Del change password screen, the ADUC console, the ADSelfService Plus web portal, and the mobile app, so users cannot bypass enforcement by switching to a different channel.

Multi-factor authentication (MFA) provides a complementary layer. ADSelfService Plus enforces MFA on self-service password reset, account unlock, and directory update flows as well as on Windows, macOS, and Linux logins via the Endpoint MFA add-on. Strong password rules reduce exposure from guessable credentials; MFA addresses stolen ones.

Where native AD reaches its limits, ADSelfService Plus picks up, with breach screening, pattern detection, dictionary filtering, and AD attribute restrictions applied at every point where a password is created or changed. Per-OU and per-group targeting gives you FGPP-level granularity without PSO configuration overhead.

Frequently asked questions

What are the NIST SP 800-63B password requirements?

NIST SP 800-63B moves away from the complexity rules most organizations are used to. The key requirements: a minimum eight characters, a maximum of at least 64 to support passphrases, mandatory screening against known breached password lists, and blocking dictionary words, repetitive strings, and context-specific passwords like those containing the username. Forced periodic rotation is explicitly discouraged unless there is evidence of compromise, and mandatory character type rules are not recommended. Native AD satisfies some of these requirements by default but has no mechanism for breach screening, dictionary blocking, or pattern rejection—those require a third-party enforcement layer.

What are event IDs 4723 and 4724?

Both are Windows security log events related to password activity in AD. Event ID 4723 is when a user attempts to change their own password; whether the attempt succeeds or fails, the account, domain, and originating workstation are logged. Event ID 4724 is when an administrator resets another user's password. Failed attempts for either ID typically mean the new password didn't meet policy requirements. Neither event is logged unless the audit policy is configured to track account management events; you can enable this under Advanced Audit Policy Configuration > Account Management > Audit User Account Management.

Can you see passwords in AD?

No. AD stores passwords as hashed values, and no built-in tool—ADUC, ADAC, or PowerShell—exposes them. The only exception is if Store passwords using reversible encryption is enabled; this stores passwords in a decryptable form and should never be on. Administrators can reset a password without knowing the current one, but that is not the same as retrieving it—the original credential is never exposed.