Technical Anshu
Tutorials Blog
🔐 Lockout Auditing

Enable Account Lockout Auditing So Event 4740 and 4625 Explain Every Lockout

Every lockout investigation on this site starts with Event 4740 — but that event only exists if somebody turned auditing on before the incident. Ten minutes of setup today is the difference between a mystery and a log entry that names the guilty machine.

✍️ Technical Anshu🪟 Windows Server / Windows 10 / 11⏱️ 8 minute read
🎥 Watch the full video — Windows account lockout policy and all 3 recovery methods, demonstrated step by step

Here is the uncomfortable default: on many networks, account lockout auditing is not fully enabled, so the first real lockout arrives with no 4740 event, no caller computer name, and an admin reduced to guessing which device holds the old password. This page is the fix, done once, properly: which audit subcategories produce 4740 and 4625, where to set them (domain controllers matter most), how to verify with auditpol instead of hoping, how to keep the logs from overwriting themselves, and the extra Netlogon debug log that cracks the cases the events cannot.

Command Prompt — verifying audit policy with auditpol
C:\> auditpol /get /subcategory:"Account Lockout" System audit policy Category/Subcategory Setting Logon/Logoff Account Lockout Success
👆 The setting that makes Event 4740 exist (output recreated with the real auditpol format) — if yours says No Auditing, your next lockout will be a guessing game
1

The Two Events and the Policies That Create Them

Two events do all the lockout detective work, and each has its own switch in Advanced Audit Policy Configuration (inside Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration):

  1. Audit Account Lockout (under Logon/Logoff) set to Success → produces Event 4740, "a user account was locked out", with the caller computer name. This must be enabled on your domain controllers — the Default Domain Controllers Policy is the natural home.
  2. Audit Logon (also Logon/Logoff) set to Failure → produces Event 4625, every failed logon with its reason codes and source. Enable it on DCs and on member servers and key workstations, since 4625 on the target machine often shows the original source that the DC's event summarises.

On a standalone PC the same settings live in secpol.msc under Advanced Audit Policy Configuration — worth doing on any important single machine too.

2

Set It with auditpol When You Need It Now

Group Policy is the durable route, but for immediate verification or a single machine, auditpol speaks directly:

  1. Enable lockout auditing: auditpol /set /subcategory:"Account Lockout" /success:enable
  2. Enable failed-logon auditing: auditpol /set /subcategory:"Logon" /failure:enable
  3. Check any setting: auditpol /get /subcategory:"Account Lockout" — and check the whole picture with auditpol /get /category:*
  4. After a GPO change, refresh and re-verify: gpupdate /force, then run the /get command again. "I set it in the console" is not verification; the auditpol output is.

One Group Policy gotcha that burns everyone once: if the legacy basic audit policy and the advanced subcategories fight, advanced settings can be silently overridden. The security option "Audit: Force audit policy subcategory settings to override audit policy category settings" exists precisely to settle that fight in favour of the subcategories.

3

Keep the Evidence Alive — Log Size and Forwarding

Auditing that overwrites itself by lunch is theatre, not evidence. The Security log on a busy DC fills fast once failure auditing is on:

  1. Raise the Security log size on DCs (Group Policy or Event Viewer properties) — hundreds of megabytes, not the small default, and set a retention behaviour your organisation actually accepts.
  2. Forward the important events — Windows Event Forwarding or your SIEM/monitoring tool should collect 4740 and admin-account 4625s centrally, because the first thing a serious attacker does is clear local logs.
  3. Alert on 4740 for admin accounts. A lockout of a normal user is support work; a lockout of an administrator at 3 AM is a page-somebody event.
4

When Events Are Not Enough — Netlogon Debug Logging

For the stubborn case — 4740 shows the caller, but the trail dies there — domain controllers keep one more diary: the Netlogon debug log. Enable it on the DC with nltest /dbflag:0x2080ffff and the file C:\Windows\debug etlogon.log starts recording authentication traffic in detail — which workstations passed bad passwords through, and when. It has solved "impossible" lockout mysteries for a generation of admins. Two disciplines: turn it off when the case closes with nltest /dbflag:0x0 (the log is verbose and rotates), and treat the file as sensitive — it maps your authentication flows, so it does not belong in casual email threads. With auditing on, logs sized, forwarding set and this tool in reserve, your next lockout will not be an investigation. It will be a lookup.

⚠️ Do this on a calm day: auditing cannot be enabled retroactively. The lockout that happens before you set these policies leaves no 4740 behind — which is why this page, of all the lockout pages, is the one to act on today.

🎥 See the Lockout Recovery Methods in the Video

The complete lockout policy walkthrough and all 3 recovery methods, shown live on a real Windows system — this is the video this guide is based on.

▶️ Watch Full Video
❓ Frequently Asked Questions

Why is there no Event 4740 for a lockout that definitely happened?

Because Audit Account Lockout (Success) was not enabled on the domain controller that processed the lockout. The event is only written when that subcategory is on. Enable it in the Default Domain Controllers Policy, run gpupdate, and verify with auditpol /get.

Where should lockout auditing be enabled — workstations or domain controllers?

Domain controllers first: 4740 is written there, since AD processes the lockout. Add Audit Logon (Failure) for Event 4625 on DCs and also on important member servers and workstations, where it can reveal the original device or IP behind a lockout.

What does nltest /dbflag do and when should I use it?

nltest /dbflag:0x2080ffff enables detailed Netlogon debug logging on a domain controller, written to C:\Windows\debug\netlogon.log. Use it when Event 4740 and 4625 still cannot identify the source of bad passwords. Remember to switch it off afterwards with nltest /dbflag:0x0.

This guide is based on the Technical Anshu Windows Account Lockout Policy video • Stuck on a step? Ask in the video comments — you will get a reply 🙏