Below is a blog I wrote quite a long time ago, but never posted. Hopefully, this is helpful.

Account Lockout Settings

The first thing that you will want to contemplate is your Account lockout threshold.  If you have this setting set two low this can lead to accounts being locked out.  This is because users may make mistakes when entering their passwords, applications may try to authenticate multiple times, as well as the fact that user may have a multitude of devices that have the credentials stored and will repeatedly attempt to log on. Microsoft’s general guidance on the Account lockout threshold is 10. If your Account lockout threshold is lower than that you should consider raising it.

How Account Lockout Occurs

Everytime a user enters the wrong password when logging on using a resource that authenticates to Active Directory, the badPWDCount attribute has a value that is incremented.  This value is incremented on the domain controller that the user is attempting to authenticate to.  The Domain Controller then retries that authentication attempt with the PDC, since PDC is urgently replicated all password changes.  If the authentication attempt on the PDC fails, the PDC increments its copy of the badPWDCount attribute for that user.  This structure allows the badPWDCount to increment even if different domain controllers are used for authentication.   Once the badPWDCount attribute reaches the Account lockout threshold the account will be locked out.

Troubleshooting Account Lockouts

Domain Controller Auditing

In order to troubleshoot accounts lockouts you will first need to have some auditing in place.

On Domain Controllers, you should have Audit account logon events configured to Audit Success and Failure attempts.

The events that you should be looking for on the Domain Controller are:

Event 4771, which is a Kerberos Pre-Authentication failure.  But be careful this event can be a little misleading since you Windows will intentially fail Pre-Auth the first time to get a list of the DCs encryption capabilities.

Key Information in this event:

Security ID and Accountname tell me which account failed Pre-Authentication.

Under Network Information we see the client address and port, so this can help us identify the source of the failed authentication.

Event 4740, which shows that an account has been locked out.

We see that the Caller Computer Name is listed, which lets us identify the source of the account lockout.

Server and client auditing and logging

On the server or client to which you are trying to authenticate to will need to have Audit logon events enabled for Success and Failure.

Events you will see on the server or client to which you are authenticating to you should look for the following events:

Event 4625, which shows you that an account failed to log on.

Key information in this event include:

Security ID, Account Name, Caller Process, Caller Process Name, Workstation Name, Source Network Address, and Source Port

So how do you find which accounts are locked out?

Step 1: Open the Active Directory Administrative Center

Step 2: Click on Global Search

Step 3: Select the checkbox for Users with enabled but locked accounts

Step 4: Click Add

Step 5: Ensure that the Scope is set to match the location you wish to search

Step 6: Click Search

So how do you determine the DC that the user was logging on to when they get locked out?

Step 1: Download the account lockout tools from here: http://www.microsoft.com/en-us/download/details.aspx?id=18465

Step 2: Launch LockoutStatus.exe

Step 3: Enter the Target User Name and Domain Name and click OK

Step 4: In the lockoutstatus tool view the Orig Lock column.

How do you find the server where the Account Lockout originated?

Option 1: Once you locate the DC where the lock originated you can view the 4740 event and view the Caller Computer Name if it is present.

Option 2: Alternatively you can view the 4771 event and the Client Address should identify the source of the Account Lockout.  It is important that you correlate this to 4740 event to ensure that you are looking at the correct Pre-Authentication failure.

Option 3: If you still cannot locate the source, you can enable Netlogon Diagnostic logging. The following article contains the steps used to enable this logging as well as Fix It scripts that will enable/disable it for you: https://support.microsoft.com/en-us/kb/109626.  All data will be logged to %windir%\debug\netlogon.log and netlogon.bak

In this example, I see that the user lockmeout attempted to authenticate to FCCA01 from the machine FCServer01.  Ultimately an 0xc0000234 was returned, which means the account was locked out.

How do I find out which process caused the account lockout?

On the server or client to which you are trying to authenticate to will need to have Audit logon events enabled for Success and Failure.

As illustrated in the example below the process ID and Name are listed in the event.

If you wish to dig deeper into this you can grab the process ID from the event.

In this example the Caller Process ID is 0x330

We can convert the hex into decimal by using calc.  Simply select Hex, enter 330 and then toggle the radio button to Dec.  In this example, this gives us 816 which is the PID of the process.

Then if you run tasklist /svc, you will get a list of PIDs and what processes are associated with them.

-Chris