Active Directory — Part 10 — Account Lockouts & Password Policies

Introduction

A user calls at 9:05 on a Monday morning. Locked out. You unlock the account. At 9:35 they are locked out again — and this time they insist they have not even touched the keyboard.

They are probably telling the truth. So what is entering the wrong password on their behalf, every half hour, precisely on schedule?

Understanding lockouts means understanding three things: why the policy exists at all, how a lockout mechanically happens across multiple Domain Controllers, and where stale credentials hide. Once you know the machinery, the 9:35 mystery takes minutes to solve instead of days.

Why Lockout Policies Exist

Account lockout is a defence against password guessing. Without it, an attacker can hammer an account with thousands of guesses per minute until something works. With a threshold of, say, five bad attempts, the guessing stops after five tries.

The policy has three dials, set in the domain’s password policy (by default via the Default Domain Policy GPO from Part 6):

How a Lockout Actually Happens

Each Domain Controller keeps a per-account counter called badPwdCount. The interesting part is what happens when a DC receives a wrong password: before rejecting it, the DC forwards the attempt to the PDC Emulator — the one DC that always knows the account’s most recent password. This exists so that a password changed five minutes ago, which has not replicated everywhere yet (Part 7), does not cause false rejections.

If the PDC Emulator also rejects the password, the count increments. When it crosses the threshold, the account locks, the DC records event ID 4740 in its Security log, and the lockout replicates urgently to all DCs — one of the few changes that skips the normal replication schedule, as mentioned in Part 7.

The practical consequence: the PDC Emulator sees every bad password attempt in the domain. When hunting lockouts, it is the one place you can always start.

The Hotel Keycard Analogy

Think of a lockout like a hotel room door that swallows your keycard after too many failed swipes.

Now imagine you changed rooms yesterday, but your old keycard is still in your jacket pocket, your bag, and your car — and helpful automated machines keep swiping those old cards at the new door on your behalf, all day, on a timer. The door does exactly what it was designed to do. The problem is not the door. It is the pocket you forgot about.

What Causes Lockouts Beyond Wrong Passwords

After a password change, anything holding the old password becomes a lockout machine. The usual suspects:

Add to those: mapped drives reconnecting with saved credentials, entries in Windows Credential Manager, applications with hard-coded passwords, and background processes on a machine the user forgot they were logged into. Each retries automatically — which is exactly why the lockouts recur on a schedule and why the user honestly is not touching anything.

Investigating: Finding the Source

The investigation always follows the same trail: find the 4740 event, read the calling computer, then find what on that computer holds the old credential.

Event 4740 contains the locked account and, crucially, the Caller Computer Name — the machine the bad attempts came from. Because every lockout is known to the PDC Emulator, query it first rather than hunting across every DC. Once you have the source machine, the culprit is on it: check services, scheduled tasks, Credential Manager, mapped drives, and disconnected sessions for that user.

If the caller computer name is blank or points at a gateway, the attempts are usually coming from outside the Windows machinery — a mobile device through Exchange or a VPN concentrator — and the equivalent logs on those systems carry the trail forward.

Doing this lookup by hand every time does not scale past the first few tickets. See Active Directory Lockout Source Reporting with PowerShell for a script that automates the 4740 query and emails a ready-to-read report.

Fine-Grained Password Policies

For most of AD’s early life, one domain meant one password policy. If the service accounts needed 24-character passwords and ordinary users needed 8, your options were separate domains or compromise. Fine-Grained Password Policies, introduced with Windows Server 2008, removed that limitation.

A FGPP is a Password Settings Object, or PSO — a small object carrying its own complete set of password and lockout settings. You link a PSO to users or, more sensibly, to global security groups. Members of the group get the PSO’s settings instead of the domain policy.

Because a user can be in several groups, each PSO has a precedence number, and the PSO with the lowest precedence wins. A PSO linked directly to a user beats any group-linked PSO. The effective result for any user is computable — the msDS-ResultantPSO attribute tells you exactly which policy applies, so there is never a need to guess.

A Note on Modern Password Guidance

Password thinking has shifted. Current guidance from NIST and Microsoft favours long passphrases over complex short ones, and drops forced periodic expiry for ordinary accounts — routine expiry mostly produces predictable increments like Summer2026! becoming Autumn2026!. Length, breach-list screening, and multi-factor authentication do more than complexity rules ever did.

Where those modern controls are in place, the password policy’s job narrows to what it is genuinely good at: setting a sane minimum length, and keeping lockout thresholds humane enough that stale credentials do not paralyse the helpdesk.

Scripts / Commands

Use the commands below to read the effective policies, find locked accounts, trace lockout sources, and manage PSOs. All are read-only except Unlock-ADAccount and the PSO creation example.

# Show the domain's default password and lockout policy
Get-ADDefaultDomainPasswordPolicy

# Find every currently locked-out account
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName

# Unlock an account
Unlock-ADAccount -Identity skaranth

# Find the PDC Emulator - the DC that sees every lockout
Get-ADDomain | Select-Object PDCEmulator

# Read lockout events from the PDC Emulator, newest first
Get-WinEvent -ComputerName (Get-ADDomain).PDCEmulator -FilterHashtable @{
    LogName = 'Security'; Id = 4740
} -MaxEvents 20 |
    ForEach-Object {
        [pscustomobject]@{
            Time     = $_.TimeCreated
            Account  = $_.Properties[0].Value
            Source   = $_.Properties[1].Value
        }
    }

# Check an account's bad password count and lockout state
Get-ADUser skaranth -Properties badPwdCount, LockedOut, lockoutTime |
    Select-Object Name, badPwdCount, LockedOut

# List all Fine-Grained Password Policies and their precedence
Get-ADFineGrainedPasswordPolicy -Filter * |
    Select-Object Name, Precedence, MinPasswordLength, LockoutThreshold

# Which policy actually applies to this user?
Get-ADUserResultantPasswordPolicy -Identity skaranth

# Create a stricter PSO for privileged accounts and apply it
New-ADFineGrainedPasswordPolicy -Name "PSO-Admins" -Precedence 10 `
    -MinPasswordLength 20 -LockoutThreshold 10 `
    -LockoutDuration "00:30:00" -LockoutObservationWindow "00:30:00" `
    -ComplexityEnabled $true
Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Admins" -Subjects "Tier0-Admins"

Troubleshooting Cheat Sheet

Quick Reference Summary

Final Thoughts

Lockouts sit at the junction of security policy and helpdesk reality. The policy exists to stop attackers; in practice it mostly catches the debris of password changes — the forgotten phone, the ancient scheduled task, the session someone never signed out of.

The machinery is on your side. Every lockout funnels through the PDC Emulator, every 4740 names its source, and every user’s effective policy is queryable rather than guessable. A recurring lockout is not a mystery — it is a breadcrumb trail that always leads somewhere specific.