With the upcoming release of OpsMgr 2007 R2 RTM, I wanted to offer some
guidance on getting the best out of some of the new security enhancements in the
R2 release. The ‘Run As’ functionality within OpsMgr provides the ability to
carry out monitoring and execute administrative tasks using a specific account
without ever presenting the account to the Operator. This allows the OpsMgr
accounts to be configured with a minimum of security permissions and facilitates
the configuration of specific accounts for individual applications and servers
such as a dedicated account to access a SQL instance.
In OpsMgr 2007 SP1, each object in a management pack is configured to use a
specific Run As Profile. Run As Accounts are assigned to the
profile for each agent that needs to use the account. For example, to carry out
full monitoring of SQL on SERVER1 you create a Run As Account and
assign it to the SQL Run As Profile specifically for SERVER1 (along
with any other SQL servers that use this account). This functionality allows you
to configure a distinctly different account for each agent individually or use
the same account for multiple agents.
The new R2 release of OpsMgr brings with it some additions to this security
model. The main differences are with the granularity of the use of Run As
Accounts and with the fact that the accounts must now be manually
distributed to appropriate agents to add an additional layer of security.
The following screenshots show the new process for creating a Run As
Account, distributing the account and associating it with a Run As
Profile.
The first step is to create a Run As Account as you did in OpsMgr
2007 SP1, configure the name, account details etc. The only difference you will
notice is on the last screen of the wizard, shown below (click the image to see a larger size):
You have two options here; Less Secure and More
Secure. Basically, less secure means that the account you are
configuring will be distributed to all managed agents. This is a security risk
but in order to actually impersonate the account, a user would have to be logged
onto the agent, would have to submit a module into OpsMgr using the $RunAs
replacement and would have to output the results to be able to glean the account
details. This is no small feat but it still possible.
With that in mind, the recommended setting is ‘More Secure’ which means that
once the account has been created, you’ll need to go back into the properties
for the object and choose the agents to which you want to distribute the
account. This setting is especially important in environments where you are
monitoring agents in un-trusted domains or DMZ’s since distributing an
unrecognized domain account to these machines results in the following error in
the console and this error will appear multiple times (sometimes causing a mini
alert storm).
Once the account has been created, you need to assign it to a Run As
Profile. In SP1, this used to be simply a case of selecting the agent and
the account you want to use but Microsoft have now made this more granular to
take into account applications such as SQL which can have more than one instance
(and therefore set of credentials) per server. The selection screen for the new
Run As Profile wizard is shown below:
When selecting the objects which will use the credentials, you can simply
select the ‘All Targeted Objects’ option which will use the same account for all
monitors, rules and tasks or you can select a specific Class, Group or Object to
use the account. I find the use of groups most useful as you can configure your
own custom groups and use them. However, the use of groups introduces its own
problems. Because the Run As Account validation happens on the agent
before the enumeration of groups, using groups in a Run As
Profile may result in one or two of the above errors being generated.
Unfortunately, these alerts are somewhat cryptic (as you can see in the image
above) but a member of the Product Group has created a tool which helps to
troubleshoot these alerts. I’ll cover this tool off in my next blog post.
In summary, the new ‘Run As’ functionality in OpsMgr R2 adds significant
flexibility to the product but at a cost of making configuration and planning
more complex. However, I firmly believe that the benefits outweigh the added
complexity.
Read the complete post at http://www.1e.com/1EBlogs/post/2009/04/22/Making-the-Most-of-Run-As-in-OpsMgr-2007-R2.aspx