If you’ve been any form an IT Admin for more than a month then you’ve probably ran into locked out Active Directory accounts.
Usually a locked-out account is easy to troubleshoot and resolve. It’s probably a user forgetting a password or forgetting to change their password in a timely manner.
However, sometimes the lockout cause and a sticky resolution aren’t so easy to find. I’m sure you’ve been there. You reset the password and unlock the account. Your user is happy. Ten minutes later you get a call back that the account is locked again. Your user is now frustrated and you’re under pressure.
Fortunately, there a numerous ways to troubleshoot why an AD account keeps locking. I’m going to show you some of the easiest ways below.
What can cause repeated account locking?
Before we start tearing things apart, let look at some of the common causes for AD account lockouts. One of them might trigger an “ah ha!” moment for you and you can avoid all the digging.
It’s also just good knowledge to have.
The most common cause of repeated lockouts is user error. Usually they have forgotten that they changed their password and just keep typing the wrong one in, even after you unlock the account the first time.
Sometimes, you’ll unlock the account, give them a temp password, and then they’ll mess up changing their temp password which again locks the account out.
Usually, an open line of communication (get them on the phone) with your user can sort this one out.
We live in an age where everyone has at least one mobile device that authenticates to using a work account. Cell phones, tablets, watches, etc. will be signing into your domain using saved credentials using technologies such as ADFS.
With the advent of Office 365, Skype for Business, and OneDrive this is almost a requirement in many organizations.
When your user changes their password on their workstation but forgets to update it on their mobile devices the device will keep pinging the network, eventually (quite quickly) locking the account out.
It’s very common for a scheduled task to be setup with domain credentials to run and do what it needs to do. If you’ve configured any scripts or other process to run on a fixed schedule using domain credentials you can end up with a locked account if that task isn’t updated when you change the password.
Sometimes when software is installed it installs services that run under certain domain user accounts. If you change the password the account uses in Active Directory but don’t update the services, then that service will ping the domain every time it tries to authenticate and will lock the account out.
If you just have one user that is having an issue there is a chance it’s a service running on their workstation or VDI that may be toying with thing.
Terminal Services Sessions
It’s possible, when lacking the appropriate policies, for accounts to stay logged into RDP, RemoteApp, Citrix, and other Terminal Services based sessions. An account that remains logged in elsewhere on the domain when you change a password can cause lockouts because the account will keep hitting the domain to re-authenticate.
I always recommend setting policies that log out account that remain logged in past a certain time, such as after 15 or 20 minutes of inactivity. It’s a good security practice too.
AD Integrated 3rd Party Software
Most enterprise software can integrate with AD for authentication these days. Things like LDAP and Radius are common and can be configured with domain credentials. Forget to update the software after changing a password and you end up locking the account when the software tries to authenticate.
Account Lockout Troubleshooting with Account Lockout Tool
The easiest way to find what is causing an account to keep locking is to use the Microsoft Account Lockout and Management Tools (sometimes called ALTools).
Simply download the tools and extract them to your desired folder.
Configure Domain for Logon Event Logging
Before we use the tools, however, we need to make sure you’ve properly configured your domain’s Audit Polies to capture account logon events successes and failures. You should have a domain wide group policy that contains the following settings under Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy:
Audit account logon events: Success, Failure
Audit logon events: Success, Failure
I do recommend these be domain wide settings so that you have the maximum amount of endpoints to capture data from.
Run ALTools LockoutStatus.exe
- Open the folder you extracted ALTools to and launch the exe.
- Navigate to File and click on Select Target.
- Enter the account name that keeps locking in the Target User Name
- Enter your domain name in the Target Domain Name
- Click OK
Review LockoutStatus.exe Results
- The results window opens once you click OK from above.
- Look at each row to determine the Domain Controller that the user’s account has failed against (Orig Lock).
- Look at the end of each row to determine the last time the account failed to authenticate (Lockout Time).
Find the Logon Event to determine Caller (Source) Computer
- Open Event Viewer and connect it to the Domain Controller listed under Orig Lock in the LockoutStatus Tool.
- Right Click on Security and click on Filter Current Log…
- Type 4740 in the Includes/Excludes Event IDs
- Open one of the events and look for the Caller Computer Name under Additional Information. This will tell you what machine the account lockouts are coming from.
- Make note of the timestamp of this event.
Find the Logon Event on the Caller (Source) Computer
- Connect the Event Viewer to the computer listed as the Caller Computer from the steps above.
- Open the Security logs and find the Event that corresponds with the timestamp you noted above.
- Open the event (4625 in this situation) and look for the Failure Reason as well as the Caller Process Name. If you have a software process that keeps retrying authentication and locking the account it should show up next to the Caller Process Name.
When there is No Caller Computer Listed
Sometimes you’re not going to see a caller listed. This will happen when it’s something off domain that is causing the problem such as a mobile device like a cellphone or tablet trying to log into a mail account or terminal services app.
These devices can be hard to track down through networking means because they are usually coming in over the open internet.
I always recommend to start with talking to the user about all the devices they use with their domain credentials. You can help them reconfigure their accounts on those devices or temporarily disable the services (such as email, Skype, OneDrive). I would also recommend that they go home and shut down any computers they may have used for remote work to rule those out.
Recommended for You: Solarwinds Server & Application Monitor (SAM)Know which applications are having issues in your environment before users complain? Know which systems are causing those problems? How about which servers are about to have problems like running out of space or memory?
Automate collection of data and alerting on your applications and servers with Solarwinds Server & Application Monitor so you have these answers.
Get insight into Active Directory, DNS, DHCP, and your Virtual and Applications environments without needing to mess with complex templates or knowing a single line of code.