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, it is generally accepted that the SCOM action account be a local admin on all servers, especially if time is a factor. Ultimately, this is a bad idea.
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 action account has one main purpose: deploying agents and upgrades. Those are tasks, I’d add, that can have an account specified on the fly as needed. As such, I’m not really sure it’s wise to simply give that account carte blanch 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 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.