Share via

Why not to use Local System for your core SCOM accounts

  • Article

say-what-logo1

Stay with me here, this is for the SCOM management group installation

 

So first, let's research and figure out what the experts are doing, and what the install guides exist.

Researching expert published documentation helps us understand the options, and we can dive into some of the reasons why.

 

SCOM Security

scom-kh-securityblogcapture

(KH blog )

 

 

SQLRights and roles

scom-sql_accountrightsmapping

(KH blog here to download the XLS (applies for 2012,2016 as well)

 

Experts separate out the various functions into dedicated ID's

 

The reason for multiple ID's is to lower the risk (less vulnerability if one ID is locked out, expired, disabled)

-- If you use one ID for all SCOM functions, and something happens to the ID, your SCOM environment stops working.

-- There's always some associated risk with either scenario for LocalSystem or ID's (decrypt RunAs ID's UK blog )

If that is a concern, here is some great advice from Kevin Holman

  1. Control who has access to SCOM
  2. Control who has access to the servers using RunAs accounts, that are monitored by SCOM.

If you have lost control of local admin on a server, you are compromised, and I am not sure how gaining access to a RunAs account is no worse in some sense.

By the way – this is the entire reason “more secure” was introduced in SCOM 2007R2, to limit distribution of credentials only to servers that required it, to limit the potential for a local attack.

 

Another option (not recommended) is using Local System

-- Cannot login to system to verify access concerns (quite honestly is why someone might sanction this approach)

-- Scripts run as local system can be terminated, allowing a command window with Local System access

-- Depending on which services LocalSystem is used, this could grant elevated privileges (like a Domain Controller DC)

localsystemaccount

-- If 'Local System' was used for the core SCOM environment, a change made to the Local Security Policy, or group policy can break the environment.

Local Security Policy snapshot localsystem-localsecuritypolicy

Security Options localsystem-securityoptions-localsecuritypolicy

Group Policy

Locking down protocol blog here gpo-snapshot-technetwebsite

 

 

 

Hope this helps you decide the 'how to' set up your environment

 

 

Related documentation 2016 Kevin Holman Deployment Guide 2012 R2 Kevin Holman Deployment Guide 2016 Technet Deployment Guide 2012 Technet Deployment Guide 2007R2 Technet Deployment Guide