Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Over the years I have written many articles dealing with RunAs accounts. Specifically, the most common need is for monitoring with the SQL MP. I have explained the issues and configurations in detail here: Configuring Run As Accounts and Profiles in OpsMgr – A SQL Management Pack Example
Later, I wrote an automation solution to script the biggest pain point of RunAs accounts: distributing them, here: Automating Run As Account Distribution – Finally! Then – took it a step further, and built this automation into a management pack here: Update- Automating Run As Account distribution dynamically
Now – I want to show a different approach to configuring monitoring for the SQL MP, which might make life a lot simpler for SCOM admins, and SQL teams.
What if I told you – there was a way to not have to mess with RunAs accounts and the SQL MP at all? No creating the accounts, no distributing them, no associating them with the profiles – none of that? Interested? Then read on.
The big challenge in SQL monitoring is that the SCOM agent runs as LocalSystem for the default agent action account. However, LocalSystem does not have full rights to SQL server, and should not ever be granted the SysAdmin role in SQL. This is because the LocalSystem account is quite easy to impersonate to anyone who already has admin rights to the OS.
We can solve this challenge, by introducing Service SID’s. SQL already uses Service Security Identifiers (SID’s) to grant access for the service running SQL server, to the SQL instance. You can read more about that here: https://support.microsoft.com/en-us/kb/2620201
We can do the same thing for the SCOM Healthservice. This idea was brought to me by a fellow MS consultant – Ralph Kyttle. He pointed out, this is exactly how OMS works to gather data about SQL server. We have an article describing this recommended configuration here: https://support.microsoft.com/en-us/kb/2667175
Essentially – this can be accomplished in two steps:
- Enable the HealthService to be able to use a service SID.
- Create a login for the HealthService SID to be able to access SQL server.
That’s it!
This creates a login in SQL, and allows the SCOM agent to be able to monitor SQL server, without having to maintain another credential, deal with password changes, and removes the security concern of a compromised RunAs account being able to access every SQL server in the company! No more configuration, no more credential distribution.
I even wrote a Management Pack to make setting this initial configuration up much simpler. Let me demonstrate:
First, we need to ensure that all SCOM agents, where SQL is discovered – have the service SID enabled. I wrote a monitor to detect when this is not configured, and targeted the SQL SEED classes:
Image may be NSFW.
Clik here to view.
This monitor will show a warning state when the Service SID is not configured, and will generate a warning alert:
Image may be NSFW.
Clik here to view.
The monitor has a script recovery action, which is disabled by default. You can enable this and it will automatically configure this as soon as SQL is detected, and will restart the agent.
Image may be NSFW.
Clik here to view.
Alternatively – I wrote two tasks you can run – the second one configures the service SID, but will wait for the next reboot (or service restart) before this actually becomes active. The first task configures the service AND then restarts the agent Healthservice:
Image may be NSFW.
Clik here to view.
Here is what it looks like in action:
Image may be NSFW.
Clik here to view.
So – once that is complete – we can create the login for SQL.
If you switch to the SQL instances view, or a Database Engine view – you will see a new task show up which will create a SQL login for the HealthService.
Image may be NSFW.
Clik here to view.
If you run this task, and don’t have rights to the SQL server – you will get this:
Image may be NSFW.
Clik here to view.
Have your SQL team run the task and provide a credential to the task that will be able to create a login and assign the necessary SysAdmin role to the service:
Image may be NSFW.
Clik here to view.
Voila!
Image may be NSFW.
Clik here to view.
What this actually does – is create this login on the SQL server and set it to SysAdmin role:
Image may be NSFW.
Clik here to view.
All of these activities are logged for audit in the Task Status view:
Image may be NSFW.
Clik here to view.
Now – as new SQL servers are added over time – the Service SID can automatically be configured using the recovery, and the SQL team will just need to add the HealthService login as part of their build configuration, or run this task one time for each new SQL server to enable it for monitoring.
I find this to be much simpler than dealing with RunAs accounts, and it appears to be a more secure solution as well. I welcome any feedback on this approach, or for my Management Pack Addendum.
I have included my SQL RunAs Addendum MP’s to be available below:
https://gallery.technet.microsoft.com/SQL-Server-RunAs-Addendum-0c183c32