Share via

Removing Local Admin Rights from the SCOM Action Account

  • Article

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

I get asked the question periodically, and after doing some checking into this I figured it was worth writing about. I’ll start by noting that if you plan on deploying SCOM in any way, it’s worth looking at the security requirements for it. Kevin Holman posts a very nice summary here. The issue at hand is that most customers are going to follow the requirements we lay out, and those are somewhat nebulous. While we make it clear not to make the action account a domain admin, I often see that the SCOM Management Server action account is set to be a local admin on all servers, especially if time is a factor.  Ultimately, this is a bad idea.

Why?

Pass the Hash. Understand that the SCOM agent will log on with the action account on each and every server, thus loading its credentials in the LSA. What this means is that if any server is compromised, the attacker essentially has a hashed password of an account that is a local admin on all of your servers. If Wdigest is enabled (Server 2008 R2 and below default behavior) they have that same password in clear text.

Ultimately, if you are using a local admin credentials for this account, the compromise of one server in your data tier will lead to the compromise of all servers in your data tear. While your security tier (tier 0) is not yet exposed, the attacker now has the ability to help themselves to whatever data exists at tier 1.

The Basics

First off, there are two action accounts, and it is worth distinguishing between the two as this isn’t always clear. The management server action account is used to run work flows on the management server. It is also the account used during deployment of SCOM agents via the wizard when you choose to use the default action account. It must be a local administrator on all management servers, and this is the action account specified during SCOM setup. This is the account that often gets set as local administrator across the domain for ease of deploying agents.

The default agent action account is the account is used to run workflows on the agent. In an ideal world, this should be set to the local system account. If this is a server admin, this is where pass the hash vulnerability exists.

Mitigation

The default agent action account has one main purpose: running workflows on agents. For SCOM related tasks that require administrative rights, it’s wiser to simply enter credentials as needed or defining targeted run-as accounts instead of giving this account admin authority on all servers. There is way too much risk in order to save what would amount to manually typing a username/password several times a year.

Options to correct this are as follows:

1) Specify the Local System Account as the action account during SCOM’s agent install.

2) Implement a least privilege mode for the action account.

It was a bit harder to dig up than I’d have liked, but we do have documentation on exactly what the action account needs in a least privilege scenario. That can be found here.

The document states:

The default action account must have the following minimum privileges:

  • Member of the local Users group

  • Member of the local Performance Monitor Users group

  • Allow log-on-locally permission (SetInteractiveLogonRight)

The minimum described above are the lowest privileges that Operations Manager supports for the action account. Other Run As accounts can have lower privileges. The actual privileges required for the Run As accounts depend on which management packs are running on the computer and how they are configured. For more information about which specific credentials are required, see the appropriate management pack guide.

Keep the following points in mind when choosing credentials for the agent action account:

  • A low-privileged account is all that is necessary for agents that are used to monitor domain controllers.

  • Using a domain account requires you to update your password consistent with your password expiration policies.

  • You must stop and then start System Center Management service if the action account has been configured to use a low-privilege account and this account was added to the required groups while the System Center Management service was running.

As you can see, there’s not much to it, and this is a simple step to ensure that your monitoring server does not become the attack vector that an attacker uses to compromise an environment.