← Back to home

Product

Account lockouts: why an Active Directory account keeps locking out

The Account Lockouts module answers, from the panel and without an RDP session on the Domain Controller, why an Active Directory account keeps locking out: which computer triggered the last lockout, where the failed authentication attempts are coming from, and what is still retrying with the old password. The survey runs through the agent already installed on the Domain Controller and ends in a diagnosis with coded findings and a PDF report under your brand.

The module opens from the Domain Controller record, and the user search accepts a first and last name, an account name, a UPN or an email address. When the term matches several accounts, the screen lists the matches with the status of each one and the technician picks which one to survey: an account the technician did not pick is never surveyed.

The computer behind the lockout: event 4740 on the PDC Emulator

Windows writes event 4740, the one that records an account lockout, in a single place across the domain: the PDC Emulator. KairosLink reads it there and shows the source computer and the exact time of the last lockout. If the survey ran against a Domain Controller that is not the PDC Emulator, the diagnosis says so, names the domain PDC and offers to run the query again against it.

If lockout auditing is turned off on the Domain Controller, event 4740 is never written and the source of the lockout cannot be determined. KairosLink detects that situation and lets you turn auditing on from the panel, with a mandatory written reason and an entry in the security audit log. It is the only action in the module that changes the Domain Controller. If a domain GPO manages that policy, the diagnosis warns that the GPO will overwrite the local change.

Where the failed sign-ins come from: events 4771 and 4625

The survey covers a 72-hour window and groups the failed authentication attempts (event 4771 for Kerberos and 4625 for NTLM) by source computer, with the attempt count and the time of the last one. That is where the real pattern shows up: a single computer with dozens of failures, or several different sources failing at the same time.

When the failures come from a Domain Controller, the diagnosis flags it separately. It means an intermediary service is authenticating on the user's behalf, and the computer the person actually works on is not to blame.

Three or more failed attempts from the same source within the same second are reported as an automated burst. Nobody mistypes a password three times in one second: that pattern is a device or a service retrying in a loop with a stale credential.

The same survey brings back the domain password policy and the fine-grained password policy (FGPP) that applies to that account, which is what sets the lockout threshold and the observation window the user is actually subject to.

What keeps retrying with the old password

Knowing which computer triggered the lockout is not enough: you have to find what is running inside that computer with the stale credential. With one click, KairosLink analyzes the source computer and reports open or disconnected sessions, scheduled tasks, services, saved credentials, mapped network drives and on-disk profiles tied to that account.

The search runs by SID as well as by account name. When a user profile is deleted from a computer, the scheduled tasks are not deleted: they keep referencing the SID, because there is no longer a name to resolve. By name they do not show up; by SID they do. That case, a deleted profile with live tasks, is flagged as a finding of its own.

When the failures come from a Domain Controller, the equivalent analysis runs on that DC, to identify which service is brokering the authentication. Both analyses are read only: they survey and describe, they do not delete tasks, stop services or touch credentials.

On the account itself, the technician can unlock it, enable it and force a password change at next sign-in. Every one of those actions lands in the Active Directory action history, along with the technician who ran it.

Where the user is signed in: every computer gets asked

Windows keeps no central record of where a domain user is signed in. The only reliable source is to ask the computers themselves, and that is exactly what the panel does: it asks every online computer of the customer, using quser, whether that account has an open session, and shows what each one answered.

The result never blends three different things: the computers with a session, the computers that answered the account has no session, and the computers that could not be asked, each with a written reason (it was offline, it has no agent, it did not answer in time). A computer that did not answer is not a computer without a session, and the screen never counts it as one.

For every session found, it reports whether it is active or disconnected. The distinction matters in a lockout investigation: a disconnected session left open weeks ago with the old password keeps retrying on its own, and nobody is watching it.

The query is read only: it tells you where a session exists and closes none. There is no remote logoff in this module.

Sign-in history: what each Domain Controller actually saw

The Active Directory lastLogon attribute does not replicate between Domain Controllers: each one keeps the value it authenticated itself. Asking a single DC gives you a partial answer, and that is the classic trap with this attribute. KairosLink asks every Domain Controller in the domain and shows each answer, with the DC name next to it and the ones that did not answer in their own list.

Alongside that it shows lastLogonTimestamp, which does replicate, with the warning that it carries a lag of up to 14 days by design in Active Directory. It tells you whether an account is in use; it does not tell you whether it was used this morning.

It also adds up the sign-ins the Domain Controller saw (event 4624 over the same window), grouped by source computer, with the logon type, the count and the most recent one. The number comes with its limit written next to it: a Domain Controller only sees the sign-ins that went through it, so whatever the person did against their own workstation is not there.

That difference is part of the diagnosis, not a limitation being hidden. Asking a computer whether the account has an open session is hard fact. What Active Directory reports about sign-ins is an inference about what one Domain Controller managed to see. The two are shown separately, and every screen states where its number came from.

FSMO roles: which computer is really the PDC Emulator

The diagnosis shows the five FSMO roles of the domain and which Domain Controller holds each one. It matters for one concrete reason: event 4740 is written only on the PDC Emulator, so surveying the wrong Domain Controller leaves the source of the lockout invisible.

The holder of the PDC Emulator role is cross-checked against two different sources within the domain itself. If the two disagree, the diagnosis reports it as a finding instead of picking one on its own. When a domain contradicts itself about which computer is its PDC, that is information for the technician, not noise to paper over.

Deterministic criteria, no AI in the analysis

The evaluation lives in the panel's code, not in a language model: the same data always produces the same findings, each one with its code, its cause and the recommended action. No AI takes part in the analysis of a lockout.

The diagnosis always separates "there is no problem" from "I cannot see it". When a piece of data is missing, the screen says what is missing and why, instead of showing a blank that reads like a result: not finding a 4740 event while auditing is off does not mean the account never locked out.

The full diagnosis comes out as a PDF report with your company's logo and header, ready to hand to the customer.

Account Lockouts is available on the Business and Enterprise plans.

Frequently asked questions

Why does an Active Directory account lock out when the user did nothing?
Because something other than the person keeps authenticating with the previous password. The usual suspects are a scheduled task or a service configured with that account, a mapped network drive, a credential saved in Windows Credential Manager or a device still holding the old password. Each retry adds a failed attempt and, once the domain policy threshold is reached, the account locks itself out even if the user is nowhere near their computer.
What is event 4740 and why does it only exist on the PDC Emulator?
Event 4740 is the Windows security event that records an account lockout and reports the computer it came from. Every Domain Controller forwards bad password attempts to the PDC Emulator, which is the one that keeps the count and decides the lockout, so 4740 is written only in its log. Surveying any other Domain Controller leaves the source of the lockout invisible: KairosLink detects that, warns about it and lets you run the query again against the PDC.
What happens if lockout auditing is turned off on the Domain Controller?
Without that auditing, event 4740 is not written and the source of the lockout cannot be determined. KairosLink reports it as a finding instead of showing an empty screen that looks like a result. From the same diagnosis you turn auditing on for the Domain Controller, with a written reason and an entry in the security audit log, and from then on the next lockout is recorded. If a domain GPO manages that policy, the diagnosis warns you: the GPO will overwrite the local change.
Why does the event sometimes not report the source computer?
That happens when the lockout originates over Kerberos: the 4740 is recorded with the time of the lockout but with no computer name. In that case the diagnosis says so plainly and the investigation continues through the origins of the failed attempts, events 4771 and 4625, which do come grouped by computer with the attempt count and the time of the last one.
What leftovers of a deleted profile can keep locking an account?
Scheduled tasks and services outlive the profile: they keep referencing the account SID, not its name. That is why the source computer analysis searches by SID as well as by account name, and finds tasks belonging to a user whose profile is no longer on disk. The same pass reports saved credentials and mapped network drives, which retry on their own with the old password every time the computer uses them.
How do you tell a human attempt from an automated retry?
By how tightly packed they are in time. A person mistyping a password produces attempts separated by seconds or minutes. Three or more failures from the same source within the same second are typical of a device or a service retrying in a loop, and KairosLink reports them as an automated burst, with the attempts per second and the computer they are coming from.
How do you find out which computers a user is signed in to?
By asking the computers, which is the only reliable source: Windows keeps no central record of a domain user's sessions. The panel queries every online computer of the customer with quser and builds the result from what each one answered, always separating the computers with a session, the ones that answered there is no session, and the ones that could not be reached, each with its reason. For every session found it reports whether it is active or disconnected. The query is read only: it closes no sessions and runs no remote logoff.
Why does the last sign-in reported by Active Directory not always match?
Because the lastLogon attribute does not replicate between Domain Controllers: each one keeps the value it authenticated itself, so asking a single DC gives you a partial answer. KairosLink asks every Domain Controller in the domain and shows each answer separately. lastLogonTimestamp does replicate, but it carries a lag of up to 14 days by design, and the screen says so right next to the value. All of that is an inference about what each Domain Controller managed to see, and it is presented apart from the sessions queried from the computers, which are hard fact.
What are FSMO roles good for in a lockout investigation?
They tell you which Domain Controller to ask. Event 4740 is written only on the PDC Emulator, so a survey run against any other Domain Controller cannot identify the source computer. The diagnosis shows the five domain roles with their holder and cross-checks the PDC Emulator against two different sources: if they disagree, it reports that as a finding rather than picking one on its own.
Try KairosLink free for 14 days

All modules included. No credit card.