Password policies in AD: default policy, fine-grained PSOs and length over complexity
Many domains still apply a single eight-character complexity policy, identical for an intern and a domain administrator. Yet Active Directory has long allowed different requirements for different accounts. Here is how to structure a realistic policy.
The default domain policy
For domain accounts, password and lockout settings are only read from a GPO linked to the domain root, usually the Default Domain Policy. A password GPO linked to an OU only affects local accounts on the machines in that OU: a frequent source of confusion. There is therefore only one "baseline" policy per domain.
Fine-grained policies (PSOs)
Password Settings Objects let you define different requirements for specific accounts. They apply to users or global security groups, not to OUs. When several apply, the msDS-PasswordSettingsPrecedence attribute decides: the lowest value wins.
New-ADFineGrainedPasswordPolicy -Name 'PSO-Admins' -Precedence 10 ` -MinPasswordLength 16 -ComplexityEnabled $true ` -LockoutThreshold 10 -LockoutDuration '00:30:00' ` -LockoutObservationWindow '00:30:00' ` -ReversibleEncryptionEnabled $false Add-ADFineGrainedPasswordPolicySubject 'PSO-Admins' -Subjects 'Tier0-Admins'
Typical uses:
- admin accounts: a significantly longer minimum than for users;
- service accounts that cannot be gMSAs: very long, randomly generated passwords;
- standard users: the baseline policy, aligned with current guidance.
PSOs also let you go beyond the historical 14-character limit of the GPO editor.
Length over complexity
Guidance from ANSSI and NIST broadly converges: length adds more than composition rules, which push users towards predictable patterns. NIST also advises against forced periodic changes without evidence of compromise and recommends rejecting passwords known to be compromised. Exact thresholds vary between documents and versions; what matters is favouring passphrases, pairing the policy with weak password filtering, and using multi-factor authentication wherever possible.
Account lockout: finding the balance
A threshold that is too low lets anyone lock accounts out in bulk. No lockout at all leaves the field open to password spraying. A moderate threshold, a limited lockout duration and an automatic counter reset are usually a reasonable compromise, backed by an alert on spikes of authentication failures.
Avoid. The "Store passwords using reversible encryption" setting is close to storing passwords in clear text. It must be disabled in the default policy, in every PSO, and on every account where the option may have been ticked individually.
What an audit checks
- The effective settings of the default policy and every PSO.
- Whether privileged accounts are covered by a stronger policy.
- Accounts with reversible encryption, password not required or password never expires.
- Consistency between the written policy and the actual configuration.