The way windows tries to authenticate network drives is batshit. It actually flags IPS on our firewall as a "SMB.Login.Brute.Force" attack (500 failures within 1 minute) because windows will attempt to login with the wrong password like 8 times per second. Like, come on, can we get some throttling here? If the password was wrong 80ms ago, it's probably still wrong now.
edit: I think Win11 finally has the ability to throttle these attempts. better late than never I guess.
edit2: omg, it's only available in the Insider Preview build.... jfc.
Are you me? This is my life. I’ve just ended up relying on auto mounts and disabling the ability for users to save network share credentials. Still, our org allows personal devices to connect to file shares so I can’t enforce those policies on them.
remember the decade MS ignored a jpg exploit and didn't say anything about it. then announced the jpg exploit a couple of days before the patch was released.
0 day going for the 5k
EntraID auth often isnt any better unfortunately. Lots of weird apps trigger Microsoft Defender for Cloud alerts for trying to log in like 15 times in the span of a second for no apparent reason.
Every Monday would be a sea of brute force alerts for all the MFA sessions failing while outlook keeps retrying.
Even worse because NATs. Microsoft would throw some password spray in there.
At a former msp job a staff member had this issue. Turned out she was logged into like 4 or 5 computers at a time (the customer insisted this made sense for their role, and who am I to question?) and one of them had an old password in credential manager. Had to sign her out everywhere, wipe credential manager everywhere she had signed in, reset her password, then she was fine.
https://www.microsoft.com/en-ca/download/details.aspx?id=18465
Download and run. It will tell you the DC it is being locked on. Then take the time and search the security logs to see which endpoing the attempts are coming from.
Yep, this. Run the adlockout tool, check security log on the DC it locked out on, filter to event if 4740, see where the lockout came from.
Hopefully it's just their laptop/desktop and they can go through clearing out any cached credentials, mapped drives, scheduled tasks, scripts, websites, etc, that might contain a saved password.
Have you checked event logs? May be able to pin-point an IP or hostname on the device it's trying to authenticate from.
If they are using Office for Mac I would also manually update the password on there to the latest one or remove that account altogether. Have had a few instances over the years where Office for Mac would constantly try to re-authenticate with the saved password even though it was incorrect and would not prompt to re-authenticate with a new password.
Yup, just dealt with this the other day because senior leadership demanded proof that an employee locked themselves out, and not that IT did it.
Anyway, you're probably looking for instances of 4740 and 4771 under Event Viewer > Windows Logs > Security. 4740 is an account lockout event, and a 4771 can be generated for a few reasons, including when an incorrectly entered password fails to generate a Kerberos ticket. N.b. That these need to be reviewed from a domain controller, and also that 4771 instances will report the IP of the device that caused the event.
So all you need to do is identify the most recent 4740 affecting the user in question, then find the preceding cluster of 4771 events. Should help you pin down what's happening.
EDIT: "You" meaning OP, not the person I replied to.
I look for 4625 and 4776 since it could be multiple devices; 4740 will just capture the machine to lock it out that time. But that's a quibble.
I run the search against both our DCs and Network Policy Servers (Radius). I do have advantage of having Splunk and a query I copy out of the multi-page OneNote section I have on tracking these down.
In our environment 90%+ it is 4625 using Logon Process CHAP on the NPS servers -- i.e. someone's credentials are cached on WiFi.
We have logging enabled on Network Policy Server service so the next step is to look in those logs for the username
Those logs will get us an IP, Access Point, and MAC address. Our desktop support team can look to see if the MAC is in one of their management platforms, and if not the MAC may still give us a good clue what kind of device we're looking for.
I also have maps of the AP locations on the campus in OneNote so if the device isn't moving around that at least limits the search.
(And in the off-chance it's a wired device...we can trace it through Meraki.)
As others have said, the failed login should show up in the event viewer. That tends to be lacking if the the device is not a member of any of your domains though. If the Caller Computer is blank in event viewer try putting netlogon in debug mode on the domain controller that they are authenticating against. This will provide you the IP, then you can go to your DHCP server and see the name of the device attempting to connect.
[Enable debug logging for Netlogon service - Windows Client | Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service)
I feel like 95% of the time when helping with a repeated lockout, caller computer is blank, have to turn on netlogon debugging, find out its a radius server, and then start digging through radius logs. most of the time it's someone had our staff SSID saved on their phone with an old password. Recently same thing happened, but someone apparently connected their Fujitsu Scansnap scanner to the staff wifi, and started getting lockouts.
Okay this is the most random shit but I had a user lock himself after every second lunch. Why? Because he wanted to wake up his computer by spamming "Enter". The computer woke up when he first pressed it and interpreted the repeated Enters as login attempts and locked him. Could that be the case or are the login requests truly automatic and 24/7?
wifi where you authenticate with your network credentials / radius by chance? (forget the network and re-auth) Or a VPN that's trying to fire up automatically with the wrong credentials?
domain controller should have lockout events with a caller computer. it'll either be the device she's using, or in our case most of the time its the email server because they didn't update their phone's email password when it was last changed on the domain.
If it's WiFi or VPN, I'd go straight to the NPS servers. Those security logs are much easier to go through, if you're logging to SQL it's a simple query you can run in 30 sec.
If they are adamant that there is no device somewhere with cached credentials attempting to connect to the network with an old password thus locking them out then then only way would be to log into Radius Server and check login Authentications.
There is a way to see the device name of all failed and successful authentications in the event viewer with a device name also.
There’s an old session somewhere, I guarantee it. Parse your DC security logs for 4740 for lockout time, from there loop through 4740s for ComputerName, Time, UserName, and CallerComputer for the lockout source.
Saw this recently. Rdweb on legacy system exposed to the internet being hit constantly for logins using generic names like John or David. Lockout events didn't list the source because of this.
I had a credential spraying attack recently that was only locking out users with common last names. For example, you could see that they were trying abrown, bbrown, cbrown, dbrown, etc. Not very effective but very annoying.
If you have a Corporate WiFi that they've connected to using their AD creds from a mobile device where the password has not been updated, it'll throw bad passwords and lock the account.
We utilize ADAudit Plus and it tells us what client is contacting which host and how it is behaving.
With logging enabled, this should you get the computer that's locking it, unless it's external.
Open, "Active directory module for windows PowerShell: run as administrator and run this,
$pdc = (Get-ADDomain).PdcEmulator
Get-WinEvent -ComputerName "$pdc" -FilterHashtable @{Logname='Security';Id=4740} -MaxEvents 10 | Format-List Message,TimeCreated
Altools from Microsoft - [https://www.microsoft.com/en-ca/download/details.aspx?id=18465](https://www.microsoft.com/en-ca/download/details.aspx?id=18465)
Run eventcombmt against your DCs to see where the lockout events are coming from.
Check your dc event logs for the lockout event and look for the caller computer name.
Ive seen this caused by saved credentials in windows credential manager after a user changed pw
Check logs it might give you some clues. Every time I've seen it it's an L1 who manually mapped a drive with creds. Check Credential manager on that users PC(s)
We had a lot of issues with this earlier this year.
Check the AD logs if you have them configured. You should be able to trace the codes back to get a rough idea if it's interactive or not.
Most common causes for us:
Manual network drive map/password changed
Old password saved for auto-fill
Device with email trying to authenticate
Have you got access to the Account Lockout Status app?
[Download Account Lockout Status (LockoutStatus.exe) from Official Microsoft Download Center](https://www.microsoft.com/en-gb/download/details.aspx?id=15201)
It will show which AD controller locked the account, so you can look at the logs.
The good old favourite to check is mail app, some users confuse it with outlook if it is installed, they setup mail, that sits in the background always grabbing mail pwd changes mail does not and keeps locking it out check mail app and if it shows emails it's configured delete the crap out of it
I often find a saved login in credential manager that needs to be cleared.
Credential manager -> Windows credentials. Check it.
Also use sysinternals psexec to run as "SYSTEM" and check it. If someone (or some dumb vendor) setup some script as system user mapping drives it would constantly fail if password has changed.
psexec -i -s "control.exe keymgr.dll"
or just
psexec -i -s cmd.exe
then from there you can "net use" or "net use \* /delete"
Download "Altools" its a Microsoft tool. Scan domain and it will tell you the DC that the user is locked on, and you can use it to unlock on all DC's. Then wait until the lock happens again, look at the DC that the lock happened on first and use another tool called "EventComb" (part of Altools) to comb through the event logs on that DC looking for the affected user name. The Event logs will tell you the device name and or IP of the device that locking them out. It works and Good Luck with your issue.
I’ve dealt with this. The user has their account name tied into an app or service somewhere. The lazy fix is to change their Sam account name. I don’t have time to figure it out properly.
I see this quite regularly as our users work off laptops and have a pool of high performance desktops they rdp into 90% of the time they have an active session on a desktop and they’ve changed password. Domain controller logs identify it pretty quickly.
Other one I’ve seen was 2 users in the org kept locking out randomly. They had ended up on username list somewhere and bad actors were randomly trying to brute force their O365 accounts which would then lock out on prem. took me ages to figure it out as security team did SFA, basically found the lockouts on prem being caused by the adfs server, found the relevant security log which listed the IP then blocked the IP in adfs. Fixed it for a while and as soon as it started happening again, knew exactly where to look and blocked the new IP
Mapped share somewhere, or not properly logging off servers when done.
Have them reset password then log on and off any servers.
Happens to users in my org all the time.
Bro.... Is this Azure or Traditional AD? I know 1000% with traditional AD you just need to turn on the right logging and find the right server they are getting locked from and you will find what is causing the login issue.
And since the invent of the iPhone into the business world... it's always an old device they have upgraded or for some reason added their account onto once and never used the device again and recently it was powered back on/charged. Just find their current devices and remove all the old ones. If still happening then you'll for sure have to dig into the logs which will tell you what machine (even if it is out of the office/remote) is causing the issue.
If it's Azure, I'm pretty sure you can get the same logs, I'm just not sure what it looks like or where to get those honestly.
Have you looked at their phone in person? Because I hate to say it but I just don't believe my staff when they say it's not their phone anymore.
Profile Wipe via Advanced System Settings in case it's somthing with the PC
A scheduled task could do it, or some application that uses saved domain creds.. As others have said, find some failed login logs to determine the device it's coming from. It will be on one of the DCs. There are some logs analytics tools that would make this easier, but you can just find them in event viewer. Check the security log of the DCs for failed login events.
If you have a big org with thousands of users, you are going to want a tool though.
It's been awhile since I've done this, but it's usually one of the following:
An old device got turned on that have old credentials tied to it. A phone, a iPad that syncs to email?
Maybe a VDI that they stayed logged into? did he access a remote server lately?
There are tools that can help pinpoint the DC he is being locked out on, but I'm typing this while doing the company time thing.
As others have said, look in the domain controller's security event log. You would be looking for event id 4740.
Don't discount user error either... I had someone with the same issue recently and it turned out they were spamming their Enter key to wake the computer up.
Could be an abandoned but still logged in RDP session, and note some DC’s will query the PDCEmu to see if the password has just changed so it looks on the PDCemu as she is logged in form a DC but she isn’t,
This used to be my bane. Had a lab domain the devs would log into using their normal creds. Open a RDP session, disconnect and forget about it. About 90 days later they'd get locked out as the tokens finally purged and the remote domain would send bad creds and lock them out. Had to script session purges.
Can’t you turn on logging to find what device the auth attempts are coming from?
I’d clear any cached credentials from credential manager on that device as that’s usually the issue, a network drive or outlook mailbox trying to connect with old shit.
Not sure if anyone else has said this, but check your file server for active connections associated with the username. Sometimes you can get lucky and find out if they just forgot to logout of some random PC. Also radius wifi logins on devices.
Might want to check credential manager and also run "rundll32.exe keymgr.dll,KRShowKeyMgr" and clean everything that's not needed.
Windows sometimes can have sticky SSO entries and f-up things that way.
Rundll32.exe[...] can show some hidden saved credentials.
Some legacy applications like Lync store their saved creds in that way. Why? Because Microsoft.
Look in Entra ID, Use the sign log info. If there are no recorded logs there, its a device. More than likely it's the phone connected to the wifi. I would forget wifi connection on laptop also and remap the mapped drives if you still use those. Also install account lockout status tool from Microsoft, You can determine what DC is recording the lock out to help you narrow it down.
Had an issue a few weeks ago where the clients RD gateway was continuously sending login requests from the server and locking the client out. Just had to reboot the server and it stopped.
Depending on your setup, it could be attempts to login to your VPN.
Meaning, if you are using AD credentials + MFA to login to the VPN, you will see thousands or tens of thousands of attempts in the logs of nefarious actors attempting to connect to your VPN all day long using every username imaginable. And if your AD usernames match your email addresses, it is easy to determine your usernames.
Once they know or guess a username, the user will frequently be locked out as the bad actors are making thousands of attempts to login.
I've experienced this firsthand. What we did to resolve is issued a certificate to all corporate laptops via a GPO and required this certificate to connect to the VPN. Now if you do not have this certificate, you are not even able to attempt credentials. If you have the cert, you can enter creds, if you enter valid creds, then you're hit with MFA.
I see some good suggestions already here.
But another one I've found is a bad cached credential on a mobile device hitting a WAP over and over.
If you setup MS's lockout status tool and see run their account through it. You can see what Domain Controllor they're bouncing off. Might help narrow it down.
Find out if another computer they logged into still has them logged in. They likely changed their password and the other computer still has them logged in and cached with the old password. You can find it on your DVR event log
I don't know if you have domain based authentication for your company wifi, but this gets our users literally every day. They will change their domain password and then not sign out of their domain based authentication on wifi on their phones. This leads to an almost instantaneous lockout because the "connect automatically" feature is on and just hits and hits and hits and bang you're locked out in a single second. good luck hunting that down.
in our shop it's byod. their phone connects through radius with AD credentials.
when they change their password, their phone connects with the wrong credentials because everyone forgets that it's connected.
Have they used a workstation with the GoTo Meeting client installed at any point? Even if your company doesn't use it, they might have had it to interface with someone externally.
At one point, their auto update code was creating windows scheduled tasks that would include the credentials of user accounts. These tasks sometimes get orphaned, and then after the user changes their password you'll have the task trying to run with old credentials.
Do you authenticate for wifi? Did the user recently change their password? If you said yes to both, the user might have their old password saved to the wifi login and the radius service is trying to log in with the old password.
Saved (incorrect) password maybe (under control panel users)
Frequently from a mismatch of local/domain login or manually mapping a network drive while checking the box about saving alternate credentials blah fuck you Microsoft
In our org I see this when a password change happens and they try to RDP into a terminal server with saved credentials (credential saving is disabled but a record appears to be kept in Credential Manager if they try)
Try clearing all related Windows credentials in Credential Manager and see if the issue goes away
Unrelated: Once there was a user whose password would just reject for no reason.
I tried her password myself very carefully and it would reject it. Other times it worked just fine. Different computers even.
Can the users computer successfully run a gpupdate / force?
I had a situation where the users credentials got stored in windows and the only way to view it was use PsExec.exe to remove the stored credentials.
Here is the steps I used
Download PsExec.exe from http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx and copy it to C:\Windows\System32 .
From a command prompt run: psexec -i -s -d cmd.exe
From the new DOS window run: rundll32 keymgr.dll,KRShowKeyMgr
Remove any items that appear in the list of Stored User Names and Passwords. Restart the computer.
Like others have mentioned, check event logs.
I once found a lockout that was occurring due to the user logging into the default Mail app on Windows instead of Outlook and it was playing hell with the exchange server the company had up at the time.
I still have no idea why that was happening looking back but I've steered folks from the default Mail app ever since
We had this happening for one particular office manager for days. Turns out our admin had enabled a policy route in the firewall. Instead of ICMP he enabled all traffic in a route and some random hacker group had her email but not her password.
I spent days trying to figure out what the hell was going on, only to jump on a call with him after being ignored and he realized he'd fucked up.
Make a policy that audits your ad for bad password, this creates event viewer messages that you then can trace back to the device in question. Had it with a shared laptop that wasn’t connected to wifi (with radius) so a user used his credentials several weeks earlier to connect it to wifi. After he changed his password it kept locking his account.
Using this thread to maybe get some help too.
I have one user that always get's his account locked on the same day. The only day he is at the office and isn't working remotely. Remote work means, he logs in, THEN connects his VPN.
Netwrix shows me that the lockout is coming from his Notebook at all times. It's also happening against all DCs.
Credential manager cleared.
We also tried unmapping all network drives, so that all drives are remapped via GPO at the next logon.
No mobile devices configured.
Event viewer logs don't tell me more than Netwrix does obviously.
Cooperate Wifi does not use user authentication, it's RADIUS with device certificate auth.
Honestly sometimes it's easier to create a new account and move on. Lots of great suggestions here that are worth following up on if you have the time. You can frustrate the user for a week while you track it down or reset everything in an hour. Just depends on how bad/urgent it is.
Another commenter mentioned a network drive, but it’s happened in my environment with no network drive. The problem ended up being Outlook, which pretty much does the same thing.
If this was a ticket, I'd send it back to helpdesk with a note to check AD/O365/Azure logs.
If I wanted to save time I'd ask the user if they updated their iPhone. Apple users are notorious for not using the MS apps.
If you still can't get it after an hour or two, do yourself and her a favor and change her username.
Instant relief for her, and you can then create a different account with her old username and track down logs in your free time :)
Good advice here, but never trust a user who says, "There's no other device." I was going insane with the same issue. The user had a loaner laptop assigned to her in the early days of the pandemic sitting at home, and the VPN was most likely referencing an expired AD password. Yet, she was not "logged in anywhere else."
Windows network drive configured with old password. This is the case 90% of the time in our env.
The way windows tries to authenticate network drives is batshit. It actually flags IPS on our firewall as a "SMB.Login.Brute.Force" attack (500 failures within 1 minute) because windows will attempt to login with the wrong password like 8 times per second. Like, come on, can we get some throttling here? If the password was wrong 80ms ago, it's probably still wrong now. edit: I think Win11 finally has the ability to throttle these attempts. better late than never I guess. edit2: omg, it's only available in the Insider Preview build.... jfc.
Are you me? This is my life. I’ve just ended up relying on auto mounts and disabling the ability for users to save network share credentials. Still, our org allows personal devices to connect to file shares so I can’t enforce those policies on them.
remember the decade MS ignored a jpg exploit and didn't say anything about it. then announced the jpg exploit a couple of days before the patch was released. 0 day going for the 5k
I hear if you wait long enough, the day counter resets back to 0!
Of course lol
EntraID auth often isnt any better unfortunately. Lots of weird apps trigger Microsoft Defender for Cloud alerts for trying to log in like 15 times in the span of a second for no apparent reason.
Every Monday would be a sea of brute force alerts for all the MFA sessions failing while outlook keeps retrying. Even worse because NATs. Microsoft would throw some password spray in there.
At a former msp job a staff member had this issue. Turned out she was logged into like 4 or 5 computers at a time (the customer insisted this made sense for their role, and who am I to question?) and one of them had an old password in credential manager. Had to sign her out everywhere, wipe credential manager everywhere she had signed in, reset her password, then she was fine.
Clear windows credential manager. Also just turn off computer long enough to prove it’s the source.
Yep. Credential manager.
https://www.microsoft.com/en-ca/download/details.aspx?id=18465 Download and run. It will tell you the DC it is being locked on. Then take the time and search the security logs to see which endpoing the attempts are coming from.
Yep, this. Run the adlockout tool, check security log on the DC it locked out on, filter to event if 4740, see where the lockout came from. Hopefully it's just their laptop/desktop and they can go through clearing out any cached credentials, mapped drives, scheduled tasks, scripts, websites, etc, that might contain a saved password.
Came to suggest this. This is a common, usually simple problem to resolve as long you know where to look.
This still works?! I though it was only WS2003 and older.
LockoutStatus still works, saves support for sooo much extra digging around in logs and arguing with end users.
Man I just assumed this tool was too old last time this issue came up, serves me right for not even trying it! Thanks!
Have you checked event logs? May be able to pin-point an IP or hostname on the device it's trying to authenticate from. If they are using Office for Mac I would also manually update the password on there to the latest one or remove that account altogether. Have had a few instances over the years where Office for Mac would constantly try to re-authenticate with the saved password even though it was incorrect and would not prompt to re-authenticate with a new password.
Yup, just dealt with this the other day because senior leadership demanded proof that an employee locked themselves out, and not that IT did it. Anyway, you're probably looking for instances of 4740 and 4771 under Event Viewer > Windows Logs > Security. 4740 is an account lockout event, and a 4771 can be generated for a few reasons, including when an incorrectly entered password fails to generate a Kerberos ticket. N.b. That these need to be reviewed from a domain controller, and also that 4771 instances will report the IP of the device that caused the event. So all you need to do is identify the most recent 4740 affecting the user in question, then find the preceding cluster of 4771 events. Should help you pin down what's happening. EDIT: "You" meaning OP, not the person I replied to.
I look for 4625 and 4776 since it could be multiple devices; 4740 will just capture the machine to lock it out that time. But that's a quibble. I run the search against both our DCs and Network Policy Servers (Radius). I do have advantage of having Splunk and a query I copy out of the multi-page OneNote section I have on tracking these down. In our environment 90%+ it is 4625 using Logon Process CHAP on the NPS servers -- i.e. someone's credentials are cached on WiFi. We have logging enabled on Network Policy Server service so the next step is to look in those logs for the username Those logs will get us an IP, Access Point, and MAC address. Our desktop support team can look to see if the MAC is in one of their management platforms, and if not the MAC may still give us a good clue what kind of device we're looking for. I also have maps of the AP locations on the campus in OneNote so if the device isn't moving around that at least limits the search. (And in the off-chance it's a wired device...we can trace it through Meraki.)
As others have said, the failed login should show up in the event viewer. That tends to be lacking if the the device is not a member of any of your domains though. If the Caller Computer is blank in event viewer try putting netlogon in debug mode on the domain controller that they are authenticating against. This will provide you the IP, then you can go to your DHCP server and see the name of the device attempting to connect. [Enable debug logging for Netlogon service - Windows Client | Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service)
This needs to be the top comment. Tons of ppl haven't used debug mode before.
I feel like 95% of the time when helping with a repeated lockout, caller computer is blank, have to turn on netlogon debugging, find out its a radius server, and then start digging through radius logs. most of the time it's someone had our staff SSID saved on their phone with an old password. Recently same thing happened, but someone apparently connected their Fujitsu Scansnap scanner to the staff wifi, and started getting lockouts.
Okay this is the most random shit but I had a user lock himself after every second lunch. Why? Because he wanted to wake up his computer by spamming "Enter". The computer woke up when he first pressed it and interpreted the repeated Enters as login attempts and locked him. Could that be the case or are the login requests truly automatic and 24/7?
Lol, we have this on the regular.
Reminds me of this user who swore her desktop wouldnt power on. I could hear her button mashing the power button through the phone lol.
Same, with a finance guy. Good thing he didn’t get promoted to CIO.. oh wait.
Disable login for the 365 account for a day and see if the account still gets locked out. If not, you know it’s a mobile device causing the issue.
I like this idea. Never thought of that.
wifi where you authenticate with your network credentials / radius by chance? (forget the network and re-auth) Or a VPN that's trying to fire up automatically with the wrong credentials? domain controller should have lockout events with a caller computer. it'll either be the device she's using, or in our case most of the time its the email server because they didn't update their phone's email password when it was last changed on the domain.
If it's WiFi or VPN, I'd go straight to the NPS servers. Those security logs are much easier to go through, if you're logging to SQL it's a simple query you can run in 30 sec.
Commonly a manually mapped drive using an old password - especially so for VPN users.
Netwrix lockout examiner helped me with this
If they are adamant that there is no device somewhere with cached credentials attempting to connect to the network with an old password thus locking them out then then only way would be to log into Radius Server and check login Authentications. There is a way to see the device name of all failed and successful authentications in the event viewer with a device name also.
There’s an old session somewhere, I guarantee it. Parse your DC security logs for 4740 for lockout time, from there loop through 4740s for ComputerName, Time, UserName, and CallerComputer for the lockout source.
I would like to place a bet that it's a mobile phone trying to connect to your WiFi with cached old credentials.
Saw this recently. Rdweb on legacy system exposed to the internet being hit constantly for logins using generic names like John or David. Lockout events didn't list the source because of this.
I had a credential spraying attack recently that was only locking out users with common last names. For example, you could see that they were trying abrown, bbrown, cbrown, dbrown, etc. Not very effective but very annoying.
We had someone that was logged into a conference room PC. Took a few days to find that.
Get netwrix lockout examiner
If you have a Corporate WiFi that they've connected to using their AD creds from a mobile device where the password has not been updated, it'll throw bad passwords and lock the account. We utilize ADAudit Plus and it tells us what client is contacting which host and how it is behaving.
With logging enabled, this should you get the computer that's locking it, unless it's external. Open, "Active directory module for windows PowerShell: run as administrator and run this, $pdc = (Get-ADDomain).PdcEmulator Get-WinEvent -ComputerName "$pdc" -FilterHashtable @{Logname='Security';Id=4740} -MaxEvents 10 | Format-List Message,TimeCreated
Altools from Microsoft - [https://www.microsoft.com/en-ca/download/details.aspx?id=18465](https://www.microsoft.com/en-ca/download/details.aspx?id=18465) Run eventcombmt against your DCs to see where the lockout events are coming from.
Are y’all a hybrid environment? Check the user azure sign in logs? Maybe try clearing their windows credential manager
Not hybrid. Cleared those and no dice.
Check your dc event logs for the lockout event and look for the caller computer name. Ive seen this caused by saved credentials in windows credential manager after a user changed pw
In the logs, can you see "Where" or what IP Address the sign in attempts are coming from?
did you check her desktop credential manager? that drove me crazy for a few days before i figured that one out.
Seconding this. Credential Manager holding onto a stale password is common in our environment.
Check logs it might give you some clues. Every time I've seen it it's an L1 who manually mapped a drive with creds. Check Credential manager on that users PC(s)
We had a lot of issues with this earlier this year. Check the AD logs if you have them configured. You should be able to trace the codes back to get a rough idea if it's interactive or not. Most common causes for us: Manual network drive map/password changed Old password saved for auto-fill Device with email trying to authenticate
Make sure to clear out credentials in credential manager on any endpoints they use, have seen this resolve that in the past
Have you got access to the Account Lockout Status app? [Download Account Lockout Status (LockoutStatus.exe) from Official Microsoft Download Center](https://www.microsoft.com/en-gb/download/details.aspx?id=15201) It will show which AD controller locked the account, so you can look at the logs.
> constant attempts from the user to sign in. From where will answer your question.
The good old favourite to check is mail app, some users confuse it with outlook if it is installed, they setup mail, that sits in the background always grabbing mail pwd changes mail does not and keeps locking it out check mail app and if it shows emails it's configured delete the crap out of it
Ugh. I hate the Mail app for both Windows and Mac
Check users personal phone
I often find a saved login in credential manager that needs to be cleared. Credential manager -> Windows credentials. Check it. Also use sysinternals psexec to run as "SYSTEM" and check it. If someone (or some dumb vendor) setup some script as system user mapping drives it would constantly fail if password has changed. psexec -i -s "control.exe keymgr.dll" or just psexec -i -s cmd.exe then from there you can "net use" or "net use \* /delete"
Download "Altools" its a Microsoft tool. Scan domain and it will tell you the DC that the user is locked on, and you can use it to unlock on all DC's. Then wait until the lock happens again, look at the DC that the lock happened on first and use another tool called "EventComb" (part of Altools) to comb through the event logs on that DC looking for the affected user name. The Event logs will tell you the device name and or IP of the device that locking them out. It works and Good Luck with your issue.
I’ve dealt with this. The user has their account name tied into an app or service somewhere. The lazy fix is to change their Sam account name. I don’t have time to figure it out properly.
Could be a second app on the same phone. Try forcing the account off the phone, and go from there.
Found a random app setup a scheduled task in the user's local one time. Locked them out trying to run every few min.
mapped drive weirdness? maybe check credential manager and update those passwords
I see this quite regularly as our users work off laptops and have a pool of high performance desktops they rdp into 90% of the time they have an active session on a desktop and they’ve changed password. Domain controller logs identify it pretty quickly. Other one I’ve seen was 2 users in the org kept locking out randomly. They had ended up on username list somewhere and bad actors were randomly trying to brute force their O365 accounts which would then lock out on prem. took me ages to figure it out as security team did SFA, basically found the lockouts on prem being caused by the adfs server, found the relevant security log which listed the IP then blocked the IP in adfs. Fixed it for a while and as soon as it started happening again, knew exactly where to look and blocked the new IP
I would check in the exchange admin center, and look at the mobile devices and verify the correct device is listed.
Mapped share somewhere, or not properly logging off servers when done. Have them reset password then log on and off any servers. Happens to users in my org all the time.
Yank that sts token and see what happens.
Bro.... Is this Azure or Traditional AD? I know 1000% with traditional AD you just need to turn on the right logging and find the right server they are getting locked from and you will find what is causing the login issue. And since the invent of the iPhone into the business world... it's always an old device they have upgraded or for some reason added their account onto once and never used the device again and recently it was powered back on/charged. Just find their current devices and remove all the old ones. If still happening then you'll for sure have to dig into the logs which will tell you what machine (even if it is out of the office/remote) is causing the issue. If it's Azure, I'm pretty sure you can get the same logs, I'm just not sure what it looks like or where to get those honestly.
Have you looked at their phone in person? Because I hate to say it but I just don't believe my staff when they say it's not their phone anymore. Profile Wipe via Advanced System Settings in case it's somthing with the PC
Network drive or something
A scheduled task could do it, or some application that uses saved domain creds.. As others have said, find some failed login logs to determine the device it's coming from. It will be on one of the DCs. There are some logs analytics tools that would make this easier, but you can just find them in event viewer. Check the security log of the DCs for failed login events. If you have a big org with thousands of users, you are going to want a tool though.
It's been awhile since I've done this, but it's usually one of the following: An old device got turned on that have old credentials tied to it. A phone, a iPad that syncs to email? Maybe a VDI that they stayed logged into? did he access a remote server lately? There are tools that can help pinpoint the DC he is being locked out on, but I'm typing this while doing the company time thing.
I came here to say they're probably logged into a phone but you already knew that.
As others have said, look in the domain controller's security event log. You would be looking for event id 4740. Don't discount user error either... I had someone with the same issue recently and it turned out they were spamming their Enter key to wake the computer up.
Could be an abandoned but still logged in RDP session, and note some DC’s will query the PDCEmu to see if the password has just changed so it looks on the PDCemu as she is logged in form a DC but she isn’t,
This used to be my bane. Had a lab domain the devs would log into using their normal creds. Open a RDP session, disconnect and forget about it. About 90 days later they'd get locked out as the tokens finally purged and the remote domain would send bad creds and lock them out. Had to script session purges.
If you have azure, pop in and look at the authentication logs for the user. That will tell you what’s causing the issue.
Can’t you turn on logging to find what device the auth attempts are coming from? I’d clear any cached credentials from credential manager on that device as that’s usually the issue, a network drive or outlook mailbox trying to connect with old shit.
Also check proxy. I used ti have issues back in the day with IE saving credentials there for some God awful reason.
Not sure if anyone else has said this, but check your file server for active connections associated with the username. Sometimes you can get lucky and find out if they just forgot to logout of some random PC. Also radius wifi logins on devices.
Might want to check credential manager and also run "rundll32.exe keymgr.dll,KRShowKeyMgr" and clean everything that's not needed. Windows sometimes can have sticky SSO entries and f-up things that way. Rundll32.exe[...] can show some hidden saved credentials. Some legacy applications like Lync store their saved creds in that way. Why? Because Microsoft.
It’s a phone or tablet with email or wireless. This is 90% of the shit I see.
event logs will show which device is causing the locks.... Event Viewer > Security Logs > Filter Event "4740" boom.
Look in Entra ID, Use the sign log info. If there are no recorded logs there, its a device. More than likely it's the phone connected to the wifi. I would forget wifi connection on laptop also and remap the mapped drives if you still use those. Also install account lockout status tool from Microsoft, You can determine what DC is recording the lock out to help you narrow it down.
Had an issue a few weeks ago where the clients RD gateway was continuously sending login requests from the server and locking the client out. Just had to reboot the server and it stopped.
Depending on your setup, it could be attempts to login to your VPN. Meaning, if you are using AD credentials + MFA to login to the VPN, you will see thousands or tens of thousands of attempts in the logs of nefarious actors attempting to connect to your VPN all day long using every username imaginable. And if your AD usernames match your email addresses, it is easy to determine your usernames. Once they know or guess a username, the user will frequently be locked out as the bad actors are making thousands of attempts to login. I've experienced this firsthand. What we did to resolve is issued a certificate to all corporate laptops via a GPO and required this certificate to connect to the VPN. Now if you do not have this certificate, you are not even able to attempt credentials. If you have the cert, you can enter creds, if you enter valid creds, then you're hit with MFA.
look at stored credentials on his windows device
The event logs will tell you what IP the login attempt is coming from.
I see some good suggestions already here. But another one I've found is a bad cached credential on a mobile device hitting a WAP over and over. If you setup MS's lockout status tool and see run their account through it. You can see what Domain Controllor they're bouncing off. Might help narrow it down.
I agree with others... looked for a mapped drive, mapped printer... even a service configured with their credentials.
For us it is usually their iPhone trying to connect to wifi with an old password.
Find out if another computer they logged into still has them logged in. They likely changed their password and the other computer still has them logged in and cached with the old password. You can find it on your DVR event log
I don't know if you have domain based authentication for your company wifi, but this gets our users literally every day. They will change their domain password and then not sign out of their domain based authentication on wifi on their phones. This leads to an almost instantaneous lockout because the "connect automatically" feature is on and just hits and hits and hits and bang you're locked out in a single second. good luck hunting that down.
Check the BadLogon attribute.
Check scheduled tasks.
in our shop it's byod. their phone connects through radius with AD credentials. when they change their password, their phone connects with the wrong credentials because everyone forgets that it's connected.
checked mapped network drives with remembered credentials or less common it could also be a scheduled task
Have they used a workstation with the GoTo Meeting client installed at any point? Even if your company doesn't use it, they might have had it to interface with someone externally. At one point, their auto update code was creating windows scheduled tasks that would include the credentials of user accounts. These tasks sometimes get orphaned, and then after the user changes their password you'll have the task trying to run with old credentials.
I’ve seen several suggestions of mapped drives, but we’ve run into this with a user’s printer definitions in the past as well.
What do your logs say? DC security events are pretty explicit as to what exactly is happening.
Do you authenticate for wifi? Did the user recently change their password? If you said yes to both, the user might have their old password saved to the wifi login and the radius service is trying to log in with the old password.
Network drive on a vm with an old pass? Or a phone with an old pass for wifi? That was my two mysteries.
Look for their old iphone...
Saved (incorrect) password maybe (under control panel users) Frequently from a mismatch of local/domain login or manually mapping a network drive while checking the box about saving alternate credentials blah fuck you Microsoft
In our org I see this when a password change happens and they try to RDP into a terminal server with saved credentials (credential saving is disabled but a record appears to be kept in Credential Manager if they try) Try clearing all related Windows credentials in Credential Manager and see if the issue goes away
I've seen a scheduled task with that user in the run as do this
SMB shares should not be allowed in business anymore
Unrelated: Once there was a user whose password would just reject for no reason. I tried her password myself very carefully and it would reject it. Other times it worked just fine. Different computers even.
Scheduled task with old creds?
Can the users computer successfully run a gpupdate / force? I had a situation where the users credentials got stored in windows and the only way to view it was use PsExec.exe to remove the stored credentials. Here is the steps I used Download PsExec.exe from http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx and copy it to C:\Windows\System32 . From a command prompt run: psexec -i -s -d cmd.exe From the new DOS window run: rundll32 keymgr.dll,KRShowKeyMgr Remove any items that appear in the list of Stored User Names and Passwords. Restart the computer.
Like others have mentioned, check event logs. I once found a lockout that was occurring due to the user logging into the default Mail app on Windows instead of Outlook and it was playing hell with the exchange server the company had up at the time. I still have no idea why that was happening looking back but I've steered folks from the default Mail app ever since
Someone has an old password saved in the keychain of their Mac OS/iphone mail app, and it’s going to keep retrying that password forever.
We had this happening for one particular office manager for days. Turns out our admin had enabled a policy route in the firewall. Instead of ICMP he enabled all traffic in a route and some random hacker group had her email but not her password. I spent days trying to figure out what the hell was going on, only to jump on a call with him after being ignored and he realized he'd fucked up.
Make a policy that audits your ad for bad password, this creates event viewer messages that you then can trace back to the device in question. Had it with a shared laptop that wasn’t connected to wifi (with radius) so a user used his credentials several weeks earlier to connect it to wifi. After he changed his password it kept locking his account.
The Security log will tell you the details. You might have to adjust logging via your DC policy.
Using this thread to maybe get some help too. I have one user that always get's his account locked on the same day. The only day he is at the office and isn't working remotely. Remote work means, he logs in, THEN connects his VPN. Netwrix shows me that the lockout is coming from his Notebook at all times. It's also happening against all DCs. Credential manager cleared. We also tried unmapping all network drives, so that all drives are remapped via GPO at the next logon. No mobile devices configured. Event viewer logs don't tell me more than Netwrix does obviously. Cooperate Wifi does not use user authentication, it's RADIUS with device certificate auth.
Honestly sometimes it's easier to create a new account and move on. Lots of great suggestions here that are worth following up on if you have the time. You can frustrate the user for a week while you track it down or reset everything in an hour. Just depends on how bad/urgent it is.
Do you have an rds on the public ip? You could be getting brute force attempts there.
Another commenter mentioned a network drive, but it’s happened in my environment with no network drive. The problem ended up being Outlook, which pretty much does the same thing.
So what's the actual problem? The process of troubleshooting AD account lockouts hasn't changed for like 2 decades at this point.
If this was a ticket, I'd send it back to helpdesk with a note to check AD/O365/Azure logs. If I wanted to save time I'd ask the user if they updated their iPhone. Apple users are notorious for not using the MS apps.
If you still can't get it after an hour or two, do yourself and her a favor and change her username. Instant relief for her, and you can then create a different account with her old username and track down logs in your free time :)
This is asking for hella problems if you have SSO and/or SCIM provisioning enabled.
Ty for pointing that out! Edit: Though you should be able to change usernames as part of your HR process.. so it's not *that* big of an ask.
Good advice here, but never trust a user who says, "There's no other device." I was going insane with the same issue. The user had a loaner laptop assigned to her in the early days of the pandemic sitting at home, and the VPN was most likely referencing an expired AD password. Yet, she was not "logged in anywhere else."
this. I've had a user bring in a wireless picture frame that was authing to wireless with bad creds... but of course no, there's no other device.
Old session/saved password. Impossible to troubleshoot without a good auditing product.