If you’ve ever dealt with “my account is locked again” tickets, you know the real pain isn’t unlocking the account — it’s finding what keeps locking it.

When a user gets locked out in Active Directory, the key investigative signal is Windows Security Event ID 4740 (“A user account was locked out”). [techpress.net]

---

✅ The real-world problem

Most IT teams hit the same cycle:

• A user is locked out.
• Helpdesk unlocks the user.
• The account locks again (minutes later).
• The user calls again.
• The admin wastes time digging through event logs to find the Caller Computer Name — the device/service repeatedly sending a bad password.

If you don’t identify and fix the source (stale password in a service, scheduled task, cached credentials, mobile device, etc.), the lockouts will keep coming — and admins end up repeatedly unlocking the account without actually solving the problem.

---

Callout (Tip)
Unlocking the account is not the fix.
The fix is finding the caller computer/device and removing the stale credentials or misconfiguration.

---

Why this becomes time-consuming (and doesn’t scale)

The manual process is usually:

1. Log on to a domain controller
2. Open Event Viewer → Security log
3. Filter for Event ID 4740
4. Find the affected user
5. Read the Caller Computer Name
6. Repeat… for every lockout/user

Event 4740 is extremely useful for lockout investigation because it records the lockout event and (in many cases) the calling machine name. [techpress.net]

But doing this manually for many users is slow, disruptive, and error-prone.

---

---

✅ The solution: an automated lockout report (HTML + optional email)

To make lockout troubleshooting fast and repeatable, we built a PowerShell script that:

• Pulls all lockout events (4740) in a chosen time window
• Extracts the locked username and the caller computer
• Generates a clean HTML report for quick review
• Optionally sends the same report inline in email using Microsoft Graph (no attachments)

This turns lockout analysis into a 30-second workflow instead of an Event Viewer marathon.

---

---

Why this script queries the PDC Emulator only (and not every DC)

Active Directory is multi-master, but some operations are centralized.

Microsoft’s Active Directory technical specification for the PDC Emulator FSMO role states:

• When logon authentication fails at a DC due to a bad password, the DC can forward the request to the PDC emulator to validate against the most current password.
• Account lockout is processed on the PDC emulator. [blog.mindcore.dk]

Practical benefit: querying the PDC emulator is typically the most efficient starting point for lockout investigations because that role handles lockout processing and related password-validation behavior. [blog.mindcore.dk]

Callout (Note)
In some environments, you may also see related lockout events appear on other DCs depending on where authentication occurs. But the PDC emulator is commonly the primary place to start because lockout processing is handled there. [blog.mindcore.dk], [graphpermi…merill.net]

---

---

What the report includes

Each row in the report contains:

• TimeCreated — when the lockout occurred
• SamAccountName — who was locked
• Domain – Caller Computer — the lockout source (cleaned so duplicates don’t show twice)
• DomainController — the PDC used for the query
• EventRecordId — for quick correlation back to Event Viewer

This is designed specifically for day-to-day operational use: “who is locked, and from where?”

---

<

---

Configuration steps (what you need to set)

1) Prerequisites

• PowerShell running on a machine with the ActiveDirectory module (RSAT)
• Permission to read the Security log on the PDC emulator
• If emailing is required: Microsoft.Graph module + app registration

Event ID 4740 is generated when a user account is locked out and is written to the Security log. [techpress.net]

---

2) Set the time window

In the script, configure:

• HoursBack (example: 12 hours)

Example run (HTML only):

.\Get-LockoutCaller.ps1 -HoursBack 12

3) Optional: Enable email sending via Microsoft Graph (certificate-based)

If you want to email the report automatically, you’ll configure:

• TenantId
• ClientId
• CertificateThumbprint
• FromAddress
• ToRecipients

Microsoft Graph requirements

The Graph API supports sending mail via:

• POST /users/{id | userPrincipalName}/sendMail [learn.microsoft.com]

And Graph PowerShell supports certificate-based app-only auth via:

• Connect-MgGraph -TenantId -ClientId -CertificateThumbprint [windowstechno.com]

Required Graph permission

Your app registration needs Mail.Send (Application) for sendMail. [learn.microsoft.com], [youtube.com]

Callout (Security)
Mail.Send (Application) is powerful. Restrict it appropriately in production and follow least-privilege practices. [youtube.com], [youtube.com]

---

4) Run with email enabled

.\Get-LockoutCaller.ps1 -SendEmail

5) Don’t want email?

Just don’t use -SendEmail:

.\Get-LockoutCaller.ps1

This makes the email functionality optional and safe for teams that only want the local report.

---

---

Operational workflow (recommended)

1. Run the script (or schedule it)
2. Check the report for the user
3. Identify the caller computer
4. Fix the source on that machine:
   • remove cached creds
   • update scheduled task credentials
   • update services/app pools
   • re-authenticate mobile clients
5. Unlock the user once (if needed)
6. Confirm the lockouts stop

---

---

Final thoughts

Account lockouts are expensive because they’re noisy and disruptive — but the fix is almost always hidden in one field: Caller Computer Name. Event ID 4740 is the event you want, and automating the collection into a report makes troubleshooting faster and more consistent