Creating rules to monitor Security Logs with SCOM 2012 (SP1)

The requirement

Monitor certain Security events, like account locked, account unlocked, etc in the security event log of the Domain controllers. Generate an Alert when any of the events happened and be able to generate a report on the occurrences.

The Challenges

• Event IDs – which ones are the ones we are looking for
• Rules – Create rules for all events and show appropriate information in the description
• Reports – Show Summarized views of the events

Challenges Accepted!

Event IDs

    Well, that part was not that hard. Having gurus like Kevin Holman really makes life easier. You can find a very good list of the events here:
http://blogs.technet.com/b/kevinholman/archive/2011/08/05/a-list-of-all-possible-security-events-in-the-windows-security-event-log.aspx
    I decided to start with:
Note that 2003, 2008 and 2008 R2 will have different IDs for the same event, so, double the work…
Now, with that, I think I can start creating the rules.

Rules
    To simplify things, I’m using the 2007 authoring console. I’ve created a new Empty Management pack and called it Security (ok, not very creative…but it is what it is!). No fancy targets here, since I want to target all domain controllers. Makes it easy to start. Let’s start with the Alert rule:




Repeat the process for the 4767 event: A User account was unlocked
Now, the rules above will generate alerts, but won’t store any data in the databases. For the Event collection rules, let’s proceed as follows:
Create a second Event-Collection rule for the Account unlocked event (4767).

You should have something similar in the end:
Import the rules in to the SCOM server. I kept this one unsealed for now, but sealing and versioning is the right way to go:
When you do it the first time, it should be green. It is showing the blue ! because I already have it there.

Now, let’s test the rules. In order to test it, I have used an existing user, called bubblehead. I tried logging in with the wrong password until the account got locked out. To be 100% sure it worked, I looked for the events on the security log of the DC:
Meanwhile, in the SCOM Console…
Ok, now, how do I know whether the events are being collected. Fear not, here it goes:
In the My Workspace area:




There they are!
The last step is reporting. Prepare to enter the magic land of report builder. It is going to be Legen…


Reporting on the Events

The basic Event Analysis template reports don’t seem to fit my summary needs. I have tried both and couldn’t get the results I wanted.
I wanted something like a simple table, with the Event ID, what kind of event that was and how many times it happened. Selecting the time range will be needed as well.
So, here we go.

You have the option to fire reporting services from the Reporting section in the SCOM Console:
However, this usually brings up an older version of Report Builder (it did for me, at least). So, if you want to go with the latest (and maybe greatest) version of SSRB, open the Reporting Services URL from any machine, as below, and click in Report Builder:
http://<SSRS_Server>/Reports
It will install the client locally and you’re ready to go…Not! First you need to make sure you have the Event.smdl model installed. Follow the instructions here:
http://technet.microsoft.com/en-us/library/ee292069.aspx
After that, we will need to create a dataset to work on the new report. You could start a new dataset from inside the report, but I like to see the dataset there and it could be shared with other reports. And it is my blog, so…:
If you don’t see the Event.SMDL there, use the Browse other data sources option:
Note: You can create new fields right in the dataset configuration, if you want them available for other reports. In this case, I will leave it and create one inside the report itself.

To create the report, save the dataset (as Events_Dataset) and follow the steps below:




If you run the report now, you will see all events in the database. We don’t want that. Let’s filter to what is important:

You can restrict as much as you want.
You should see something like this now when you run the report:

Let’s add a little bit more of information. Let’s create a calculated field, so we can find out what those events are. Back in the design view, add a calculated field:




Click the fx and add the formula:

=Switch(Fields!Event_Display_Number.Value="4767","A user account was unlocked.", "4740", "A user account was locked out.")
Yes, I know. Isn't it in the database somewhere. Very likely. It doesn't seem to be in the Event dataset that is provided, so, let's stick with it for now.

Now drag the new field to your table:


Note: Make sure you add it to the left, otherwise it will try to create a sum for it.

You should see something like that:

Now, the cherry on top. Let’s select the data range. First you need to add parameters to your report:


I have added a start date, with a default value of Yesterday (today-1 day):

Also added and End Date, with “Now()” as default value:

Now let’s add this to the criteria:



And Voila:
Now save your report in a folder in the Reporting Server:
If you look at your SCOM Console, in the folder you saved the report:



There you go!

…dary!!!!

So, if you came all this way, I hope you have enjoyed and that you can expand it, filter it, create new reports with it,etc.
Reporting with SCOM can be painful in the beginning, but with time, you may even start to like it.
True story.

Jose Fehse