Auditing failed logons and lockouts

Auditing failed logons and lockouts in active directory

Failed logons and account lockouts are the earliest, loudest signals of identity trouble in a Windows environment. Sometimes that trouble is harmless (a user typing the wrong password). Sometimes it is operational debt (stale credentials in a scheduled task). Sometimes it is an active adversary (password spraying, credential stuffing, lateral movement). The difference is rarely visible from a single event. It emerges when you audit correctly, interpret fields precisely, and correlate across systems with discipline.

This guide goes beyond “enable auditing, look for Event ID 4625 and 4740.” It explains the mechanics that produce those events, the hidden dependencies that distort them, and the practical workflows experts use to turn noisy security logs into high-confidence conclusions.

What “auditing failed logons and lockouts” really means

In plain terms, auditing failed logons and lockouts means collecting the right authentication telemetry, at the right places, with enough detail to answer three questions quickly:

Who is failing to authenticate (user, service account, computer account)?
Where is the authentication coming from (workstation, server, VPN concentrator, application host)?
Why is it failing (bad password, account disabled, logon restrictions, protocol mismatch, time skew)?

The surface-level view is: “4625 = failed logon, 4740 = lockout.” That’s correct but incomplete. Those IDs are not the story. They are the breadcrumbs. The story is in the details: logon type, status/substatus, authentication package, target account, caller computer, and the chain of events before and after.

If you want this to function as a comparison-grade reference (one you can use to judge tools, designs, and approaches), you need to understand how Windows creates these events and what can silently mislead you.

Why this matters right now

Identity attacks have shifted toward volume and plausibility. Password spraying targets many users with a few guesses each to evade lockout thresholds. Credential stuffing reuses breached passwords at scale. Meanwhile, hybrid environments create more “places” where a password can be cached and replayed: endpoints, mobile mail clients, legacy line-of-business apps, VPNs, sync services, RPA bots, and scheduled tasks.

Operationally, lockouts are expensive. One locked admin account during a change window can create cascading delays. Security-wise, a domain full of 4625s without context is worse than no telemetry at all: it trains teams to ignore the signal because the noise never stops.

Done well, auditing becomes both a troubleshooting tool and a detection layer. Done poorly, it becomes a storage bill.

The mechanics: first principles that drive everything you see in the logs

Windows authentication is not one thing. It is a set of protocols and decision points that produce different logging artifacts depending on where the request is validated and how credentials are presented. Three core principles explain most surprises:

1) Where the credential is validated determines where the useful event lives

A user typing a password into a workstation is not the same as a service on a server presenting cached credentials to a domain controller. Some failures will be most visible on the client (the machine initiating the logon). Some are most visible on the domain controller (the machine validating credentials). Some appear in both, but with different clarity.

2) Kerberos and NTLM failures do not look the same

Kerberos is ticket-based. NTLM is challenge-response. A failure during Kerberos pre-authentication, ticket request, or service ticket validation can produce different fields than an NTLM failure. Treating all failures as identical leads to wasted time and missed attacks.

If you want foundational context, Wikipedia entries for Kerberos and NTLM are a good quick refresher.

3) “Lockout” is a policy-driven outcome, not a cause

A lockout is the result of repeated failures exceeding a threshold. The reason for the failures can be mundane or hostile. The lockout event is your “symptom event.” Your job is to find the “cause events” that incremented the failure counters.

The two event IDs everyone quotes — and what they hide

The Google AI overview correctly highlights two cornerstone events: Event ID 4625 (failed logon attempt) and Event ID 4740 (account locked out). You should absolutely use them. But you should also understand their limitations.

Event ID 4625: failed logon

4625 is useful because it is frequent and detailed. It is also dangerous because it is frequent and detailed. Without a mental model, you will drown in it. The most important fields to treat as “truth anchors” are:

Logon type (interactive vs network vs service vs batch).
Status and substatus (why Windows says the attempt failed).
Authentication package (Kerberos, NTLM, Negotiate).
Workstation name / source network address (where it came from).
Process information (what on the system initiated it).

Microsoft’s reference for 4625 is worth keeping open when you are diagnosing difficult cases: Event 4625 documentation.

Event ID 4740: account lockout

4740 is the pivot point for lockout troubleshooting because it includes the caller computer name in many cases. That name is not a guess. It is often your fastest path to the system replaying old credentials. But it is not guaranteed to be present or correct in every scenario (NAT, proxies, load balancers, certain services).

Hero technical section: the expert workflow that actually works

This section is intentionally practical and highly technical. The goal is to help you build an audit posture that is: (1) accurate, (2) scalable, and (3) usable under pressure. The steps below reflect the guidance referenced in the overview (ManageEngine, Lepide, Microsoft) and the reality-tested troubleshooting patterns discussed widely in sysadmin forums.

Step 1: enable the right auditing (and do it the modern way)

The overview suggests enabling legacy audit categories: “Audit logon events” and “Audit account logon events” for success and failure via: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy. This works, but experts typically prefer advanced audit policy because it is more granular and avoids some category ambiguity.

Open Group Policy Management Console (GPMC) on a management system or DC.
Edit the GPO linked to your domain controllers OU (or a dedicated “DC security baseline” GPO).

Navigate to:

Computer Configuration
  > Policies
    > Windows Settings
      > Security Settings
        > Advanced Audit Policy Configuration
          > Audit Policies
            > Logon/Logoff

Enable these at minimum (Success and Failure):
- Audit Logon (captures many 4624/4625-style outcomes)
- Audit Account Lockout (captures lockout signals)
Also review:
```
Advanced Audit Policy Configuration
  > Account Logon
  > Credential Validation
```
In many real environments, Credential Validation events are essential for understanding credential misuse patterns.
Force policy refresh:
```
gpupdate /force
```
(Referenced in the overview’s sources.)

Microsoft’s audit policy recommendations are a strong baseline reference: Audit policy recommendations. Defender for Identity also documents event collection strategy that is relevant if you forward events centrally: Configure windows event collection.

Step 2: confirm you are collecting what you think you are collecting

Two failure modes cause endless confusion: (1) auditing is enabled but events never appear, or (2) events appear but lack critical fields due to log size, retention, or forwarding filters.

On a DC, open Event Viewer → Windows Logs → Security, and filter by event ID 4625.
Verify Security log size and retention strategy (do not let it overwrite too quickly).
If using Windows event forwarding (WEF), validate subscriptions and confirm the forwarded log actually contains 4625/4740.

Step 3: interpret 4625 like an investigator, not a tourist

When you open a 4625 entry, do not start with “Account name.” Start with the shape of the attempt: logon type, status/substatus, authentication package, and source.

Logon type is your fastest triage:
- 2 = interactive (keyboard/console)
- 3 = network (SMB, remote access, mapped drives)
- 4 = batch (scheduled tasks)
- 5 = service
- 10 = remote interactive (RDP)
Status/substatus tells you the class of failure (bad password vs disabled vs restrictions). Use Microsoft’s 4625 reference to decode these reliably: Event 4625.
Source fields (workstation name, source network address) tell you where to go next. Treat them as leads, not verdicts (NAT and proxies can lie).

Step 4: use 4740 to pivot, then prove causality

The classic lockout workflow from the overview is correct: find 4740 on a DC, note the caller computer name, then inspect that computer for 4625s at the relevant time.

On a DC, filter the Security log for 4740.
Open the event. Record:
- Target account
- Caller computer name
- Timestamp
On the caller computer, search the local Security log for 4625 around that timestamp.
Identify the culprit pattern:
- Recurring at exact intervals (scheduled task / service restart loop)
- Triggered at logon/logoff (mapped drives / cached credentials)
- Triggered by an app opening (Outlook / legacy apps / stored passwords)

ManageEngine documents this practical tracing approach clearly: Trace and diagnose account lockout.

Step 5: build fast queries (PowerShell) for repeatable triage

Event Viewer is fine for one-offs. PowerShell is what makes this repeatable, automatable, and easy to operationalize. The following examples are intentionally minimal and focus on the fields you will actually use during a live incident.

# Recent failed logons (4625) on a domain controller
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 50 |
  Select-Object TimeCreated,
    @{n='TargetUser';e={$_.Properties[5].Value}},
    @{n='LogonType';e={$_.Properties[10].Value}},
    @{n='Workstation';e={$_.Properties[13].Value}},
    @{n='SourceIP';e={$_.Properties[19].Value}} |
  Format-Table -AutoSize

# Recent lockouts (4740) on a domain controller
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 50 |
  Select-Object TimeCreated,
    @{n='TargetAccount';e={$_.Properties[0].Value}},
    @{n='CallerComputer';e={$_.Properties[1].Value}} |
  Format-Table -AutoSize

Now the expert move: don’t just “list events.” Group and count to spot sprays, loops, and hotspots.

# Top sources of 4625 in the last hour (simple triage)
$since = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=$since} |
  Group-Object { $_.Properties[13].Value } |
  Sort-Object Count -Descending |
  Select-Object -First 15 Count, Name |
  Format-Table -AutoSize

Step 6: stop guessing which DC is “responsible”

A common trap: you see 4740 on DC1 and assume DC1 “caused” the lockout. It didn’t. It logged the lockout because it processed the authentication request that crossed the threshold. The actual failed attempts may be distributed across DCs (depending on client affinity, site topology, and load).

In high-friction lockout cases, you often need to query multiple DCs for the same user in the same window and correlate. That’s why centralized collection (WEF to a collector, or ingestion into a SIEM) becomes a quality-of-life improvement, not a luxury.

Step 7: use event forwarding and correlation to get out of “manual hell”

Mature environments treat authentication logs like telemetry: centralized, searchable, correlated, and alertable. If you rely on “RDP into a DC and click around Event Viewer,” you will eventually fail under volume or time pressure.

Consider Windows event forwarding (WEF) to a collector and store events centrally.
If you use Microsoft Defender for Identity, align with its event collection guidance: Configure windows event collection.
If you use a SIEM, build two foundational detections:
- Password spraying: many users, same source, low attempts per user.
- Credential loop: same user, same host, repetitive timing (task/service).

Step 8: incorporate “human reality” from the field

Practitioners repeatedly report the same root causes in the wild:

Mapped drives reconnecting with old credentials after a password change.
Scheduled tasks using a domain account whose password was rotated.
Services running under user credentials without managed rotation.
Old credentials stored in Credential Manager, browsers, or mail clients.
Mobile devices retrying aggressively after a password reset.
VPN clients caching passwords and retrying in the background.

This matters because it tells you where to look first when 4740 points to a workstation or server. You are not hunting for mysteries. You are checking a short list of usual suspects with a disciplined method.

Additional practical walkthroughs from the overview sources: Find the source of failed login attempts, Audit logon/logoff and failed logons, Find failed logon attempts source.

Implications, limitations, and silent dependencies

The design choices that make Windows authentication scalable also create predictable auditing pain. If you understand these tendencies, you stop blaming “randomness” and start designing around reality.

Security log volume is a design constraint

Failed logons can spike suddenly during password resets, service outages, VPN issues, or active attacks. If your Security log retention is small, your evidence evaporates. If your SIEM ingest budget is limited, you may drop exactly the data you needed when volume surged.

Experts plan for bursts: they allocate retention on DCs, forward critical subsets, and build rate-based alerts rather than “one event = incident.”

Caller computer name can be missing or misleading

4740’s caller computer name is invaluable, but not omniscient. Proxies, NAT devices, certain application flows, and some identity middleware can distort the apparent source. Treat it as a starting point, then confirm with surrounding 4625 data, endpoint logs, and network telemetry.

Account lockout policy can be weaponized

An aggressive lockout threshold can become a denial-of-service lever. Attackers don’t need to guess passwords correctly to cause harm; they can simply lock out key users repeatedly. The auditing lesson: high confidence detection requires pattern recognition, not blind reliance on lockouts as “protection.”

Expert mental models that unlock faster diagnosis

The “three narratives” model

Every failed logon cluster typically fits one of three narratives:

User narrative: interactive mistakes, password changes, expired passwords, device confusion.
System narrative: services, tasks, scripts, stored credentials, app pools, integration accounts.
Adversary narrative: spraying, brute force, credential stuffing, lateral movement probes.

Your job is to identify which narrative the evidence supports, then use the correct playbook. Trying to troubleshoot a spray attack like a user mistake wastes time. Treating a scheduled task loop like an attack creates panic and ticket churn.

The “shape over identity” insight

Experts often ignore the username at first. They look at the shape: logon type, timing, source diversity, and repetition. The shape tells you the mechanism. The mechanism tells you the fix.

The “pivot machine” rule

For lockouts, the DC is rarely where you fix the issue. You pivot to the caller computer (from 4740), then locate the initiating component (task/service/credential store). This avoids the endless loop of “reset password → lockout again.”

Misunderstandings, risks, and correctives

Misunderstanding: “4625 means bad password”

A 4625 can mean bad password, but it can also mean account disabled, logon restrictions, or other policy constraints. Always use status/substatus and logon type to avoid misdiagnosis.

Misunderstanding: “4740 proves the attacker’s location”

4740 provides a strong lead, not an unchallengeable truth. Confirm with correlated 4625s and endpoint context.

Risk: alert fatigue destroys the value of auditing

If you alert on every 4625, people will ignore alerts. Instead, alert on:

Unusual spikes above baseline
Same source failing across many users
Failures against privileged accounts
Repeated failures from unusual geographies or network segments (where applicable)

Expert essentials checklist

Enable auditing with advanced audit policy where possible.
Size and retain Security logs so evidence survives bursts.
Use 4625 for detail; use 4740 for pivoting; then prove causality on the source system.
Group and count events to identify sprays and loops quickly.
Design alerts around patterns and baselines, not single events.

Applications, system consequences, and what comes next

Strong auditing improves more than troubleshooting. It shapes how you design identity controls across the environment:

Incident response: Authentication logs often provide the earliest timeline of credential misuse.
Operational hygiene: Repeated lockouts often expose unmanaged service accounts and weak credential rotation.
Zero trust alignment: Identity becomes the perimeter; failed logons become perimeter probes.
Hybrid readiness: On-prem logons intersect with cloud sign-in patterns; correlation becomes a core skill.

The forward path is clear: better centralization (WEF/SIEM), better correlation, and reduced reliance on passwords where feasible. But even in passwordless migrations, legacy paths remain. Auditing stays relevant because visibility is the prerequisite for control.

If you are building a deeper Active Directory auditing and hardening program, these internal searches help you interlink related topics on Windows Active Directory without guessing exact slugs:

Few other sources:

Key takeaways and wrap-up

Auditing failed logons and lockouts is not a checkbox. It is an engineering discipline: collect the right signals, preserve them long enough to investigate, and interpret them with a model that separates user mistakes from system loops from adversary behavior.

If you implement only one improvement, make it this: stop reading 4625 as a standalone event. Group it. Count it. Correlate it. Pivot from 4740 to the caller machine and prove causality. That workflow turns “random lockouts” into solvable problems and turns “noisy failures” into detection-grade telemetry.

Want a faster path in your own environment? Subscribe for updates and grab our practical lead magnet: a downloadable account lockout troubleshooting toolkit (PowerShell queries, checklists, and a correlation worksheet you can hand to a helpdesk or SOC analyst). Explore more at windows-active-directory.com.