Security Model
The Operations Manager 2007 security model incorporates Active Directory and the SDK to secure objects and workflows, and is prevalent in all areas of SCOM, including the Operations Console, the reporting UI, and the discovery and monitoring workflows running on agent-managed computers.
Although we have all the guides available at our disposal, it can be a lot of reading and usually requires some degree of hands-on experience to gain an understanding of how all these components are comprised and the relationships between them. Here I’ll try to break it down in terms that everyone should be able to understand relatively quickly.
Relationships Between Active Directory, User Roles and Run As Accounts
User Roles are containers in Operations Manager 2007, which can be populated with Active Directory users and groups to control the type of access an operator has in the Operations Console. There are different types of control mechanisms in the User Roles configuration, which describe which tasks an operator can perform and what monitoring data the operator can view in the console.
Note: User Role scoping also affects what an operator can do and see while using the Command Shell.
Run As Accounts are objects that are associated with a Active Directory accounts. Run As Accounts are a type of service account, which enable discovery and monitoring workflows to function properly on agent-managed computers. A Run As Account and an Active Directory account maintains a 1 to 1 relationship.
Relationships Between Run As Accounts, Run As Profiles and Computers
Run As Accounts are the key to gaining access to run monitoring workflows on resources requiring elevated privileges, in cases where the Default Action Account does not have sufficient permissions. The Default Action Account on agent-managed computers is most commonly Local System.
Run As Profiles are defined in a management pack and are the vehicle for delivering the configured Run As Accounts to an agent-managed computer. A Run As Account is also associated with a computer via distribution lists that the SCOM administrator configures.
Once a Run As Account is associated with a Run As Profile and the distribution is configured, discovery and monitoring workflows requiring elevated privileges, as defined in the management pack, will use this account to successfully run the workflow.
Relationships Between User Profiles, User Roles and Monitoring Data
A User Profile is a template that defines each of the User Roles that an Operations Manager administrator can create. Each User Profile comes standard with a set of privileges that allow or restrict a User Role to specific areas in the console in a default configuration. The User Profile does not define restrictions on monitoring data, but on the level of access a new User Role will have in the console.
Outside of the default User Roles, an administrator can create new User Roles and scope those to monitoring data. For example, an administrator can create a SQL Operators User Role and scope this role so that these operators can only view monitoring data related to SQL Server and the SQL Management Pack.
With the same example in mind, consider the processes at your company. You may want to allow the SQL team to customize monitoring of their SQL Servers. By scoping a User Role created from the Advanced Operator User Profile template using the same concepts, this will effectively allow the SQL team to view only their SQL related monitoring data and customize (override) discoveries, rules and monitors that would affect their servers.
Comments
Anonymous
January 01, 2003
If you've been reading our blog for a while you'll remember that back in March of this year we postedAnonymous
January 01, 2003
NOTE: This information has been updated. To view the latest version see blogs.technet.com/.../jonathanalmquist