How do you all monitor account lockouts in SCOM and causes?

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.

Thanks,

Gary

1 Like

Hi Gary,

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:

Let me know if it could help or if you need further information :slight_smile:

2 Likes

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?

1 Like

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.

1 Like

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:

 

A user account was locked out.

Subject:
Security ID: NT AUTHORITY\SYSTEM
Account Name: UserAccount$
Account Domain: DOMNAME
Logon ID: 0x3e7

Account That Was Locked Out:
Security ID: DOMNAME\UserAccount
Account Name: UserAccount

Additional Information:
Caller Computer Name: SOURCECOMP

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 :slight_smile:

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).