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)
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)
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:
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:
- Plan your association and distribution strategy and make it consistent
- 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:
- Troubleshooting improper distribution: http://michielw.blogspot.com/2011/02/scom-account-specified-in-run-as.html
- A good scenario based discussion from Kevin Holman http://blogs.technet.com/b/kevinholman/archive/2010/09/08/configuring-run-as-accounts-and-profiles-in-r2-a-sql-management-pack-example.aspx
This posting is provided "AS IS" with no warranties, and confers no rights.