Short answer: The default password policy in Windows Server 2019 requires 7 characters with complexity. It remembers 24 passwords and expires them after 42 days. Change it in the Default Domain Policy, under Account Policies. For specific groups, we'd use fine-grained password policies and PowerShell.
The password policy in Windows Server 2019 is set in the Default Domain Policy for domain accounts and in Local Security Policy on a standalone server. A sign-in screen, and it wants a new password again. Which password variation is due this month? The admin has it no easier. Security wants unbreakable passwords, and users are close to mutiny. Set right, that same policy is how both sides get out of that mess.
Domain accounts: Default Domain Policy. Standalone servers: Local Security Policy.
Out of the box it remembers 24 passwords and expires them after 42 days. Changes are blocked for 1 day. Seven characters are required, and complexity is on.
You change it in Group Policy Management, or with PowerShell. Fine-grained policies cover groups that need different rules. On a Windows Server 2019 domain it takes less clicking than you’d expect.
| Point | What to know |
|---|---|
| Where domain rules come from | A GPO linked at the domain root, normally the Default Domain Policy; GPOs linked to OUs only affect local accounts |
| Minimum length | The default of 7 is weak; 14 is the maximum the classic setting accepts on Server 2019 |
| Fine-grained password policies | Stricter rules for admins and service accounts, including lengths above 14 |
| Current NIST guidance | Long passwords, no forced periodic changes, no composition rules, plus MFA |
Default password policy in Windows Server 2019
These are the values in the Default Domain Policy of a fresh domain. Note the last row: accounts are never locked out by default.
| Policy setting | Default (domain) | Common modern choice | Why |
|---|---|---|---|
| Enforce password history | 24 passwords | 24 | Stops cycling back to old passwords |
| Maximum password age | 42 days | 0 (never) with MFA, or 365 days | Forced changes breed predictable patterns |
| Minimum password age | 1 day | 1 day | Stops users cycling through history in minutes |
| Minimum password length | 7 characters | 14 (the classic maximum) | Length beats complexity |
| Password must meet complexity requirements | Enabled | Enabled, unless you move to long passphrases with a blocklist | Basic protection against dictionary words |
| Store passwords using reversible encryption | Disabled | Disabled | Close to storing passwords in plain text |
| Account lockout threshold | 0 (never lock) | 10 invalid attempts | Microsoft’s security baselines use 10 |
At first glance the defaults look okay. In practice a 7-character password typically falls to modern cracking hardware quickly, complexity or not.
And the 42-day expiry? Users often rotate through Spring2025!, Summer2025!, Autumn2025!. That defeats the whole purpose.
Defaults give you a starting point, nothing more. The right values depend on your real threats and on how your people work.
What the complexity setting demands
- The password can’t contain the user’s account name.
- It can’t contain parts of the full name longer than two characters.
- It must use characters from three of four groups.
| Character group | Examples |
|---|---|
| Uppercase letters | A to Z |
| Lowercase letters | a to z |
| Digits | 0 to 9 |
| Symbols, or other Unicode letters | ! $ # % |
How to change the password policy in Windows Server 2019 with Group Policy
- Sign in to a domain controller, or to a management PC with Remote Server Administration Tools.
- Run
gpmc.mscand expand Forest, Domains, your domain. - Right-click Default Domain Policy and select Edit.
- Go to Computer Configuration, Policies, Windows Settings, Security Settings, Account Policies, Password Policy.
- Double-click each setting, tick “Define this policy setting” and enter the value.
- Do the same under Account Lockout Policy, if you plan to use lockouts.
- Force a policy update on a domain controller, or wait for the next refresh.
gpupdate /forceDomain controllers refresh every 5 minutes by default.
| Setting | What it controls |
|---|---|
| Enforce password history | How many old passwords are blocked |
| Maximum password age | When a change is forced; 0 means never |
| Minimum password age | How long before a user may change again |
| Minimum password length | The shortest acceptable password, from 0 to 14 |
| Password must meet complexity requirements | The character-mix rule described above |
| Store passwords using reversible encryption | Leave it disabled unless an old app truly needs it |
Password rules for domain accounts only work from a GPO linked at the domain level. Linked to an OU, they change only local accounts on computers there. Domain users aren’t touched. For different rules per group, we’d use fine-grained password policies.
New rules apply to new passwords. Existing passwords keep working until they’re changed or expire. So a stricter length takes effect gradually, unless you force resets.
Our guide on how to change a Windows Server password covers forced resets in bulk with PowerShell.
On a standalone server
On a server that isn’t in a domain, the same settings live in Local Security Policy. Run secpol.msc and open Account Policies, Password Policy.
The command line works too. The first line shows the current values, and the second changes them.
net accounts
net accounts /minpwlen:14 /uniquepw:24Domain policy overrides these on member servers.
Fine-grained password policies in Windows Server 2019
They’re called FGPP for short, and they’re stored as Password Settings Objects. They set different password and lockout rules for specific users or global security groups, in the same domain.
Use them when admins, service accounts or regulated teams need stricter rules than everyone else. The domain functional level has to be Windows Server 2008 or higher.
Different people need different rules. An admin with Domain Admin rights needs far stricter controls than someone in HR.
- Open Active Directory Administrative Center with
dsac.exe. - Go to your domain, System, Password Settings Container.
- In the Tasks pane choose New, Password Settings.
- Enter a name, a precedence number and the password and lockout values.
- Under “Directly Applies To”, add the users or the global security groups.
- Click OK. Then check a user with the cmdlet below.
Get-ADUserResultantPasswordPolicy -Identity jsmithPrecedence decides the winner when a user falls under several policies. The lower number wins, so precedence 1 beats precedence 10.
A policy linked directly to a user beats any linked through a group.
FGPP can’t be linked to OUs. That catches people out. Put the users in a “shadow” group and link the policy to that.
| Who | Typical rule |
|---|---|
| Privileged accounts | Passwords of 20 characters or more |
| Standard users | Moderate rules, through the Default Domain Policy |
| Service accounts that can’t use gMSA | Long random passwords and no lockout |
| Teams with access to regulated data | Strict controls |
Keep it simple. Too many policies generally create management chaos. Map users by risk level and create only the ones you need. Three is plenty for most domains.
Managing the password policy with PowerShell
The ActiveDirectory module has four cmdlets for this. PowerShell suits large or multi-domain environments and repeatable builds.
| Cmdlet | What it does |
|---|---|
Get-ADDefaultDomainPasswordPolicy |
Shows the domain policy |
Set-ADDefaultDomainPasswordPolicy |
Changes it |
New-ADFineGrainedPasswordPolicy |
Creates a fine-grained policy |
Add-ADFineGrainedPasswordPolicySubject |
Applies it to a group |
View the current domain settings, then change them:
Get-ADDefaultDomainPasswordPolicy
Set-ADDefaultDomainPasswordPolicy -Identity contoso.com -MinPasswordLength 14 -PasswordHistoryCount 24 -LockoutThreshold 10 -LockoutDuration 00:15:00 -LockoutObservationWindow 00:15:00Create a fine-grained policy and apply it to a group:
New-ADFineGrainedPasswordPolicy -Name "PrivilegedAccounts" -Precedence 10 -MinPasswordLength 20 -MinPasswordAge "1.00:00:00" -MaxPasswordAge "365.00:00:00" -PasswordHistoryCount 24 -ComplexityEnabled $true -LockoutThreshold 5 -LockoutDuration "00:30:00" -LockoutObservationWindow "00:30:00"
Add-ADFineGrainedPasswordPolicySubject -Identity "PrivilegedAccounts" -Subjects "Tier0-Admins"List every fine-grained policy and who it covers:
Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name, Precedence, MinPasswordLength, AppliesToPowerShell is handy for three jobs: consistent policies across several domains, compliance reports, and temporary tightening during an incident.
Test scripts in a lab first, and log what they change. These commands affect every account in the domain at once.
What current guidelines recommend
The current guidance is NIST SP 800-63B-4. It flips years of “best practice” on its head.
| Topic | What the guidance says |
|---|---|
| Length, password as the only factor | At least 15 characters |
| Length, with multi-factor authentication | At least 8 characters |
| Periodic changes | Not forced; change when there’s evidence of compromise |
| Composition rules | Not imposed |
| New passwords | Checked against a blocklist of compromised or common ones |
| Long passwords | At least 64 characters should be accepted |
The NIST SP 800-63B-4 guidelines boil down to five points.
- Ditch calendar expiry. Not every 42 days. Microsoft dropped periodic expiration from its Windows security baselines years ago, for the same reason.
- Length beats complexity. A 16-character passphrase beats an 8-character symbol soup. “correct horse battery staple” wins over “P@ssw0rd!”.
- Check against breach lists. Compare new passwords with known compromised ones. Drop the arbitrary character rules.
- Accept long passwords. Sixty-four characters or more.
- Add MFA. It protects more than any password rule alone.
A Server 2019 domain can follow most of that.
- Set the maximum age to 0, never, once MFA covers remote access.
- Raise the length to 14 in the domain policy, and higher through FGPP.
- Keep complexity enabled until you have a blocklist.
On-premises Active Directory has no built-in breach list. Microsoft Entra Password Protection adds one. It needs an agent on the domain controllers and a Microsoft Entra ID P1 license or higher.
The classic “Minimum password length” setting stops at 14 on Server 2019, as described on Microsoft Learn. To require 15 or more for domain users, we’d use a fine-grained password policy.
Password policy: security versus productivity
Security wants everything locked down. Users want to do their jobs and not memorize cryptographic nightmares. You’re in the middle.
Overly strict rules backfire, hard. Make passwords too complex, and people write them on sticky notes. Force too many changes, and they create predictable patterns.
Strict rules that people work around are weaker than moderate rules they follow. Four choices usually strike the balance.
- Long passphrases, not short complex passwords.
- No forced expiry once MFA is in place.
- A lockout threshold around 10 attempts, so typos don’t lock people out.
- A password manager for every user.
What should decide your policy?
- The real threats your organization faces. A bank isn’t a small manufacturer.
- Regulations you actually have to meet.
- How technical your users are.
- Other controls you have, MFA above all.
- The cost of a breach, against the cost of constant password resets.
The goal isn’t maximum security. It’s practical protection that doesn’t cripple productivity.
Rolling it out without a user revolt
A great policy fails if users see it as unreasonable. The technical part is half the battle. Change management is the other half.
Cover four things in your communication.
| Question | What to tell people |
|---|---|
| Why | It protects their data and the company; it isn’t a compliance tick box |
| What | Concrete examples of passwords that pass under the new rules |
| Where to get help | Helpdesk, self-service reset if you have it, a named contact |
| When | Enough notice to prepare; a few weeks |
A phased rollout works well.
- Announcement, with a short how-to.
- Warning phase that previews the changes.
- Soft enforcement: the new rules apply to new passwords only.
- Full enforcement: forced resets, with admins and privileged accounts first.
Some organizations reward early adopters. Others simply hand out a password manager that makes compliance painless. Either approach usually beats a surprise Monday-morning reset.
Clear support channels and a password manager cut the helpdesk spike more than any setting.
Checking that it works
Implementation is step one. Monitoring shows whether security improves, or only the ticket count.
Confirm the effective settings with the two Get cmdlets from the sections above. Then enable account management auditing on the DCs. Watch three events.
| Event ID | What it records |
|---|---|
| 4723 | A password change attempt |
| 4724 | A password reset attempt |
| 4740 | An account locked out |
Metrics worth tracking:
- Password-related helpdesk volume.
- Failed sign-in attempts and lockouts.
- Reset frequency.
- Signs of password sharing or written-down passwords.
- Credential-related security incidents.
A SIEM correlates these events better than Event Viewer. Even a weekly filtered view helps, though.
Approved password audits show whether users choose strong passwords or game the rules. Phishing simulations test real-world habits.
Then adjust. Rules that cause tickets with no security gain need refining. Persistent weaknesses need extra controls.
Our guide to managing users in Windows Server 2019 covers the account side of that work.
Need a license? Our Windows Server 2019 Standard key comes as a genuine license. Delivery is instant to email. Running many VMs? There’s a Windows Server 2019 Datacenter key as well.
How to disable the password policy in Windows Server 2019
Lab box, test VM, a kiosk nobody signs in to from outside? Then a simple password may be fine. The policy itself can’t be removed. You relax its values instead.
| Setting | Value that switches it off |
|---|---|
| Password must meet complexity requirements | Disabled |
| Minimum password length | 0 |
| Minimum password age | 0 |
| Maximum password age | 0, never expires |
| Enforce password history | 0 |
Where to set them depends on the server.
- Domain controller or domain member. The Default Domain Policy, same path as above. Editing it on one DC changes it for every domain account.
- Standalone server.
secpol.msc, Account Policies, Password Policy.
Settings greyed out in secpol? A domain GPO is in charge, and the local values don’t count.
On a standalone server the length and age values also go through the command line:
net accounts /minpwlen:0 /maxpwage:unlimited /minpwage:0 /uniquepw:0Complexity isn’t part of that command. That one stays a secpol job.
We wouldn’t do this on anything that faces the internet or holds real accounts. A production domain is better served by long passphrases and no expiry than by no rules at all.
Account lockout settings in Windows Server 2019
The lockout part lives next door, under Account Lockout Policy. Three settings work as a set.
| Setting | What it does | Microsoft’s notes |
|---|---|---|
| Account lockout threshold | Failed sign-ins before the account locks | 0 to 999; 0 never locks, the default; the security baselines start at 10 |
| Account lockout duration | Minutes until it unlocks by itself | Must be equal to or longer than the reset counter |
| Reset account lockout counter after | Minutes before failed attempts are forgotten | Works only with a threshold above 0 |
A low threshold has a cost. Anyone who knows the user names can lock every account on purpose, no password needed. That’s why 10 is the usual starting point, not 3.
Two more details from Microsoft:
- The built-in Administrator account isn’t locked out by this policy. A strong password matters even more there.
- Kerberos retries and apps that keep reconnecting with an old password count as failed attempts too.
The complexity rule has its own small print. Currency symbols such as € or £ don’t count as special characters. The rule is checked only when a password is created or changed. Source: Microsoft Learn, Account lockout threshold.
Versions these password policy steps cover
The steps apply to Windows Server 2019 domain controllers. They work unchanged on the 2016, 2022 and 2025 releases, since the policy settings are the same.
| Item | Covered |
|---|---|
| Domain controller | Windows Server 2019 Standard, Desktop Experience |
| Lab domain | Windows Server 2016 functional level |
| Consoles | Group Policy Management and Active Directory Administrative Center, from RSAT on Windows 11 |
| Shell | Windows PowerShell 5.1 with the ActiveDirectory module |
Security works as an ecosystem, not as a fortress. Rules that people understand build a security culture. Users then see their part in protection, not an obstacle to work around.
Related guides
FAQ
Where is the password policy in Windows Server 2019?
For domain accounts it's in the Default Domain Policy, edited in Group Policy Management. Look under Account Policies in the Security Settings. On a standalone server, we'd open secpol.msc and go to Account Policies, Password Policy.
Can I set a minimum password length above 14 in Windows Server 2019?
Not with the classic Minimum password length setting. It accepts 0 to 14 on Server 2019. For longer passwords, we'd use a fine-grained password policy for domain users or groups.
Why does my password policy GPO on an OU not work for domain users?
Domain password rules only come from a GPO at the domain level. A password policy linked to an OU changes only local accounts on computers in that OU. For per-group rules, we'd use fine-grained password policies.
How do I see which password policy applies to a user?
Use the Get-ADUserResultantPasswordPolicy cmdlet with the user name. If it returns nothing, the user follows the Default Domain Policy. The Get-ADDefaultDomainPasswordPolicy cmdlet shows that one.
Should passwords still expire every 42 days?
Current NIST guidance says not to force periodic changes. Change passwords only when there's evidence of compromise. Many admins set the maximum password age to 0, or to a long value, once multi-factor authentication is in place.
How long until a new password policy takes effect?
Domain controllers apply the change at their next Group Policy refresh, or right away after a forced update. The rules apply when users next set a password. So existing passwords keep working until they change or expire.
How do I disable the password policy in Windows Server 2019?
You can't delete it, only relax it. Set complexity to Disabled and length, ages and history to 0. On a domain that's the Default Domain Policy; on a standalone server, secpol.msc. We'd keep this to lab machines.
What are the password complexity requirements in Windows Server 2019?
Three of four character groups: uppercase, lowercase, digits, symbols. No account name, and no part of the full name of three characters or more. Currency symbols such as € don't count as symbols.