You need to know about this. Yes, there will be a test later.
One of the changes in SCOM 2019 is increasing the out of the box security configuration. Previous versions of SCOM not only allowed, but *required* the “Log on Locally” user right for SCOM service accounts and RunAs accounts. This has changed in SCOM 2019.
The default configuration on SCOM 2019 Management Servers, Gateways, and Agents, is that service accounts and RunAs accounts will now leverage the “Log on as a Service” user right, and no longer require “Log on locally” user right. This means that in order for any RunAs account to work, Log on as a Service is now *required*.
When you install SCOM 2019, the setup program automatically configures this for accounts you specify during setup. You can review this by opening the Local Security Policy > Local Policies > User Rights Assignment > Log on as a service:
You can read all about this change here: https://docs.microsoft.com/en-us/system-center/scom/enable-service-logon?view=sc-om-2019
One of the FIRST places you will notice a challenge, is pushing agents.
When you push an agent, and provide the credential that will query AD then connect to the remote agent and push it, you are actually spinning up a local MonitoringHost.exe process under that credential to do the Agent Push. This works the same as a typical RunAs account, and ANY account you want to use here will require Log On As A Service.
What you might notice is a failure to “find” the agents you are trying to deploy:
You will see an alert generated when this happens: Run As Account does not have requested logon type
You will also see the management server go into a warning state
This is all telling you that the account you provided, even if only temporary for agent deployment, must also have the Log on as a Service Right. For this reason, if you want to do a lot of agent pushes from the console, you should grant your Global Group in AD for SCOM Admins to have Log on as a Service on ALL Management servers. I will show what this looks like here:
You will need to restart your management server after making this one time change for it to take immediate effect.
My Global Group in AD for all my SCOM Admins and service accounts is OPSMGR\OM_Admins, and once I grant “Log on as a service” on ALL management servers, restart the management server, and run the agent discovery wizard:
Keep this in mind, on ALL traditional RunAs accounts, this will be required with SCOM 2019 agents. In previous versions of SCOM, the Log on locally (interactive) user right was required, however in most scenarios customers would simply ensure that RunAs accounts were a member of the Local Administrators group, and Local Admins inherited the Log on Locally user right. That is NOT TRUE for Log on as a Service as this user right must be explicitly defined. Therefore, if you use traditional RunAs accounts in SCOM – you need to prepare and test for this improvement in security, as it will require changes to your process to ensure RunAs accounts have the minimal rights required to work.
Again, I recommend you review the product documentation on this subject here:
- SCOM 2019 agents and management servers (by default) will use the “Log on as a service” user right, and will need to be granted that.
- SCOM 2016, 1801, and 1807 Agents will leverage the “Log on locally” user right by default, and will need to be granted that right.
This can be configured via policy, if you wish to modify it. For instance, you can switch SCOM 2019 agents to use Log on locally, or switch SCOM 2016 agents to leverage “Log on as a service” via:
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System Center\Health Service
- Worker Process Logon Type (REG_DWORD)
- 2 = Log on locally
- 5 = Log on as a service