Typically, this indicates that a user tried to login several times but provide the wrong password. The security policy threshold for such event being reached the account was locked out to prevent a security breach (in case someone is just trying to guess a password).
This may not be the case all time. It may happen that a service is configured to use a certain account and password and if that password is changed (without updating the service login credentials) than the service will keep trying to login using the old password thus triggering the lockout. If this happened after a recent change of a commonly used account then you should look for services that might use it.
Sometimes it may happen that certain appliations keep the passwords in their cache and try to use it after the user changed his/her domain password.
This is what information is provided (that may help in troubleshooting this event):
Target Account Name - this is the account that was the "target" of the logon attempt
Target Account ID - this is the security id of the account (or the SID) and it should look something like this: S-1-5-21-369898947-932139053-1777090905-3716
Caller Machine Name - the computer from which the logon was attempted
Caller User Name - the user that tried to do the logon
Caller Domain - from what domain was the logon tried (could be different domains)
Caller Logon ID - the logon id of the account that tried to perform the logon (this is a unique identifier that one can use to keep track of a user during a logon/logoff session).
On a Windows NT computer this may be recorded even if auditing is not enabled (see ME304693
Also applicable to Windows NT, the ME814511
says that sometimes this event may occur even if there were no real account lockouts. A supported fix is now available from Microsoft.
As per ME182918
, when users enter a series of incorrect passwords in an attempt to log on to Windows NT using domain accounts and the Bad Logon Attempts limit for the account is reached, the account is locked out at the domain controller. Windows NT generates an account lockout event on the workstation where the failed logon attempts occurred if the audit policy on that workstation enables auditing of failed logon/logoff events. However, no event is logged at the domain controller. Administrators must search the event logs of all client systems to locate the computer where the bad password attempts originated. A hotfix is available.
indicates a method on to automate the detection of account lockouts. Also see ME174073
with tips for interpreting security auditing events related to user authentication.