This weekly blog post will be about the idea and wish I have a long time now: I want to see what a SCOM operator is doing with SCOM. So an Audit trail of the SCOM SDK idea was born.
The Idea:
Its very simple , as a SCOM administrator you have the world for your self. You can create rules , modify overrides , import / delete Management Packs , add users as you wish. If something went wrong they can blame you for it. That’s no problem because you are the the only one that know how to fix this. But what when you are not the only one with administrator privileges. Who is blaming who ? And if blaming isn’t the issue how do I know What , Who and When something has changed (the 3 audit W’s) ?
Solution(s):
On the web there are plenty of solutions that try to solve this. Most of them are using SQL triggers to catch the functions the operator is doing and a separate DB to store the generated audit records. This solutions have a very big impact on the SQL engine and I think by applying the triggers to the tables you lose your Microsoft Support Warranty. And what will happen by applying a SCOM service pack …. So this is not the way to go.
I was thinking , since SCOM uses ADAM/AD LDS for user&operations authorization why not just go this way. Every call to the SCOM SDK (the native scom console, web console,power shell , connectors,ect…) will be checked for authorization . This is done by the Active Directory Lightweight Directory Service (AD LDS), formerly known as Active Directory Application Mode (ADAM). And the nice part of this is that there is a tool that lets you read and edit this authorization store. The tool is called “Authorization Manager”. You can find it as a MMC Snapin. I will show you this later on. For SCOM the authorization catalog can be located on disk as XML file or as a SQL tables. Not going into the details , SCOM 2007 SDK uses a file store and (yes) SCOM 2012 SDK uses a SQL table store. And now the reason we dig into this all: The Authorization layer has a AUDIT trail build in !!!. Simply enable it and setup the correct audit policy and we are getting audit records…
That’s however in theory ….
The real world
Of course I have tried it out before I wrote this post. And yes we are getting audit events and yes it are events for every SDK operation and NO they do not contain parameter information. (95%not) So we can see what operation is executed but can’t see the parameters supplied with the call. For example add user X to role Y. We see the add user role operation but don’t see X and Y in the audit event. Does this make my ideas useless ? I think not. I found out that there are still some events useable. And hopefully I can get the SCOM product team so far implementing the missing parameter logging.
Some LAB testing
I will now show you how to get the audit events.
Login to the OM2012 MNG server. Open the MMC console. And add the “Authorization Manager” snapin.
The first time you will see this below:
Now we are going to make the connection to the OM SDK Authorization Store. Remember for OM2012 this in SQL. Right click and choose “Open Authorization Store..”
Now choose Microsoft SQL. And type in the Store name. I say it very easy but believe me this one cost me hours to find out (maybe because my IQ ;–) ). There is almost no documentation on Authorization manager and SQL connection. And for sure no information where the SCOM store is located. But never mind that’s your luck , because I share it with you guys.
The connection string format I got from http://technet.microsoft.com/en-us/library/cc770467(v=ws.10).aspx and looks like:
mssql://Driver={SQL Server};Server={SCOMSQLSERVER\INSTANCE};/OperationsManager/AzmanStore
Replace SCOMSQLSERVER\INSTANCE to the SQL server and Instance where your SCOM database is on.
Replace OperationsManager with the database name you have used for the operations manager database name while installing SCOM 2012.
For my LAB it will be :
Press OK and you are ready.
You will see the store and all it groups. Browse to AzmanStore\Microsoft System Center\Role Definitions and you will see the screen shot below. And I am sure you know it from the operations manager console!
Now press right button and select properties –> Definition. And you will see all the SDK operations (tasks) a SCOM administrator role can do. So every time the SDK receives a operations from for example the native console it will first check if this operation may be executed by this user. You can even add or change some operations. So you can add for example Rule__Get to a normal operator so the operator can now see the rule properties. REMEMBER IF YOU DO YOU MAY LOOSE YOUR MICROSOFT SUPPORT.
If you are curios what all the operations availably in SCOM are, Go to the Add… and press Operations. Now you will see the complete list of operations. And this one is huge..
So explained all of this you may forget it quickly now. They only thing we have to do is set the auditing flag on the store. Right click on the azmanstore and choose properties.
Now go to Auditing and enable the 2 auditing boxes.
I just wanted to show you all of this because it is fun core level stuff. But as it seems this 2 boxes are enabled by default. So the next time you can skip this part too. Sorry if I wasted your time
The only real step we have to do is enabling the security auditing policy. So lets do that. First this. The audit records are written to the server eventlog where the SQL server instance is installed. So if you have a 2 box scom installation , one OM , one SQL. You must login to the SQL server to proceed. If you have a 1box scom installation you login to the OM server.
Open the Local Security Policy editor. And enable “Audit object access” for Success and Failure. Press OK and the events will flow in.
REMEMBER HOWEVER THIS IS TOTALLY SUPPORTED BY MICROSOFT IT WILL GENERATE A HUGE NUMBER OF EVENTS AND MAY HIT THE PERFORMANCE OF YOUR SERVER.
So lets look at the events. Open the windows event viewer and go to the security logs. This will show a huge number of events. Better is to create a custom view by only selecting events with Source MOMSDK Service Security or Task Category (3).
Now if you look at a event you will notice that it has some basic information about the operation and the user plus session it belongs too. The part that is missing for a lot of operations are the parameters belonging to the operation (Data access method) if this was supplied we where done. However I found some operations that give the missing parameter information. For example when you create a new MP you will see this event. Look at the extra info given.
Same for the MP delete
I haven’t looked at all the operations but as far I can see now there are not a lot of operations with extended information. Again I hope it will be added soon with a service pack release.
Conclusion:
With the solution described we can see What is done and Who has done it and When its done. The only part missing is some extra information on the What part. So we can really see what this operator is trying to do. But better than having nothing it’s a good start.
To be continued:
I am trying to convince the OM product team to look at this. Meanwhile I have a other idea I will try to work out to solve this. I will try to post it soon.
Hope you had a good time and again…
HAPPY SCOMMING!
Michel
Tags: Auditing, Authoring, SCOM, scom2012, SDK
. But however I am running Windows 8. Okay .. could this be the case ?… After a while of figuring out what could be the problem we detected that on other NOC computers the problem was also reproduced. And yes now we had found the problem .. And what do you think ? If you have a target state view (for example the windows computer view) and you personalize this view and remove the State column you will facing the problem above. So we added the State Column again and the problem was fixed.
Touching SCOM 