Where the failed logons on your domain controllers come from
Open the failed-logon view of any domain and the numbers look alarming: thousands a day, a few accounts at the top every week. Almost all of it is self-inflicted. Knowing which event and which code you are looking at separates the noise from the one line that matters.
Symptom
A dashboard of “failed logons” on domain controllers shows a steady stream, dominated by a handful of accounts and machines. Lockouts follow a pattern: the same users, Monday mornings, after a password change.
Cause: three events, not one
Failed authentication against a domain shows up in different events depending on the protocol, and dashboards often count only one of them:
| Event | Where | What failed |
|---|---|---|
4771 |
domain controller | Kerberos pre-authentication (user or computer, usually a wrong password) |
4776 |
domain controller | NTLM credential validation for a domain account |
4625 |
the machine being logged on to | the logon itself — on a DC only when the logon is to the DC |
So most failed domain logons are 4771 and 4776 on the DCs. 4625 on a DC comes from connections to the DC itself, such as failed LDAP simple binds or access to its shares. The end of the trail, a lockout, is event 4740, logged on the domain controller that holds the PDC emulator role, with the Caller Computer Name that sent the bad password.
The codes that explain most of it
| Code | Event | Meaning |
|---|---|---|
0x18 |
4771 |
wrong password |
0x12 |
4771 |
account disabled, expired or locked |
0x17 |
4771 |
password expired |
0x25 |
4771 |
clock skew too great |
0xC000006A |
4776, 4625 |
wrong password |
0xC0000064 |
4776, 4625 |
user name does not exist |
0xC0000234 |
4776, 4625 |
account locked out |
0xC0000072 |
4776, 4625 |
account disabled |
0xC0000071 |
4625 |
password expired |
The usual sources of noise
- A stored old password. A mapped drive with saved credentials, a scheduled task or a service running as a user, a disconnected RDP session, a phone mail client. The user changed the password; the device keeps trying the old one until the account locks.
- Service accounts nobody owns. A script or application with a hard-coded password that was rotated. These produce wrong-password codes from the same server, at the same interval, forever.
- Decommissioned names. Monitoring or backup tools still trying an account that was deleted produce
0xC0000064in a steady rhythm. - Clock problems show as
0x25— see clock skew breaks your incident timeline.
Fix
Group by account, source machine and code, not by account alone. A single account failing from one server every 30 minutes with 0x18 is a stale credential: find the task or service on that server. One source failing for many accounts with a mix of 0xC0000064 and 0xC000006A is a different shape entirely, and that is the pattern worth an alert.
Clean up the stale-credential sources one by one. Each one removed makes the remaining failures more meaningful, and the lockout calls to the help desk go down at the same time.
Takeaway
Count 4771, 4776 and 4625 together, read the codes, and clean the recurring sources. A failed-logon view is only useful once its baseline is close to quiet.