Domain admin account frequently locked out

Question

Hello,

Recently a domain admin user in our organization is locked out frequently.

We can see in the event viewer Failed Authentications 4776 (Error Code (custom) 0xC000006A) every one to five minutes and then with Error code 0xC0000234 (because the user is locked).

We don't know how to discover what process or tasks use the user with wrong password ...

We also change the password of the user - still no luck.

How can we track and discover the reason and source of the failed attempts?

thanks in advance...

Answer 1

If you have multiple servers and are remoting to them regularly/irregularly, you may have a user session active on one of the servers, if you forgot to log out, but just disconnected (RDC).
Then at some point you change password and the old session still have stuff that tries to authenticate with the old password from that session, but not constantly, just irregularly.

This can cause your admin-account to become locked at irregular/illogical intervals.

Solution (with a minor but described further down) is to log back in to the servers to have the password updated in the session.
Best to remember to log off servers when work is done though.
My colleagues and me have chased our tail multiple times over the years trying to find the culprit location.

On some older server versions this task in Task Scheduler may be responsible:
Optimize Start Menu Cache Files-{xxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx}

Sometimes I also suspect this task on newer systems:
User_Feed_Synchronization-{xxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx}

Which is an Edge (or previously IE) feed update task. No clue why Microsoft chooses to have this set up as a task that runs under (especially admin) users by default.
It seems the task retains the original logged in credentials, so when user is disconnected and then updates password on domain, this disconnected session still runs with the old credentials.
The User_Feed task runs about once every 6-7 hours under "active" (aka logged in; but also disconnected) users, which is helping delay the actual lockout-time, which helps infuriate us when searching for the problem.

But I have also noticed that the problem sometimes continue even after "refreshing" the credentials with a new login (even with a full logout/login) after password change.
I suspect that the tasks under task scheduler does not always "refresh" the used password at login and causes lockouts anyway. Not sure how or why, as it SHOULD use the current session windows password.

The alternative solution to this problem is to just delete the two mentioned tasks. They are not system critical (afaik).
I say delete, not just disable, because I tried disabeling yesterday, but something had reactivated the task again today... So delete might be the best option.
Time will tell if the task is recreated automatically, in which case I'll see if I can find out how to prevent that from happening.

Or it could be another task that was set up under the user with old credentials.
Other times it has been a saved network credential on some computer.

1. To open Credential Manager, type credential manager in the search box on the taskbar and select Credential Manager Control panel.
2. Select Web Credentials or Windows Credentials 

We now use Netwrix Lockout Examiner, which is great for pointing us in the right direction of our search for culprits. :)
(Just had this problem over the past 2-3 days. And found out via the Examiner that I was still logged in to three of our servers after I had changed my admin password a couple of days ago, so three servers with User_Feed triggered about every 6-7 hours "randomly" triggers the lockout)

Answer 2

Hi @Benjamin Baroukh •

It seems that the account is used somewhere with a wrong password. (scheduled task , script ...ect)

You can check in the vent vierwer of each domain controller to identify the IP source of this lockout, if the audit is alreday enabled:

4740(S): A user account was locked out.

---

Please don't forget to accept helpful answer

---

Answer 3

Hello Benjamin Baroukh,

Thank you for posting in Q&A forum.

1.Check if you can see multiple Event ID 4771(Kerberos authentication) or 4776 (NTLM authentication) via Security log on DC/PDC.
2.Check if you can see Event ID 4740 via Security log on DC/PDC.

3.Find the locked account, and for this domain user account, if you can see Event ID 4771 or 4776 and Event ID 4740 related this domain account, can you see which machine lock the user account via 4776 or 4740?

If so, logon the machine locked out this account to try to check the reason.

• Check Credential Management to see if the user's old credentials are cached (Control Panel)

• Check whether the network disk is mounted with the wrong password

• Check if the user started the service with the wrong password, run scheduled tasks, etc

• Are there other third-party programs that cache incorrect passwords for users
• Other apps or programs that remembered or cached the wrong credential for users.

I hope the information above is helpful.

If you have any question or concern, please feel free to let us know.

Best Regards,
Daisy Zhou