RunAs Accounts – my own view


RunAs account, profiles and distribution are often a source of confusion in many customer sites I visited.

These three concepts are key to OpsMgr monitoring security, they allow to use the proper account with the proper security rights for the proper object. Beware they’re not free, you have an operational cost and a resource cost on your agents since every different runas account needs it’s own monitoringhost process. To know more on accounts, profiles and distribution there’s a fairly clear introduction at http://technet.microsoft.com/en-us/library/bb735423.aspx.

For a MP developer just

In my experience the main confusion starts with account to profile association. Let’s take a step backward. The MP developer defines runas profiles, she/he associate the profiles to specific classes (i.e. types of objects to be monitored) and then spend the profile on the workflows (monitors, rules, discoveries, …) that need to have specific privileges. The OpsMgr admin must define which security account will be used for a specific profile on a specific object. If she/he does nothing the default action account would be used (by default it is LSA or SYSTEM).

Now, when adding a runas account to a runas profile we basically have two choices:

  • Use it for all targeted objects (that means for ALL the objects the MP author has spent the account on)
  • Use it for a specific subset of objects (all the objects of a specific class, the objects included in a group, specific objects you pick)

clip_image001

Once associated, the runas account must be distributed to all the involved agents, here again you have two options:

  • Distribute the account to all computers (less secure)
  • Distribute the account to specific computers (more secure)

clip_image002

First rule to remember: if an object is targeted by a specific runas account, the runas account *must* be distributed to the agent hosting the object, if the object has not been targeted then the default action account is used. If you miss this point you’ll get an alert telling you a runas account is missing on the agent. This implies that if All targeted objects is used, the runas account must be distributed to all the possible systems managing that class of objects.

Second rule: If you select a specific targeting (vs All targeted objects) you must know which are the runas profile targets (classes or objects) or targets hosting the desired ones. You can for example use the windows computer target class for local applications objects, the fact that you can doesn’t mean you should, as we’ll see shortly.

The UI is very flexible and you can end up with the same object being targeted by different runas accounts: a configuration with a generic account targeted to all objects and then a specific account to a class or group, generates this specific situation. The agent should resolve the runas account with the more specific ones, much like overrides do, but if it, for any reason, cannot you can have unpredictable results. In "any reason" we have everything, from software bugs to bad/ambiguous configurations, to timing issues during configuration reloads (but these will fix by themselves). An example of configuration I found very intriguing is this:

clip_image003

In this situation I don’t know what is supposed to be the most specific class (maybe the agent should follow the hosting relationships if any, in this case the more specific rule should be the HealthService targeting), but I often got unpredictable results in this situations.

So, in the end, I started to follow some simple and basic rules that helped to solve every runas mess I encountered so far:

  1. Plan your association and distribution strategy and make it consistent
  1. be as specific as you can and try to use just one targeting mechanism: if you go for objects then stay for objects, if you use groups then stay with groups and be sure no overlapping members are present in groups.

Finally some useful link to drill deeper:

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

Advertisements
  1. Making DELL management packs lighter for your management servers « Quae Nocent Docent

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: