Event ID 4740 and 4771: account lockouts and Kerberos failures

Event 4740 is Windows saying "A user account was locked out". Event 4771 says "Kerberos pre-authentication failed", usually a wrong password against a domain controller. Together they tell you who is locked out, from which computer, and whether it is an old password somewhere or someone guessing.

1. Where to find the events

Both events are written by domain controllers into Event Viewer (eventvwr.msc) › Windows Logs › Security.

• 4740 is written by the domain controller that locked the account, and by the PDC emulator, which every lockout is forwarded to at once. So search the PDC emulator first: (Get-ADDomain).PDCEmulator tells you which one it is. Local accounts on a member Server or PC that get locked out produce a 4740 in that computer's own log.
• 4771 is written by the domain controller that handled the Kerberos logon. With several domain controllers, check each of them, or collect their logs centrally.

If you find nothing: 4740 needs the audit subcategory User Account Management (Success), 4771 needs Kerberos Authentication Service (Failure). Check with auditpol /get /category:* on a domain controller. The default domain controller policy normally has them on.

Recent lockouts, with the computer they came from (as administrator, with the ActiveDirectory module):

$pdc = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $pdc -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 50 |
  Select-Object TimeCreated, @{n='User';e={$_.Properties[0].Value}}, @{n='CallerComputer';e={$_.Properties[1].Value}}

In the event's data the Caller Computer Name is stored in the field named TargetDomainName (the second value), which is why Properties[1] is the computer and not the domain.

2. Reading Event 4740: who was locked out, and from where

Field	What it tells you
Account That Was Locked Out › Account Name	The user who can no longer log on.
Caller Computer Name	The computer that sent the bad passwords. This is where you look next.
Subject	Usually the domain controller's own computer account. Not the culprit.

The Caller Computer Name is the computer that passed the logon on. If it is your Exchange Server, a web Server or an RDP gateway, the real source is behind it: a phone with the old password (ActiveSync), a browser, a remote client. Then look in that Server's own logs (IIS logs, Event 4625) for the client address. If the field is empty, the request often came from a device or service that does not send a computer name; use the 4771 events at the same time instead.

3. Reading Event 4771: why Kerberos refused

The fields that matter are Account Name, Client Address and Failure Code. The Client Address is often written as ::ffff:10.0.1.25: that is just an IPv4 address in IPv6 notation, so the computer is 10.0.1.25.

Failure Code	Meaning	What it usually is
0x18	Pre-authentication failed: wrong password	The classic. A typo, an old saved password, or guessing. Repeated 0x18 from one address is what leads to a 4740.
0x12	Client credentials revoked: account disabled, expired, locked out or outside logon hours	After a lockout, every further try shows 0x12. A stream of them means the source is still trying.
0x17	Password has expired	A user or a service account whose password ran out. Not an attack.
0x25	Clock skew too great	The client's clock is more than 5 minutes off (the default). Fix the time sync, not the password.

Kerberos failures for a user name that does not exist at all are usually logged as Event 4768 (failure code 0x6), not 4771. Many 4768 / 0x6 events with changing names are a sign of someone trying user names.

Count the wrong passwords per user and address over the last day (on a domain controller):

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4771; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object { $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }; [pscustomobject]$d } |
  Where-Object Status -eq '0x18' | Group-Object TargetUserName, IpAddress | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

4. Finding the source of repeated lockouts

Once you know the Caller Computer Name or the client address, look on that computer for anything still using the old password:

• Mapped drives and saved credentials: net use and Credential Manager (control keymgr.dll) on the user's PCs.
• Services running as that user: Get-CimInstance Win32_Service | Where-Object StartName -like '*username*'.
• Scheduled tasks running as that user (Task Scheduler, the Run as column).
• Phones and tablets with company mail (ActiveSync): the lockout then points to the Exchange Server. Update or remove the account on the device.
• A disconnected RDP session still logged on with the old password on some Server: log it off.
• Other apps with a saved password: VPN clients, Wi-Fi with user logon (802.1X), scanners sending to a share, backup software.

Microsoft's older Account Lockout and Management Tools (LockoutStatus.exe) show the bad password count per domain controller, if you prefer a window to PowerShell.

5. Stale password or attack?

• Stale password: one user, one source computer, at a steady rhythm (every few minutes, or every time a device syncs), starting right after a password change. Fix it at the source; the lockouts stop.
• Attack: many different user names, or one real name from many addresses; failures at night; addresses outside your network; many 4768 events with code 0x6. Domain controllers should never be reachable from the internet, so internet attacks usually arrive through a Server that is: RDP, Outlook on the web, VPN. Look at Event 4625 on those Servers.
• Lockout as a weapon: an attacker who knows real user names can lock your staff out on purpose, simply by guessing. The lockout policy then protects the passwords but stops the people. Blocking the attacking address is what ends it.

6. Stop it for good: Coinetic reads the failures and blocks the attackers

Doing this by hand means: pulling 4740 and 4771 events from every domain controller, decoding failure codes, mapping ::ffff: addresses to computers, and again for every new lockout. Against attacks from the internet, Windows itself only counts and locks; it does not block the address, so the guessing goes on, and every lockout lands on your helpdesk.

Coinetic takes the attack side off your hands, on every Windows Server and PC:

• Kerberos failures are read for you: on domain controllers Coinetic reads Events 4771 and 4768 together with 4625 and the RDP Event 140, and shows each failed login with address, user name and what it did (counted 1 of 5, auto-banned, already banned).
• Internet attackers are banned automatically: after the number of failed logins you choose within the hours you choose, the address is blocked by a Windows Firewall rule, in both directions. Repeat offenders get longer bans.
• You can look at any time, not just once: the Failed Logins page lists every attempt with its result, and the Filter box finds a user name, address or country in seconds. After a restart, the last 24 hours are shown again.
• For botnets that try once from each of thousands of addresses: one click on Under Attack closes RDP, SSH, SMB and the other admin ports to the internet while your LAN and VPN keep working, and puts everything back when the time is up.
• Works on any Windows language, because events are read by number and field name, not by translated text, and Coinetic keeps the audit settings it needs switched on.
• Your AI security analyst (Pro + AI): right-click any line, ban, port or connection and choose Ask AI, e.g. “Where do these Kerberos failures come from - attack or an old password?”. It looks up this computer's Coinetic data itself and answers in plain words, with what to do on this machine.

Honest limit: addresses from your own network are shown, but never banned. That is on purpose: a PC with an old saved password must not cut itself off. So the internal lockouts from section 4 still have to be fixed at their source by you; Coinetic shows you the address and the user name to start with.

More guides: all Coinetic guides.

Frequently asked

Why do I see Event 4740 only on one domain controller?

The lockout is written by the domain controller that locked the account and by the PDC emulator. Search the PDC emulator and you see every lockout of the domain in one place.

What does Event 4771 failure code 0x18 mean?

Kerberos pre-authentication failed because the password was wrong. A few are typos; a steady stream from one computer is an old saved password; many user names or many addresses point to guessing.

The Caller Computer Name is my Exchange Server. Is Exchange the problem?

Usually not. Exchange passed on a logon from a phone, Outlook or a browser. Look for the user's devices with the old password, or in the IIS logs on the Exchange Server for the client address.

Why does the Client Address start with ::ffff:?

It is an IPv4 address written in IPv6 form. ::ffff:192.168.1.20 is simply 192.168.1.20.