Below you will find a security account matrix for SCOM 2019, that includes all the common service and security accounts in SCOM, and their default or recommended permissions. This includes the management servers, the database servers, SQL Role permissions, and database mappings. You can use this to correct deployments where permissions got modified incorrectly, or to verify that a least privileged model is being used.
Download: https://kevinholman.com/files/SCOM2019_Security_Matrix.xls
Example:
This matrix is for SCOM 2019. For SCOM 2016, please see: https://kevinholman.com/2019/03/08/scom-2016-security-account-matrix/
Is that also correct for SCOM 2016 and 1807?
No. SCOM 2016 link is provided above. 1807 should really not be in use anymore, as it was semi-annual channel and expired…. but I’d probably just use the 2016 permissions example for that.
I don’t think this is entirely accurate, it appears that the MS action account’s permissions on the MS, also need to be applied to gateway servers from which you point the targets before discovery (as well as ‘verify computers can be contacted’ checked. At least that’s the only way I’ve been able to push to servers in different forests than where my SCOM infrastructure is.
What part isn’t accurate? Just the fact that I do not include Gateways?
For SCOM 2019. Just confirming. In the matrix “DAS account (sdk/config)” account does this refer to System Center Configuration Service and System Center Access Service? Also for SQL database mappings what does MSDB stand for?,… is this created by default during the install of SCOM 2019 and what does what kind of information does this database store?,…is this a type of system database in SCOM SQL? Do you happen to know the permission changes on the GateWay Server?
For SCOM 2019 management console (Administration>Run As Configuration) “run as profile” and “run as a accounts”. Is run as profile designed to provide permissions to MP(management packs) when created. The run as a accounts provide the permission that run as profiles require? All this is required for providing the MPs permissions to applt rules within SCOM and it’s targets? What kind of permissions is require for the Agent Action account on the target machines and it this done using the MP?,… this is for Agent to be installed and functioning on the target machine.
Just wanting to clarify my understanding of gMSA for use with SCOM 2019 if one were to create gMSA(group managed service accounts). When creating gMSA do we just install as individual accounts then replace those with similar permission with a gMSA that meets the permissions requirements. When replacing the original account with a gMSA account how are permissions determined for the gMSA?,… is the gMSA object in AD provided with the appropriate permissions here? Password(password = KDS root key which exists in root domain) for gMSA(in child domain) is created automatically during its creation which changes at a specified time interval?
Just wanting to clarify my understanding of gMSA for use with SCOM 2019 if one were to create gMSA(group managed service accounts). When creating gMSA do we just install as individual accounts then replace those with similar permission with a gMSA that meets the permissions requirements. When replacing the original account with a gMSA account how are permissions determined for the gMSA?,… is the gMSA object in AD provided with the appropriate permissions here? Password(password = KDS root key which exists in root domain) for gMSA(in child domain) is created automatically during its creation which changes at a specified time interval? If gMSAs were to be created for SCOM 2019 were to be created would the following make sense based upon the SCOM 2019 matrix above:
gMSASQL – all SQL servers given admin permission by add to their local users group. SQL DB (Ops DB, DataWare DB, Reports DB) use the above matrix permissions set on the SQL instance/database. MSDB stores what information and is it created automatically SQL installation(just confirming)?
gMSAManagementServers – this account includes all Management Servers in the local users group. At the AD object level gMSAManagementServers permission are log on as Service.
gMSA_DASAccount(SDK_Config) – accounts (System Center Configuration Service and System Center Data Access Service) are added to local users group on all Management Servers. gMSA_DASAccount(SDK_Config) at the AD object level is provided with permission are provided with log on as a service.
gMSAManagementServeActionAccount – this account is in the the local users group for all Management Servers. Log on as service configured on its AD object gMSAManagementServeActionAccount.
gMSASCOMInstallAccount – this user account used for the install of SCOM should be in the local admin group of all SCOM servers to include SQL server. This gMSA would stay enabled until we installed a GateWay server at a later time then this gMSA would be disabled in AD. Do you recommend keeping this gMSA enabled instead of disabling it after the SCOM installation is completed?
Nice, thanks Kevin.
Pingback:SCOM with GMSA - BLOG of SCOM
So, looking that the matrix, the Reporting Data Reader Account is the same as Data Warehouse Report Deployment Account in SCOM, and the Reporting Data Write Account is the same as the Data Warehouse Action Account in SCOM???? Thank you! Tony
Hi Kevin,
I have installed a brand new SCOM 2019 according to your “SCOM 2019 – QuickStart Deployment Guide”.
Really good guide, and everything seems to work fine!
But I’m seeing this alert in SCOM from time to time.
“OleDb Module encountered a failure 0x80004005 during execution and will post it as output data item. Unspecified error
: Login failed for user ‘NET\OMAA’.
Workflow name: Microsoft.Windows.Client.Win10.ComputerGroup.MemoryTrendsRAM
Instance name: Microsoft System Center Data Warehouse
Instance ID: {16781F33-F72D-033C-1DF4-65A2AFF32CA3}
Management group: OM1”
A google search on the error code, got me to this site/guide.
I’ve checked the the permissions. They are all identical to the permissions in your guide/excel ark.
Can you guide me in any direction, to find what is wrong?
My Security Matrix is correct for a base level SCOM implementation. However, some management packs can contain workflows that need their own special configuration. The Client Windows MP’s do this. You need to add a login to the DW for the OMAA account, and grant a user mapping to the DW database, with datareader and datawriter for that MP to resolve these errors.
Hi Kevin,
quick question,
is there any other security matrix for SCOM 2022?
or shall we use this one ?
Are there any scripts to help a System Admin get these permissions applied correctly and consistently?
Not aware of any but it would not be too difficult to make. The problem with scripting is that every management group design is a little different.
At our shop, we don’t push agents via the console AT ALL. Since we don’t do this, is there any reason to not use Local System as the action account on the gateways in untrusted domains? (note that in the untrusted domains, the Gateway action account doesn’t have permissions do do anything on the agents anyway)
What about gateways in trusted domains? The same situation applies.
Nevermind, I see I asked this in 2016 already. Feel free to delete (or reply since this is the 2019 thread)
I ALWAYS install gateways using local system only. I haven’t seen any drawbacks and that’s just fewer service accounts to need to maintain.