How to Configure Account Lockout Policy Using Group Policy

Account lockout policy is the control that stops someone from guessing passwords forever. After a set number of failed sign-ins, the account locks and the attacker — or the script — has to stop. Set it well and you blunt brute-force attacks without burying your help desk in lockout tickets. Set it badly and you do the opposite.

There are only three settings, but the details matter: where you link the policy, how the three values relate to each other, and the trade-off between security and the support calls that come with aggressive lockouts. This guide covers how to configure account lockout policy with Group Policy, sensible values, and the mistakes that cause the most grief.

The three settings, and what each one does#

The Account Lockout Policy has exactly three settings. They work together, so it helps to understand all three before you change any.

The relationship between them is the part people miss. The reset counter and lockout duration must both be set if the threshold is anything other than 0, and the reset counter has to be less than or equal to the lockout duration. The Group Policy editor will actually suggest matching values when you set the threshold first.

Where the policy lives#

For domain user accounts, account lockout settings are read from a policy linked at the domain level. In almost every environment that’s the Default Domain Policy. The full path in the Group Policy Management Editor is:

Computer Configuration
  > Policies
    > Windows Settings
      > Security Settings
        > Account Policies
          > Account Lockout Policy

Configure the policy step by step#

1. On a domain controller or a management box with RSAT, open Group Policy Management (gpmc.msc).
2. Expand your forest and domain, right-click Default Domain Policy, and choose Edit.
3. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.
4. Double-click Account lockout threshold. Tick Define this policy setting, enter a value such as 5, and click OK.
5. Windows offers suggested values for the other two settings. Accept them or set your own — for example, a 15-minute duration and a 15-minute reset counter.
6. Confirm Account lockout duration and Reset account lockout counter after are both defined and consistent.
7. Close the editor. The policy applies as DCs refresh; force it if you don’t want to wait.

gpupdate /force

Choosing sensible values#

There’s no single correct number, but there is a workable range. The goal is to stop automated password guessing while tolerating the normal way people fail to sign in: a mistyped password, a phone holding an old cached credential, a mapped drive using stale auth.

A threshold of 5–10 is the sweet spot for most organizations. Going lower — 1, 2, or 3 — feels safer but it isn’t, because a single phone with a wrong saved Wi-Fi or mail password can lock a user out repeatedly and flood your help desk. Setting the threshold to 0 turns lockout off entirely, which Microsoft’s own guidance only recommends in narrow scenarios where you’re specifically defending against the denial-of-service angle of lockouts and have other controls in place.

Per-group rules with Fine-Grained Password Policies#

The domain-level policy applies one set of rules to everyone. That’s a problem when you want, say, stricter lockout for administrators and something more forgiving for standard users. Fine-Grained Password Policies (FGPP), implemented as Password Settings Objects, solve this.

FGPP lets you target specific users or security groups with their own lockout threshold, duration, and reset counter, overriding the domain default for just those members. They’ve been available since the Windows Server 2008 domain functional level and are managed through the Active Directory Administrative Center under the Password Settings Container.

A common pattern: tighten lockout on the Domain Admins and Enterprise Admins groups while keeping the general population at a help-desk-friendly threshold. Because FGPP is applied by precedence, give the admin policy a lower precedence number so it wins for those accounts.

After applying: verify it took effect#

Don’t assume the policy applied — confirm it. On a domain controller, check the effective account policy:

gpresult /r /scope:computer

You can also read the effective password and lockout policy directly:

Get-ADDefaultDomainPasswordPolicy

This returns the live LockoutThreshold, LockoutDuration, and LockoutObservationWindow values the domain is enforcing. If they don’t match what you set, the change either hasn’t replicated yet or was made in the wrong GPO.

Finding and unlocking locked-out accounts#

Once lockout is enforced, you’ll need a fast way to find who’s locked and clear them. To list locked-out accounts across the domain:

Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LastLogonDate

To unlock a specific user:

Unlock-ADAccount -Identity jdoe

If the same account keeps locking minutes after you unlock it, something is repeatedly presenting old credentials — a phone, a scheduled task, a service running as that user, or a saved credential in Windows Credential Manager. The lockout events on the PDC emulator’s Security log (event ID 4740) record the source computer, which points you at the culprit. Our guide on finding locked-out user accounts in Active Directory walks through tracing the source.

Wrapping up#

Configuring account lockout policy comes down to three settings, one correct place to put them, and a value range that protects accounts without punishing users. Set the threshold around 5–10, keep the duration and reset counter consistent, link the policy at the domain level, and verify it applied with Get-ADDefaultDomainPasswordPolicy. When you need different rules for admins versus everyone else, reach for Fine-Grained Password Policies rather than bending the domain default.