Menu Close

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”?  Smile



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:


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:”

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:


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:

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.



  1. Tony Strother

    Great info as always, thanks. And as always, a follow up question. I started seeing, this morning, that I could not reset the heath of “any” monitors. After much investigating, question asking, it turns out that one of my scom admins deleted the “builtin\administrators group” from our SCOM QC and Prod tiers. We have an admin-scom group that was also in the Operations Manager Administrators group. The admin-scom group contans the scom admins admin-account as well as the SCOM accounts created at install. Since this does not seem to be sufficient to reset the monitors, is there something else I can look at? That is the only change that was made while I was out for a few days, that I have been able to discover so far. thanks, Tony

  2. anish

    Members of group for Operator role are not able to see maintenance schedule created by other members. Is there any option available to get this visible by operators?

  3. SCOM Europe

    What if customer asks to restrict Management servers from remotely executing scripts and commands on SCOM agents due to security reasons. How can we handle this scenario?

    • Kevin Holman

      Easily. Management servers have ZERO rights to execute anything remotely on agents.

      Only through delivery of management packs, scripts and commands are executed locally. Control the access to the SCOM application through role based access control, and you control what runs on agents, locally.

      • Ken Rappold

        I realize this is an old thread. My apologies.
        To tag along with SCOM Europe’s comment, we are implementing Windows Defender Application Control and having challenges. We are able to whitelist the folder(s) used by SCOM MPs, but the script calls an API and WDAC blocks that call.
        Example of Event 21413: The Event Policy for the process started at 7:01:00 AM has detected errors in the output. The ‘StdErr’ policy expression:
        matched the following output:
        C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Monitoring Host Temporary Files 3\968\AutomaticServiceRecovery.vbs(19, 3) Microsoft VBScript runtime error: ActiveX component can’t create object: ‘MOM.ScriptAPI’
        Command executed: “C:\WINDOWS\system32\cscript.exe” /nologo “AutomaticServiceRecovery.vbs” IsmServ
        Working Directory: C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Monitoring Host Temporary Files 3\968\

        One or more workflows were affected by this
        Workflow name: Windows.AutomaticService.Monitoring.Rule

        We have engaged MSFT Global Business Support but find that the resources for WDAC are lacking in knowledge and expertise thus far.

        I have not gotten good hits when doing a search and thought I’d post here for any feedback.

  4. SrN

    Hi Kevin,

    We are running SCOM 2012 R2 and our SQL team has asked if we can disable interactive-logons for SQL service accounts used by SCOM 2012 R2. Like SQL Database reader, writer account etc….

    Is it safe to disable interactive-logons for SCOM SQL service accounts?


Leave a Reply

Your email address will not be published.