SCOM Delegated Admin 4

Being a Full SCOM Admin or not?

by

In this blog post I am writing about the rights a Delegated SCOM Admin has versus the Full SCOM Admin. It started out as a question from one of my long time customers, who are looking to use SCOM 2022 and the Delegated Admin role to narrow down the rights of daily SCOM Admins to still do what they need to do on a daily basis. The Full SCOM Admin would be handed out through a procedure with an approval.

Context

A little bit more context: While designing the SCOM roles for the people in your organization who need some type of access to SCOM data or views, we always start with having somebody in the SCOM Administrators role. This is the full SCOM Admin and can not be scoped or limited within SCOM. So, if you are a full SCOM Admin, you can do basically anything without limitations in SCOM and could potentially do stuff on high privilege machines with a SCOM agent on them. The SCOM management group is also a security boundary, whereby Admin rights are one of the things to keep into account for deciding to split into multiple management groups or not.

In SCOM 2022, we now have Read-Only Administrator, which is an Auditor type of role. You can see everything in SCOM, including all settings in all tabs. But you can not change anything.

Also in SCOM 2022, we added a Delegated Administrator set of options. This means that we can make a selection of a number of profile entries and next define a scope for it. For example, in the old days, if somebody from the server admin team needed to be able to deploy and remove agents from SCOM, that person needed Full SCOM Admin rights. Meaning there is no limitations and no scope. Mistakes can be made (on purpose or not). Now, we can create a delegated admin and select the Agent management type of profile options and add a person to that role.

If you are not aware of these new roles and want to see some details, please first look at this blogpost of mine when SCOM 2022 got released and I could write about these new items: New in SCOM 2022 – Admin RBAC | TopQore Blog

The above blog post is also where you find the pictures for this role.

Assignment

My assignment was: Try and find out that if we assign somebody All possible Delegated Admin rights and perhaps other roles within SCOM – What is the difference with a Full SCOM Admin? Can we limit a person in this role, so that he can not run a task against domain controllers for example. Being able to run a task on a higher tier server, such as a domain controller is a risk. Do we really need to create a separate SCOM management group in a tier-0 environment, just to be able to limit the few SCOM admins from running a task?

Trying

In SCOM 2022, we now also have an option to disable running of tasks for Operators using the predefined run-as account. This would be the Local System account in most cases for most agents. Of course, some actions can not be done by local system, such as adjusting AD users (although one could use SYSTEM on a domain controller to gain domain admin privileges), adjusting SharePoint farm settings and such things. But, on the other hand, Local System can stop a Windows Service from running on a critical server. The setting here which you can enable in SCOM 2022 will limit the running of a task to somebody having to put in his own credentials to run such a task. And since SCOM 2019 this also needs Login as a Service rights on such a machine, which most won’t have either. This is what we want for this customer! As stated before, a Full SCOM Admin can still run a task as Local System. This is why we are doing this exercise!

So, every time I switch between a Full SCOM Admin and a Delegated Admin role, where I keep adding rights to until I reach the maximum. Also in order to check the theory of the delegated admin and other roles against the real world to be honest. And I did find things which were kind of known somewhere, and never acted upon, and found a bug as well.

I created an account called SCOMadmin1. I added the account to the SCOM Operators role.
I can confirm I see the Monitoring pane and alerts and so on. I can see tasks. When I click a task, I can not run it with local system. Great! This is what we wanted for Operators. Now, let’s see how much stuff we can add and see if we still have this task running behaviour, while being able to do our daily SCOM Admin work.

Author and Advanced Operator

At first I added this account to also the SCOM Advanced Operator (Can create overrides and see properties of monitor/rule), and to the SCOM Authors role (can work with packs, see Authoring pane and create monitoring solutions). Also added to Reporting. So, this is the most we could give before SCOM 2022 without being an Admin.

  • The task running experience is un-changed (= good).
  • Monitoring pane access.
  • Can make overrides
  • Can work with Packs
  • Access to Authoring pane
  • Can create rules and monitors
  • Can start maintenance mode
  • Can NOT create Group ???
  • Can NOT use Management pack monitoring templates ???
  • Can NOT create Distributed Apps ???

I was a bit surprised by these last 3, because I assumed these would be part of the Author role permissions. Turns out, this was never the case since several versions of SCOM. It is just that I have never been given anything less than SCOM Admin rights anywhere to do my thing. And if a pack gets created in a tool, such as VSAE or Silect, and saved in a pack, you can still import it as Author. I am guessing this is how people worked around it in the past. Many places I go to, the SCOM Admin is also doing Authoring, so all needed rights are already there. RBAC has not been enabled to these three items in the background of SCOM, therefore these have not been added to the Delegated Admin permission sets either in the story to follow below!

Delegated Admin tests

I created next a set of Delegated Admin roles using sets of permissions, which are similar to the roles one might need to perform. I created Account Admin, Agent Admin, Connectors Admin, Notifications Admin, Global Settings Admin, MP Admin.

SCOM Delegated Admin 4

Started with adding the account to the connectors admin. What can we now do extra? By the way the account was taken out of the Author role for the following steps).

  • We can NOT run a task as local admin (= good)
  • If we are not part of Author role, we can access the Authoring pane, but can not edit anything.
  • We have access to the Administrator pane now as read-only
  • We can NOT import a management pack
  • We have access and can work with Connectors (good)
  • We can create a Resource Pool. I can imagine some connectors using these, therefore we have access to this now.
  • We can not adjust global settings
  • Other things also not working – as expected

Now, I am adding the account to the MP Admin role (and still it is in the Connector Admin role, so we are adding). The MP admin role includes MP Import, MP export, MP delete, author workflows, create overrides.

  • Can NOT run task as local system (good)
  • Can create monitors and rules and overrides
  • Can start maintenance mode
  • Can import and export and delete an MP (from Admin pane)
  • Has Read-access to SCOM Admin pane items
  • Can NOT edit global settings
  • Can NOT create a Run-As account
  • Can NOT create a Group, or Distributed app, or use Monitoring Templates in authoring pane (similar as the Author role).

Now, I am adding the account also to the Notifications Admin role items. This means we should be able to work with notification channels, subscribers and subscriptions. And whatever we had before.

  • Running task as local system still disabled.
  • MP import works (from other role assignment)
  • Can NOT create a notification channel ???
  • Can create a Subscriber, but only for himself ???
  • Can Almost create a subscription, except for where you need to select or create a subscriber (can only select himself), and can NOT create a Channel from this spot either. Thus I can not finish this one.

I sent this as feedback to the Microsoft Product Team. They are aware of this bug and will work on a solution. I spoke to them about this right before UR2 came out. I can imagine it did not make it yet. I will verify that.

At this moment I figured, let’s add the user to the Author role again and see if that helps with the items I did not expect to be blocked. That fixed nothing.

Account Admin, Agent Admin, Global Settings Admin

AT this point the user has been given every Delegated Admin right possible, plus Author and Advanced Operator, and has access to Reporting with the normal SCOM Report Operator role rights.

  • Run-As accounts work now
  • Run task as local admin still disabled
  • Can run discoveries of network devices and Windows
  • Can add users to SCOM roles (by the way, including Full Admin role and the delegated admin roles), so this user could add himself to full admin temporarily (just saying).
  • Can adjust management server settings and global settings as expected.
  • Can not create Notification Channels or subscribers (related to the bug mentioned earlier).

Other things to do in SCOM Admin pane

This customer also has Cookdown EasyTune EasyTune running, which is an item managed from the SCOM Admin pane. I have tested this product with the rights mentioned above and here is the conclusion for that one:

  • We need access to Admin pane to read the settings. The Delegated Admin roles all give access to the Admin pane. Works.
  • I went ahead and used the MP Admin and Authoring roles (both normal and Delegated Admin) and Advanced Operator at first, because this sounds like what EasyTune is doing, right? We are creating sets of overrides, and applying them, and in that process creating an MP. Later used the whole set, but the MP Admin and Authoring stuff will get us ALMOST to what we want.
  • With the MP Admin right I can now add the main EasyTune solution, because it is an MP at first.
  • I can work with the Custom Store. Placing files in the share or path requires the usual rights on the folder. Meaning I can replace the tuning files there after working with them in Excel.
  • Can export packs to CSV for creating new tuning packs.
  • I can apply global tuning. This creates a pack in the background.
  • I can apply Group tuning (also 2 groups). Same as item above.
  • Can NOT remove tuning from a group or global tuning !!! From the EasyTune console that is. It gives an access denied type of error. We CAN go into SCOM MP list and remove the tuning packs from there obviously and refresh the EasyTune screen as a workaround

Word from Cookdown engineering team about this: While EasyTune may work with some workarounds with lesser permissions, officially EasyTune was only intended to be used with the Admin role so from a support perspective we’d have to say the administrator role is required to use EasyTune.

Well, I have tested it and it does work, except for removing tuning. This can work with a workaround, while having lesser rights. But as you see above, it was intended to work with Full SCOM Admin from their support perspective.

Conclusion

We have an account. It has been made a member of every User Role in SCOM (classic style), including foremost Advanced Operator, Author, Report Operator. However NOT Full SCOM Admin of course.

Next we added the SCOM Delegated Admin rights (all of them in the end). And we applied the global setting to force Operators (and everybody else) to run tasks only with filling in credentials. So, no Local System tasks.

  • We can do all monitoring work
  • We can NOT work with Groups, monitoring templates in authoring pane, and distributed apps. All in Authoring pane. This is known at the PG, there have never been RBAC rights added to these features and therefore also no enablement of those as entries in delegated admin. There is a chance this will not change, unless a load of people jump on this.
  • We can NOT run task as Predefined action account (most often Local System). OK this was what we wanted to achieve.
  • We can not create Notification channels or subscribers or add them to the subscription when they don’t exist yet. This is a bug now known by MSFT PG and likely to be fixed. Not sure if it made it in UR2, else it will have to be UR3 (unknown date).
  • We can work with EasyTune, be it that removing tuning takes a workaround and it was never created with RBAC in mind, so officially it requires full admin. I got it to work though, and removing tuning needs workaround by using the MP Admin rights or Author rights from SCOM itself.
  • We can grant ourself or others Full SCOM Admin rights due to the Account Admin rights in Delegated admins set.
  • As a SCOM Author and MP Admin, of course we DO have the possibility to create items and scripts in a management pack, which can be made to run against all agents, and with the predefined action account. It would take more work to do so obviously. It is not as simple as clicking on a task we see and have access to running. In theory though it is possible. This would still not be able to go into every application, but it could for example do a shutdown of Windows Services if we wanted to build it that way. Keep in mind that having SYSTEM access to a domain controller gives equal to domain admin rights if one knows what they are doing. I guess the same goes for having Admin access to other big manageability tools, such as SCCM/MECM and creating a package in there to run or Orchestrator and several other tools. These are all tools which should be taken care of when doing a Tiering model in AD or creating a Management Plane (These subjects are discussed in our specialist training for Advanced Designs found here https://topqore.com/scom-specialist-training-advanced-designs/ )

And of course, if you are Full SCOM Administrator you can still do everything, have full access, AND can run tasks as Local System even if nobody else can run it like that. This is the basic difference.

If we take away normal Full SCOM Admin rights and assign somebody (The usual SCOM Admins) all other roles and delegated admin roles – they can do most of the daily work. With a number of exceptions, as you saw. Some workarounds enable access to some items (EasyTune), which could be acceptable. It would stop somebody from clicking a task and running it as local system. But in theory, again, with these rights you would have ability to create a pack which automatically runs something (theoretically), which would require more effort and knowledge of SCOM. Also adding or removing packs and objects (monitors/rules/Overrides) is audited in SCOM since SCOM 2019 UR2/3. So, that would leave an audit trail. And if User Role Admin is given out the custom Admin could add himself or somebody to the SCOM Admins role to gain full access, without using a service account or special admin account which was already part of that role, for those few times a year where those extra rights are needed.

It is up to the combination of these possibilities, with complexity added through for example creating additional management groups for different Tiers, in order to prevent too much access to higher tier servers. Or to use this solution and use fewer SCOM management groups and using SCOM Admin role less (with approvals and 4-eyes principles, and who runs a task is audited). What can we get away with in conjunction with the Security team and auditing exceptions? This is up to each organization. This opens up opportunities for sure, but there are some limitations. Sometimes this will lead to having to create an additional Management Group due to enforcing the Security Boundary. Sometimes this is enough separation.

Wishing everybody good luck in using this and NOW WE KNOW.

Bob Cornelissen