How to Find the Source of Account Lockouts

Every IT professional has dealt with it.

A user calls the service desk claiming their account is locked out. You unlock it, confirm access is restored, and five minutes later—locked out again. Rinse and repeat. At first glance, it looks like user error, but repeated lockouts are almost always a symptom of something else running in the background.

In Active Directory environments, account lockouts are rarely random. They are the result of cached credentials, background authentication attempts, or misconfigured services. The challenge is not unlocking the account—it’s identifying what is continuing to authenticate with the wrong password.

In this article, I’ll walk through how to reliably find the source of account lockouts in Active Directory, using built-in auditing, PowerShell, and hard-earned troubleshooting experience from real enterprise environments.

Why Active Directory Account Lockouts Really Happen

At a technical level, account lockouts occur when authentication attempts exceed the domain’s lockout threshold. The reasons, however, are often less obvious than “the user typed the wrong password.”

Common (and Often Overlooked) Causes

From experience, the most frequent culprits include:

• Cached credentials on laptops, desktops, or RDP sessions
• Mobile devices (mail profiles are notorious for this)
• Scheduled tasks or Windows services running under a user account
• Mapped drives or persistent SMB connections
• Old credentials stored in applications (Outlook, VPN clients, backup agents)
• Stale sessions on terminal servers or VDI
• Malware or brute-force attempts (rare, but critical to rule out)

A key takeaway: users are often not actively doing anything wrong. The lockout is usually being triggered automatically.

Step 1: Enable Auditing for Account Lockouts

Before you can investigate, Active Directory must be logging the right data. Without auditing enabled, you’re effectively blind.

Enable Advanced Account Management Auditing

1. Open Group Policy Management Console (GPMC)
2. Edit Default Domain Controllers Policy
3. Navigate to:

Computer Configuration  
 → Policies  
   → Windows Settings  
     → Security Settings  
       → Advanced Audit Policy Configuration  
         → Audit Policies  
           → Account Management

4. Enable Success and Failure for:
   Audit User Account Management

Once applied, Event ID 4740 will be logged whenever an account is locked out.

Real-world tip:
If you manage a large domain, verify this policy is not being overridden by another GPO. I’ve seen this mistake waste hours of troubleshooting.

Step 2: Identify the PDC Emulator (Critical Step)

In multi-DC environments, account lockout processing is centralized.

The PDC Emulator FSMO role holder is the domain controller that:

• Receives bad password notifications
• Logs the authoritative account lockout event

If you search the wrong DC, you’ll miss the evidence entirely.

Find the PDC Emulator Using PowerShell

Get-ADDomain | Select-Object PDCEmulator

Make a note of this domain controller—you’ll be querying it extensively.

If you only have one DC…
You already know the answer—but you should also reconsider that architecture.

Step 3: Locate Account Lockout Events (Event ID 4740)

Now that auditing is enabled and you know the correct DC, you can start hunting.

Basic PowerShell Query on the PDC Emulator

Get-WinEvent -FilterHashtable @{
 LogName='Security'
 ID=4740
}

This retrieves all account lockout events.

To view full details:

Get-WinEvent -FilterHashtable @{ LogName=’Security’ ID=4740 } | Format-List

Step 4: Identify the Source Computer of the Lockout

This is where the mystery gets solved.

Within Event ID 4740, look for:

• Caller Computer Name

This field tells you exactly which machine triggered the lockout.

Filter Lockouts for a Specific User

Get-WinEvent -FilterHashtable @{
 LogName='Security'
 ID=4740
} | Where-Object {
 $_.Properties[0].Value -eq "LockedUser"
} | Format-List TimeCreated, Message

Replace LockedUser with the affected username.

The output will clearly identify:

• Time of lockout
• Domain controller
• Source computer

That source system is where the bad credentials live.

Step 5: Investigate the Source System

Once you know the machine causing the lockout, the real work begins.

What to Check First

From experience, check in this order:

1. Services.msc
   • Look for services running as the locked user
2. Task Scheduler
   • Scheduled tasks using stored credentials
3. Credential Manager
   • Cached Windows credentials
4. Mapped Drives
   • Especially persistent mappings
5. Outlook / Mail Profiles
   • Mobile devices and old profiles are common offenders
6. RDP Sessions
   • Log off stale sessions, don’t just disconnect

Pro tip:
If the source is a terminal server, check all sessions—not just the user’s.

Using Event Viewer (GUI Method)

If PowerShell isn’t your preference:

1. Open Event Viewer on the PDC Emulator
2. Navigate to Security Logs
3. Filter for Event ID 4740
4. Open the event and review:
   • Account name
   • Caller computer name

This method is slower—but sometimes useful during incident response calls.

Preventing Future Account Lockouts

Once resolved, prevention is key.

Best Practices from the Field

• Use dedicated service accounts (never user accounts)
• Enforce password updates on all devices simultaneously
• Educate users about mobile and VPN credential caching
• Review lockout thresholds for usability vs security
• Monitor repeated lockouts as potential security indicators

For Hybrid Environments

If you’re running hybrid AD / Entra ID:

• Enable Azure AD Password Protection
• Monitor sign-in logs in Entra ID
• Correlate cloud and on-prem authentication events

Final Thoughts

Repeated account lockouts are one of those issues that feel deceptively simple—but can quickly spiral into a time-consuming investigation without the right approach.

The key lessons:

• Always check the PDC Emulator
• Event ID 4740 is your source of truth
• The lockout source is almost never random
• Most lockouts are caused by background authentication

Once you’ve tracked down a few of these in real environments, you’ll start spotting the patterns quickly—and resolving them becomes a matter of minutes, not hours.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.