One of the demos that I do in my lab uses an Opalis workflow that is triggered by a SCOM rule watching the security event log on my domain controller for any changes to the domain admins group. Once the alert gets triggered in SCOM, Opalis picks it up, disables the offending account, removes it from the domain admins group, populates the ‘notes’ field with some text indicating why the account is disabled, closes the alert in SCOM and sends an Exchange email to the administrator.
This blog post describes how to configure the SCOM piece. If you want to know how to configure the Opalis piece – I created a separate post HERE.
I’ve been asked a number of times how I did this in SCOM. Here you go. It’s pretty simple.
The first thing you’ll have to do – if you haven’t done this already – is to enable auditing on your DC’s. This is done via GPO. I won’t cover the details of that here – but this KB will walk you through the process. Basically, auditing of directory services objects (add/moves/changes) is not enabled by default - you have to do that manually and it's a prerequisite to making this process work properly.
Alright, enough of that...let's head over to the SCOM Admin Console...
Authoring –> Management Pack Objects –> Rules –> Create a New Rule
Essentially what we’re doing here is creating an alert that gets triggered by a specific event id in the DC’s security log. In our case, it’s 4728 for Server 2008 R2 domain controllers. If your DC’s are not 2008 R2, the event id is different – you’ll have to look it up.
Here are the steps. Make sure you create a custom management pack – don’t stick this in the default…it’s not good practice.
Make sure that you select a DC in the ‘target computer’ field:
Data Source is where we configure the event id and parameters – Response is where we configure the description field of the actual event and any other customizations (in our case populating a custom field):
Click the “…” to configure “Parameter 3” – for the values, you’ll just type those in:
By the way – here’s what the actual event log looks like:
You do have options here – what priority level and severity (affects how it alerts in SCOM) and then what you want the alert description to look like. You can also make changes to the Alert Name which is what you’ll see top line in the ‘alert view’ in SCOM:
In the Custom Fields section, I used #2 and populated that with the text DAACCESS.
I populate CustomField1 with the domain\username information (I use that in the Opalis workflow)
The reason I did this is because that’s how I’m telling Opalis what to look for when an event pops in SCOM. Now, every time this rule gets triggered and this alert pops in SCOM, Opalis will pick it up and start our workflow.
Good stuff! Hope this was helpful!