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

---

---

---

FAQ

Quick answers to common questions about Active Directory lockouts, Event ID 4740, and the reporting script.

Why does this script query the PDC Emulator only?

The PDC Emulator FSMO role is responsible for key password and lockout behaviors. Microsoft’s AD technical specification notes that when a logon fails due to a bad password, a DC can forward the request to the PDC Emulator to validate against the most current password, and that account lockout is processed on the PDC Emulator. This makes the PDC Emulator an efficient starting point for lockout investigation and reporting.

What exactly is Event ID 4740?

Event ID 4740 is a Windows Security auditing event generated when a user account is locked out. It’s the primary event used to begin lockout troubleshooting in Active Directory environments.

Where do I find the “Caller Computer Name” in the lockout event?

In a lockout event (4740), the event data includes details about the locked account and the system involved in the action. Many environments also expose a caller/source computer field used during investigation. If the caller field is blank in your environment, correlate with nearby failed logon events (such as failed authentication activity on the originating system) to identify the true source.

Why does the caller computer sometimes show blank?

This can happen when the caller/source information isn’t populated or isn’t visible due to how authentication occurred (for example, certain services, protocols, or intermediary systems). In those cases, use the lockout time and correlate with nearby authentication failures to identify the source.

Do I need to query all domain controllers instead?

Start with the PDC Emulator because lockout processing is handled there. If you suspect authentication is occurring across multiple sites and you’re missing events (or your environment logs relevant activity elsewhere), you can extend the script to query all DCs as a second step. For most organizations, PDC-first provides a fast operational workflow.

What permissions do I need to run the script?

You need permission to read the Security event log on the target Domain Controller (PDC Emulator). You do not necessarily need full Domain Admin privileges if your organization delegates event log read access appropriately.

Why does the email look “plain” compared to the HTML report?

Many email clients (especially Outlook desktop) do not fully support modern CSS or external style blocks. The script solves this by generating an email-specific version of the report using inline CSS, which is far more compatible with mail clients.

How does the email sending work (Microsoft Graph)?

The script sends mail using Microsoft Graph’s /users/{id|userPrincipalName}/sendMail endpoint. This supports sending the report directly in the message body. The script authenticates using certificate-based app-only access via Graph PowerShell.

What Graph permissions are required?

For app-only email sending, the app registration needs Mail.Send application permission with admin consent. Treat this as sensitive and restrict it where possible using least-privilege practices.

How do I disable email sending?

Simply run the script without the -SendEmail switch. The script will still generate the HTML report locally, but it will not send email.

What are common real-world causes of repeated lockouts?

Common causes include stale credentials stored in scheduled tasks, Windows services/app pools running under an old password, cached credentials, mapped drives reconnecting, mobile devices syncing with an old password, or scripts/tools using outdated credentials. The “caller computer” helps you narrow down which system to investigate first.