Account Lockout Issues

Question

Good afternoon,

I work in a hybrid 365/on-prem environment.

We have a password change utility that I've used in the past to reset my password.

Recently, I was working from home and my password expired.

I utilized the reset utility (DUO) and changed my password.

The next day, the PC would not accept my recently changed password even though I had written it down.

This was strange, so I reset it once more - thinking there may have been an error in what I wrote down.

Since that time, my account is unable to stay unlocked for longer than a few seconds at a time.

Our domain admins will unlock my account, and less than five seconds later it will be locked out.

For the life of us, we cannot figure out what is causing the account lockouts.
Its almost like there is a sync issue between our domain controllers - but not sure where to start.

I access all kinds of server and systems in our environment, so its hard to track down the source of the lockouts.

Is there a way to force a password sync or to clear all previous passwords for a user?
I've been unable to access my work account for over a week.

Any assistance in identifying what could potentially be causing this lockout will be appreciated.

Answer 1

Hello Jared Jarvis,

Thank you for posting in the Microsoft Community Forums.

1. First of all, you can check and enable the following logon audit on all DCs, so that we can easily check the protocols and client hostnames or IP addresses that failed to authenticate in the future.

It is recommended to enable the following audit policy on all domain controllers:

GPO: Default Domain Controller

Traditional Audit Policies: Computer Configuration\Windows settings Computer Configuration\Windows settings\security settings\local policies\audit policy

Audit Account Logon Events - Failure

Audit Account Management - Success and Failure

Audit Logon Events - Failure

Or use the advanced audit policy (advanced audit policy overrides the traditional audit policy by default).

Computer Configuration\Windows settings\security settings\Advanced Audit Policy Configuration

Logon/Logoff.

Audit Account Lockout - Failure

Audit Logon - Failure

Audit Account Lockout - Failure Audit Logon - Failure

Audit Kerberos Authentication Service - Failure

Audit Credential Validation - Failure

Account Management.

Audit User Account Management - Success and Failure

We can open CMD with administrator privileges on the domain controller and run the following command to force the policy to be refreshed and to check that the relevant audits are turned on.

gpupdate /force

auditpol /get /category:*

2. After the account has been locked out, determine on which domain control the account is locked out:

a. Note that the account will only be locked on one domain, and then the lockout will be replicated to other domains as an emergency.

b. On any domain machine, download and install lockoutstatus.exe: http://www.microsoft.com/downloads/en/details.aspx?familyid=D1A5ED1D-CD55-4829-A189- 99515B0E90F7&displaylang=en

c. You can refer to the document: “How to use the LockoutStatus.exe Tool” in http://technet.microsoft.com/en-us/library/cc738772(WS.10). aspx

d. Double click the tool, click File -> select target, enter the username and domain information, then click OK. (Here the username is the locked AD account) You can see all the DCs in the domain where the users are being sent incorrect passwords to authenticate.

If you find the case of wrong password verification on both PDC and normal DC, it means that the wrong password verification may be done on normal domain control and then sent to PDC for confirmation. In this case, we need the security log of the ordinary domain control.

3. Then go to the corresponding dc to check the security logs, 4740 (account lockout), 4771 (Kerberos authentication), 4776 (NTLM authentication) and other logs to analyze, can be filtered by the syntax: [System[(EventID=4771 or EventID=4776 or EventID=4740)]] and *[EventData[Data and (Data='user account')]]

First find the point in time of the account lockout in the 4740 event log in the security log on the DC, and then look at a couple of 4771 or 4776 event logs near the 4740 log (that contain the user's account name with an error code of 0X18 or 0xc000006a). If it is Event 4771, it means that the user was using the kerberos authentication protocol, we need to refer to the following steps to troubleshooting:

1. check the “Client Address” in the 4771 event log to get the source IP address, if the address belongs to another domain controller, please log in to the domain controller to check the 4771 event logs near the same time period to get the IP address of the client in question.
2. After getting the IP address of the client, we can login to the client to check:

• Check the credentials management to see if there are any old credentials of the cached users.
• Check to see if the user's old credentials have been cached.
• Check to see if the user's old credentials are cached. Check to see if the user's wrong password is used to mount a network drive.
• Check to see if any other third-party programs are caching the user's wrong password.

If you can't locate what process is causing the problem, you can turn on audit logon event failure audit log on the computer to see if the 4625 log can locate what process is causing the problem. Through the 4776 event log, we can get the Source workstation address, login to the computer to refer to the previous steps to check:

• Check the credentials management to see if there are any old credentials cached for the user.
• Check to see if the user's old credentials are cached. Check to see if the user has mounted the disk with the wrong password.
• Check to see if the user's old credentials have been cached. Check to see if the user's old credentials have been cached.
• Check if any other third-party programs have cached the user's wrong password.

Best regards

Neuvi