I have a user that continues to get locked out. What are the best tools available to find the source of the problem? I have downloaded the Microsoft Account Lockout tools but that just confirms what DC is getting locked out, the date and time of the occurrence. I would like to find out the source IP or Device. Is there a good way to do this via Powershell?
I had the user turn off his machine and delete all Office 365 products from his phone. Its possible he may be logged on to a server somewhere with his old credentials.
As for this....
I have a user that continues to get locked out. What are the best tools available to find the source of the problem?
... this is not a PowerShell issue, this is a ADDS policy issue that PowerShell or no other scripting thingy can solve.ADDS, says, once the user so locked, out, you must unlock them. This is also a user education issue.
Anyway, Microsoft and the US government, and industry have now changed their stance on this set and account to lockout thing.
Other articles on the topic. (NO PERIODIC PASSWORD RESETS)
No more expiration without reason. This is my favorite piece of advice: If we want users to comply and choose long, hard-to-guess passwords, we shouldn’t make them change those passwords unnecessarily.
The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.
Remove periodic password change requirements This is one that legions of corporate employees, forced to create a new password every month, will surely be happy about. There have been multiple studies that have shown the requirement of frequent password changes to be counterproductive to good password security; but the industry has doggedly held on to the practice. This will remain controversial for some time, I am sure.
I've been in IT for more than 4+ decades, and I've always thought is was foolish. As it's nothing more than a self-imposed DOS attack for / from every user in your environment, and costly help desk calls and loss in productivity, etc.
For your use case, you just Schedule Task event ID monitor ADDS security logs for logon attempts a simple PS script to send you that info. Even if you do the no rest thing, this is still needed, just to be sure.
For the tool you choose, see this:
Even if you use PowerShell, you'd still have to set it as a Scheduled Task, or background job to report back to you real-time, otherwise, you just use PowerShell to get a daily report, but that still does not solve root cause of not hampering the user with the reset policy.
Just to a event log script to grab event DI 4740.
There are pre-built scripts for such reporting from the MS powershellgallery.com. Just go there and search for them. For example:
As well as many other sites that provide samples. Just search for it. For example:
Use them as they are or tweak for your needs.
Powered by IDERA