Security in Operations Manager – some perspectives and typical customer scenarios

The concept of this article is to give you a general overview of the security model, and rights required, to deploy and operate System Center Operations Manager.  For each section, I will link to more detailed documents and articles.

 

What do I need to know?

 

When I have a discussion with customers around security, it is always different due to different customer environments and policy requirements.  Here are the discussions topic areas:

Considering the Enterprise Monitoring team, do they:

• Own full rights to their SQL servers, or is SQL managed and secured by a different team?
• Have local admin rights on all monitored servers in the environment, or no rights?
• Have an account domain admins privileges?
• Have the ability to create service accounts in the domain?  Containers?
• What is the password policy for service accounts?
• How many people on the team will be OpsMgr admins?
• Do they want to restrict OpsMgr Operators to only see specific servers, by group, or application?
• Do they want to help elevate Operators to have access to run specific tasks, or restrict them from others?
• Do we need to use a special account to configure notification access to their SMTP server?
• Do we need to monitor applications that have their own security access list, and are fairly restricted?  (SQL, Active Directory, SharePoint, etc)
• Do they even HAVE an “enterprise monitoring team”?  

 

 

Can you break it down into simpler terms for me?

First off – there is good documentation available on OpsMgr security requirements, in our Security Guide, Design Guide, and Deployment guide:

http://technet.microsoft.com/en-us/systemcenter/om/bb498235.aspx

 

I like to break down a security conversation on OpsMgr around the following topics:

• Accounts and groups needed before installing the infrastructure
• Rights needed to install, deploy, and update the infrastructure
• Rights needed to deploy agents
• Rights required for specific roles and applications (Run As accounts)
• Rights and configurations for scoping consoles for operators

 

 

Accounts and groups needed before installing the infrastructure

This can really be as simple or as complex as your environment requires it to be.  At a minimum, I like to recommend the following:

• DOMAIN\OMAdmins            OM Administrators security group
• DOMAIN\OMAA                      OM Server action account
• DOMAIN\OMDAS                    OM Config and Data Access service account

The domain group is really necessary to clearly define who has admin access to OpsMgr, and will be granted local admin access to the infrastructure (SCOM) servers.

The OM Server action account needs no special rights in Active directory, it is just a domain user account that will be used to run processes on the management servers.

The OM Config/DAS/SDK account is uses to run processes on the management server, and have access to the OpsMgr database.

 

Additionally, you might consider the following accounts, which will be needed for specific scenarios:

• DOMAIN\OMWRITE            OM Reporting Write account
• DOMAIN\OMREAD              OM Reporting Read account
• DOMAIN\SQLSVC                 SQL 2008 service account
• DOMAIN\NOTIFY                  A domain account with rights to send mail to the STMP server

The OM Write and Read accounts are used for reporting – controlling access to the data warehouse database and used for report execution, deployment, and other tasks.  Many times customers consider just leveraging the above DAS/SDK account for both of these roles when installing reporting, if maintaining multiple service accounts is more painful for your organization.

The SQL Service account is typical when installing SQL server and running the SQL DB and Agent service under a domain account.  Normally this would be handled and controlled by a dedicated SQL team.  If the OM team owns their own SQL servers, then this should be part of the planning process.

The Notification account is only needed if you have a secured SMTP relay server in your environment.  By default the OpsMgr server will send notifications using the Management Server Action Account (OMAA).  If this account does not have rights to send mail – then you have to come up with a relay solution, such as granting those rights to the OM server action account, or using a specific notification RunAs account for this, or configuring relay access via some other means.

 

 

Rights needed to install, deploy, and update the infrastructure

 

For the initial deployment, I like to recommend that a SCOM admin’s domain account be placed into the DOMAIN\OMAdmins group.  Then – assign this group to have the following rights:

• Local Administrative rights to the OS on each infrastructure servers (Management Servers, Gateways, and SQL servers)
• Systems Administrator role rights to all SQL servers which will be hosting the Operations or Warehouse database.

That’s it.

Generally, configuring each OpsMgr management server or Gateway is no issue.  However, getting local admin access or SA role rights to the SQL servers OS, and SQL specific access list, can be challenging.  There are no real workarounds to this in OpsMgr 2007 R2.  These rights are required for the OpsMgr setup routine to create and set permissions for these databases.  Sometimes you will see a SQL team pushing back on this requirement, because they do not normally grant local admin or SA role to ANY application owner.  However, these are required so you will need to work that out internally.  What I recommend is to grant the specific OM Admin’s domain user account to have these rights *temporarily* during the installation, and then remove those rights completely once install is complete.  Setup will automatically grant the required rights to each service account supplied – so the individual account that performed the installation is no longer required to have this high level of access.  This is also why I do not recommend performing installations of software using a service account.  If you remove or downgrade the rights to a service account in SQL – you might break something.  It is best to just let setup handle those required rights, and add/remove nothing to them.

 

Rights needed to deploy agents

Agents get deployed in one of three typical ways:

• Push installed from the console
• Deployed via software distribution, like using Configuration Manager
• Pre-installed in an image, using AD integration.
• Manually installed, by a local administrator running the agent MSI.

In other to Push-install agents from the console across the network to the monitored server, very specific requirements exist.  I discuss these requirements in detail here:”

https://kevinholman.com/2007/12/12/agent-discovery-and-push-troubleshooting-in-scom-2007/

One of the main items – is that in order to install software on a remote machine, the SCOM admin must have Local Admin rights on that remote OS, *OR* have access to leverage an account that does have these rights.  You will see in the below screenshot – when performing the initial discovery, we can use the Management Server Action Account (provided it has local admin rights on all managed servers) or type in an account credential that has local admins rights:

 

Most accounts I work with will type in a credential here, such as their personal administrative account, in order to push the agent out.  The alternative – is to configure the OpsMgr Management Server Action Account to have local admin rights on all monitored servers.

One distinction here, is Domain Controllers.  Most of the time – OpsMgr Administrators do not have Domain Admin rights to AD.  This also means they will not have any local admin rights to your Domain Controllers.  So pushing the agent to any Domain Controllers can be a challenge.  I discuss that in deeper detail here:

https://kevinholman.com/2009/02/20/getting-and-keeping-the-scom-agent-on-a-domain-controller-how-do-you-do-it/

 

Rights required for specific roles and applications (Run As accounts)

When an agent starts up – it needs to run as a given credential.  Whatever account the agent processes run under, needs to have the ability to gain access to most data sources on the monitored system, like the Event Log, Perfmon, WMI, ability to run scripts, read log files, etc.  The account that the agent runs these default processes under is called the “Default Agent Action Account”.  In most cases, I stress to my customers to run the agent as “Local System” which also happens to be the default configuration when you deploy an Agent.  Local System is a good, secure, low-maintenance strategy, that will give your agent the access it needs to monitor the system.

Sometimes, you will run across scenarios where Local System does NOT have enough rights to access specific objects or applications.  For instance, this is common when monitoring Microsoft SQL Server.  SQL Server maintains its own security access list to the SQL instance and databases, and does not directly leverage the local administrative group membership.  It is possible (and sometimes common) to see SQL administrators limiting the access rights of “Local System” from having any access, or enough access, to SQL.  In these cases, the agent and management pack cannot do its job.  Luckily, these scenarios are almost always fully covered in the management pack guide for applications where this might be common.  I give a much deeper dive into this concept, using the SQL server scenario here:

https://kevinholman.com/2010/09/08/configuring-run-as-accounts-and-profiles-in-opsmgr-a-sql-management-pack-example/

There are many examples of this for specific applications, and workflows, such as Active Directory MP, SQL, SharePoint, etc.

 

Rights and configurations for scoping consoles for operators

Once you have OpsMgr up and running – one of the things you will want to do for your users, is to scope the console for them based on what they need to see, or have access to.  This is a good thing, because it will let them focus on the applications, or servers that they care about, without seeing the massive amounts of issues across the environment.  We integrate with Active Directory here, so you can reuse existing Global Groups for scoping a SQL team to only see SQL computers and alerts.  Here is an example, where I create a scoped Operator User Role called “SQL Admins”, and use the AD global group for the existing SQL team:

 

Once I create this – I can scope to the Groups, Tasks, and Views that I want to deliver to my teams:

 

 

This results in a very different experience for my SQL team – where they only see computers, SQL instances, databases, and alerts from SQL:

 

Another item for a security discussion – is Tasks.  Tasks allow you to elevate an operators rights in OpsMgr.  For instance, you can have a first level helpdesk person watching the console or receiving the first line notifications of an issue…. the SQL Agent Service is stopped on a server.  With tasks – you can allow that operational team to be able to run a command in the OpsMgr console – from the actual alert that was generated – to restart the service.  But what if that Operator has NO local admins rights to the monitored server?  No problem – with tasks, they can be created to run under the default action account, or pre-defined run-as account, which DOES have rights to start the service.

 

 

Alternatively – if this task requires rights above and beyond what the run-as account or default agent action account have rights to – you can allow the admin/operator to type in one-time use credentials to execute the task under.  So we cover both scenarios.

In this way – you should take care of what tasks to allow operators to be able to run – the default behavior is possible elevation of their privileges… to be able to execute a task running under a pre-defined credential such as local system, or a SQL run-As account.