I’m looking for a good way to help a team pinpoint why a particular account locks out and be able to present this on a dashboard. Now I don’t want to have thousands of “failed username or password” hits in the sec log cause an alert every single time in SCOM so curious what people are doing. For example, event id 4625 is triggered for any of these of configured for the DCs. Before I dive deep into this I was hoping someone had a solution already made.
we’re using the ACS component of SCOM to get locked AD user information. Best for this question is default report named 'Access_Violation _-_Account_Locked:
ok cool thanks all. The ACS solution looks good. I currently have a rule in SCOM to alert when an account is unlocked and locked. I was just hoping to narrow down causes without having to alert on all username or password attempts which as you have said is a lot. So if I use ACS to collect the data does SCOM fire an alert for all events? I’m trying to visualize how I’d use this in Squared Up without having to rely on the reports. Can you have Squared Up/SCOM look at this data based on criteria so when you are investigating why someone was locked you can just edit the criteria of an alert tile?
I am going to recommend another tool that is relatively cheap but well worth the money. AD Audit by Manage Engine it is fantastic for alerting on AD changes and looking to see who did what. Their account lock out analyzer is the best thing I have found. AD is one of my duties and I love this tool has saved my butt several times.
ACS can be a bit of a beast in SQL and disk requirements. I normally just create a Windows Event Log monitor applied only to the domain controllers which looks for Event IDs 4740 or 644. I set these to a timer reset after 1 minute so they don’t fill up the Active Alerts, but can be found easily.
This will give you alerts with descriptions like this:
Interesting. I had no idea you could do a time reset. Where is that? I don’t mind the alerts now that I’m testing this but just don’t want to have to manually close 6000 or so over the course of a week
We gave up on trying to display that information. We have around 30.000 active accounts (25.000 students) in the AD. And the amount of wrong passwords generated in our environment is a lot. So accounts get locked out every second. So showing that on a dashboard was of no use for us. We store the info our elk server instead and when someone is wondering which device is locking my account we take a look there.
If it does, it would just be a case of disabling the monitor (ACS uses rules to collect events IIRC), preventing alerting. Then you can just schedule that report to go to your service desk/AD team to investigate/resolve
The disadvantage of a monitor (over a rule) is that you will miss any resets that happen within the minute reset period. And if this happens a lot; you have the potential for a lot of state changes. And do you want your domain controllers going unhealthy when an account is locked out?
SCOM can be used for this but do you really want performance and availability data mixed up with security data? I’d consider handing this off to security and they should have their own tools for this (ELK, Splunk).