SCOM Run As Account and Profile

In this blog, I will explain:

      1. What is SCOM Run As Account and Profile?
      2. How to configure them?
      3. What best practices to follow?

I will start with a scenario and then I will explain how the Run As Account and Run As Profile will fit into the scenario.

“I have got a request from my SQL Team to monitor the SQL application. They have also provided me with a domain account domain\sqlsvc which has sys admin rights on all the SQL instances in my organization and local administrators on all SQL nodes. Now my task is to import the SQL management packs and make sure we use the SQL domain account to monitor the SQL application”

What is SCOM Run As Profile? 

Any workflow in SCOM may be a rule, monitor, discovery, task etc. is defined in a Management Pack. When you define a workflow you can configure what Run As Profile to use when that workflow will run in the target. Let us take a simple example. 

<UnitMonitor ID=”Unit.Monitor.SQL.Demo” Accessibility=”Internal” Enabled=”true” Target=”Windows!Microsoft.Windows.Computer” ParentMonitorID=”Health!System.Health.AvailabilityState” Remotable=”true” Priority=”Normal” TypeID=”Custom.MyPSTransactionMonitorType.UnitMonitorType” ConfirmDelivery=”false” RunAs=”SQL_RunAsProfile”>

 

The above configuration means that whenever the unit monitor ”Unit.Monitor.SQL.Demo” will run, it will use the Run As Profile “SQL_RunAsProfile”.  

What is SCOM Run As Account?

A SCOM Run As Account will store an account name and password. Then it can be distributed either to all the agents in the Management Group using ‘Less Secure‘ option or to some selected agents using ‘More Secure’ option.

SCOM Run As Accounts are used to associate in Run As Profile so that workflows can under a specific account rather than the agent default action account (which we will discuss soon).

As we have a fair bit of understanding of SCOM Run As Profile and Account, coming back to our scenario, these are the steps I will have to follow to accomplish my task:

  1. Create a SQL Run As Account in SCOM console.
  2. Provide the username domain\sqlsvc and the password.
  3. Distribute the SQL Run As Account to all the SQL servers.
  4. Associate the SQL Run As Account in our “SQL_RunAsProfile”

How to create a SCOM Run As Profile?

The Run As Profile will be created by the Management Pack Author and will be visible under the tab Administration -> Run As Configuration -> Profiles as soon as you import the Management Pack.

How to create a SCOM Run As Account?

  1. Log on to the Operations console with an account that is a member of the Operations Manager Administrators role.
  2. In the Operations console, click Administration.
  3. In the Administration workspace, right-click Accounts, and then click Create Run As Account.
  4. In the Create Run As Account Wizard, on the Introduction page click Next.
  5. On the General Properties page, do the following:
    a. Select Windows in the Run As Account type: list.
    b. Type a display name in the Display Name text box.
    c. Optionally, type a description in the Description box.
    d. Click Next.
  6. On the Credentials page, type a user name, and its password, and then select the domain for the account that you want to make a member of this Run As account.
  7. Click Next.
  8. On the Distribution Security page, select the Less secure or More secure option as appropriate.
  9. Click Create.
  10. On the Run As Account Creation Progress page, click Close.

Distribute the SCOM Run As Account

  1. Once the Run As Account is created, go to Properties of the Run As Account.
  2. Click on Distribution.
  3. Click on Add.
  4. Search for the server/servers and Add.
  5. Click OK again.

Associate Run as Account to Run As Profile

  1. Once the Run As Account is created and distributed, go to Administration -> Run As Configuration -> Profiles -> SQL Server Discovery Account (for example). Open Properties.
  2. Go to Run As Accounts.
  3. Add and Select the Run As Account.
  4. You have 4 options here:
    A. All targeted objects: This is the most widely used option. This simply means that the Run As Account will be used for all the objects in the workflow target. For example, if the target of the SQL discovery workflow is ‘Windows Computer’, then the Run As Account will be used for all Windows Computer object.
    B. Class: This is to narrow down the scope. For example, if we target to class ‘Windows Server 2016 Operating System’, then the Run As Account will be used for all 2016 computers.
    C. Group: Same as class but will more precise scope. For example, I have two domains A and B with some SQL servers in each domain. Obviously, I will be using two domain account or two Run as Account. Now in this case, I will have to create two groups. One group will have SQL servers in domain A and other with SQL servers in domain B. And finally, associated one Run As Account with Domain A and other with Domain B.
    Note: You cannot associate two Run As Account with ‘All targeted objects’
    D. Object: The most granular scoping where we associate the Run as Account with individual object.

What will happen if you do not associate Run As Account in Run As Profile

Many a times we import Management Packs and everything gets discovered, monitored without any configuration of Run As Account and Profiles. Do not be surprised 🙂

SCOM is designed in such a way that it will try to make things work for you as much as possible. But how?

If a SCOM Run As Profile is defined but not associated, then the workflow will run with the ‘Agent Default Action Account’. The agent default action account is the account specified during the time of agent installation. The sole purpose of this account is to run workflows for which either there is no Run As Profile or there is no association inside the Run As Profile.

In our example, if we leave the ‘SQL Run As Profile’ association as blank then the SQL workflows will run under the SQL agents default action account.

Typically, most customers use the ‘Local System’ account as the agent default action account because it has all the rights to access the operating system resource like registries, WMI etc. Additionally, a domain account can also be used. I can think of situation where the local system account is locked down in a secure environment.

How to find the agent default action account?

Using console

Navigate to Administration -> Agent Managed -> Search for the agent -> Look for the column ‘Action Account’

Using PowerShell 

#for all the agents
get-scomagent | select name,actionaccountidentity
#for a single agent
get-scomagent | where {$_.Name -eq 'Test.pop1.lab'} | select name,actionaccountidentity

 

What best practices to follow?

  1. Always use ‘More Secure’ distribution. This will limit noise within your environment because if you choose ‘Less Secure’ distribution  and the account in the Run As Account
    does not have the right to log on locally, an alert will be generated. I see these alerts in many environments.
  2. Try to avoid using Object as target in Run As Profile association. You will soon be in a situation where it will become very hard to manage the association with a long list of objects.
  3. Read the Management Pack guide, especially, the Security segment to configure the permission of the Run As Account in your application.

Take Away

  1. SCOM Run As Account and Profile together are used to run any workflow under a specific account rather than the agent default action account.
  2. The distribution of SCOM Run As Account should preferably be ‘More Secure’.
  3. If the SCOM Run As Profile is blank then the workflow will run under the ‘Agent Action Account’ typically ‘Local System’ account.

Hope you now have a better understanding of SCOM Run As Account and Profile.

Thanks!!

Explore, Learn, Share, Repeat!

 

 

 

 

 

This entry was posted in SCOM on by .

One thought on “SCOM Run As Account and Profile

Comments are closed.