Summary

Previously, Monitoring Guys had a post about using Group Managed Service Accounts for core Operations Manager Services (link).  However, we can also use Group Managed Service Accounts for RunAs accounts as well.  This article shows you the steps you need to take to make these accounts work in your environment.

Group Managed Service Accounts (Refresher)

From: Group Managed Service Accounts Overview | Microsoft Learn

A standalone Managed Service Account (sMSA) is a managed domain account that provides automatic password management, simplified service principal name (SPN) management and the ability to delegate the management to other administrators. This type of managed service account (MSA) was introduced in Windows Server 2008 R2 and Windows 7.

The group Managed Service Account (gMSA) provides the same functionality within the domain but also extends that functionality over multiple servers. When connecting to a service hosted on a server farm, such as Network Load Balanced solution, the authentication protocols supporting mutual authentication require that all instances of the services use the same principal. When a gMSA is used as service principals, the Windows operating system manages the password for the account instead of relying on the administrator to manage the password.

Support for Group Managed Service Accounts in Operations Manager

Beginning with System Center Operations Manager 2019 (UR1), we can leverage gMSAs for both core services (Data Access, Data Warehouse Action Account, Data Warehouse Report Deployment) as well as RunAs accounts.  This is a great feature for environments where administrators must update passwords for RunAs and Service Accounts. We should all be updating these passwords, but it can be a real challenge.

Demonstration: OLE DB Data Source

For this article, I’ll demonstrate the use of Group Managed Service Accounts using the OLE DB Data Source monitoring template from the SCOM Authoring Console.  I am using System Center Operations Manager 2019 (UR4).  Using gMSA for RunAs accounts will work in Operations Manager 2019 (UR1) and higher.

I am assuming that:

1. Your Active Directory Forest Functional level is Windows Server 2012 R2 or higher;
2. You have configured your Active Directory environment to support the use of Group Managed Service Accounts;
3. You are working from a computer that has both the Active Directory graphical user interface tools and the Active Directory PowerShell Cmdlets installed

For more information about working with Group Managed Service accounts, please see the following link: Getting Started with Group Managed Service Accounts | Microsoft Learn

Scenario

1. I have a database server (SQL202) and a File Server (FS201). 
2. I will be using FS201 to monitor a database on SQL202 with a custom query. 
3. For authentication, I will be using a Group Managed Service Account (sqlQuery$). 
4. The RunAs account that I will create will be distributed to FS201.

Step-by-step

Create OLE DB Data Source Monitor

Navigate to the Authoring Console and expand Management Pack Templates. Select “Add Monitoring Wizard” and then highlight “OLE DB Data Source”.

Notes:

1. In this case, we MUST create the OLE DB Query Monitor first; we need the wizard to create the RunAs profile for us first;
2. Carefully check the frequency for the query; the default is 2 minutes which is aggressive

Create the Group Managed Service Account (PowerShell)

There is no graphical user interface to create Group Managed Service Accounts.  You must use PowerShell to create the accounts (and to make any changes to the account once it has been created).

PowerShell:

New-ADServiceAccount -Name "sqlQuery"  `
-principalsAllowedToRetrieveManagedPassword FS201$ `
-KerberosEncryptionType AES128,AES256

Notes:

1. Like computer accounts, gMSA accounts are limited to 15 characters
2. I am specifying KerberosEncryptionTypes because I have removed RC4 from the available Kerberos Encryption types in the policy “Configure encryption types allowed for Kerberos” (link).  If you have not done this in your environment, you should strongly consider fixing this (link).
3. Note that I am specifying FS201 as the AD object that is allowed to retrieve the managed password for this account.  I could instead use an Active Directory Group to accomplish this.  My personal rule of thumb is that if I am using the account on just one or two servers, I won’t create a group. If I am using the gMSA on three or more servers (or the servers will change frequently), then I’ll create a group and assign “principalsAllowedToRetrieveManagedPassword” to the group.

Provision the gMSA in SQL Server

Since I am using the OLE DB Data Source monitoring template, I will be provisioning this account in the SQL database engine.  This step will vary depending on what you are using the account for.  Group Managed Service Accounts are supported in a number of different applications; the specific steps to create/provision the account will vary depending on the target being monitored.  Generally speaking, it is enough to append the “$” after the account name to indicate that it is a gMSA account (and bypass the requirement to enter a password).

IMPORTANT: Check documentation to ensure gMSA is supported.  Check documentation for the specifics of entering gMSA account credentials.

Create SQL Login and User using T-SQL:

<connect to instance>CREATE LOGIN [abcd\sqlQuery$] FROM WINDOWSUSE <database>CREATE USER [abcd\sqlQuery$] FROM LOGIN [abcd\sqlQuery$]ALTER ROLE db_datareader ADD MEMBER [abcd\sqlQuery$]

Notes:

1. Note the trailing “$” in the account name
2. I am using “db_datareader” to allow the account to select from any user table; your security requirements may be more restrictive.

You can also use SQL Server Management Studio to create the login:

“You can add the credential to SCOM with PowerShell or with the Console.”

– Fancypants Hugh

Add the Credential to SCOM as a Windows Account (PowerShell)

$credential = Get-Credential

Add-SCOMRunAsAccount -Windows -Name "Sql Query Managed" `
-Description "Run as account for SQLOLEDB monitoring template." `
-RunAsCredential $credential

$account = Get-SCOMRunAsAccount -Name “Sql Query Managed”

$agent = Get-SCOMAgent -dnshostname "fs201.abcd.lcl"

Set-SCOMRunAsDistribution -RunAsAccount $account -MoreSecure `
-SecureDistribution $agent

Notes:

1. When setting the credential, be sure to include the domain component (ie, <abcd\>)
2. In this example, I am distributing to a single Windows Server (the designated watcher node); you may need to adjust line 4 to get the distribution right. 
3. The agents to which the account is distributed MUST match the AD computer objects used in “PrincipalsAllowedToRetrieveManagedPassword”

Add the Credential to SCOM as a Windows Account (Console)

You can also use the console to add the RunAs account.

Configure RunAs Profile (PowerShell)

$account = Get-SCOMRunAsAccount -Name "Sql Query Managed"

# Your profile name will be unique
$profile = Get-SCOMRunAsProfile -Name "OleDbCheck_4a97c0424a2048fe8789adb82f389cc3.PrivilegedMonitoringAccount"

Set-SCOMRunAsProfile -Profile -$profile -Account $account -Action Add

Notes:

1. In the example above, I am using an EXISTING OLE DB Data Source monitor. I retrieved the name “OleDbCheck_4a97c0424a2048fe8789adb82f389cc3.PrivilegedMonitoringAccount” from PowerShell by querying for the DisplayName of the SCOM Class
2. In the command “Set-SCOMRunAsProfile”, I am targeting “All targeted objects” (because I have not specified an object, nor a group).

Configure RunAs Profile (Console)

Verify Updates/Changes

Verify Distribution of Account to Agent

First, verify in the Operations Manager event log that all credential references have successfully resolved. Search for Event ID 1109:

If you have not distributed the account to the right agent, you will see Event ID 1108:

Verify Monitor

Now, check the monitor using the RunAs account. In this case, it will be under the folder for “Synthetic Transaction”

Summary

That’s it! Using a Group Managed Service Account for an Operations Manager RunAs Account is really no different from using a regular domain user account. However, you will not need to manage the password for this account, minimizing any disruptions to monitoring caused by regular password changes.

Additional Reading

Run As Accounts and Profiles | Microsoft Learn

Support for group managed service accounts in System Center Operations Manager | Microsoft Learn

Group Managed Service Accounts Overview | Microsoft Learn