Comparing OpsMgr 2007 Security with MOM 2005 Security

If you've used MOM 2005, you're in for a big surprise when it comes to security in OpsMgr 2007. Like most things in the more recent release, things have changed completely.

MOM 2005 security was pretty simple. Each management server used local security groups to restrict the types of operations allowed within the MOM consoles, with no restriction on scope. Microsoft created four groups on a management server when that management server was created:

• MOM Administrators
• MOM Authors
• MOM Users
• MOM Service

Two other groups were created, although not on the management server

• SC DW DTS (System Center Data Warehouse Data Transformation Services) - found on the server hosting the operational database
• SC DW Reader - created on the MOM Reporting database server 

These were local Windows groups when the component was on a member server and domain local grops if the server was a domain controller.

The access of the first three groups had was fairly self-explanatory. An Administrator could do anything in the MOM Administrator and Operator consoles, a MOM Author could author mangement pack but not change which computers were managed or how a computer was managed. This group was for individuals responsible for creating, customizing, importing, importing, and exporting management packs. MOM Users could view and modify alerts; MOM Users were typically Operations staff.

The MOM Service group was used for internal MOM services and processes. Members of the SC DW DTS group could transfer data from the operational database to the reporting database. Members of SC DW Reader could view MOM reports.

There was actually a big deficiency with this model.  By using local groups on each management server to grant management group access, it was possible that the group membership on the different management servers could vary. There was no guarantee that SusieQ, a MOM Author on MS_Server1, was automatically a MOM Author on MS_Server2. To work around this, the best approach was to add user accounts to Active Directory global groups and then add those global groups to the appropriate local groups on each management server.

MOM 2005 also used a number of service and action accounts. We'll focus here on the action accounts:

• The Management Server Action account was used to install and configure agents, run server-side responses for agent-managed computers, run computer discovery, gather operational data from agentless systems, and run tasks issued from the MOM console. Each management server had its own action account, and you could specify the same action account with multiple management servers or use different accounts.
• The Agent Action account ran responses such as scripts or management code responses on the managed computer. It also was used to gather performance data and events information from the local computer. The Local System account was used by default.

So what's different about OpsMgr 2007 security? For starters, these are not local groups. You ADD groups or individual users to roles, typically from Active Directory. In addition, as I point out in my earlier article (http://www.networkworld.com/community/node/22613), security is role based.  Each role was a combination of a profile (capabilities) and a scope (the data and objects one could access). MOM 2005 security was really just profile-based: Administrator, Author, and User. In addition, OpsMgr uses Run As Profiles and Run As Accounts. These can be used in lieu of the Action account to grant access to specific operations in management packs, so that the default Action account does not have access to the world. Let's look at the OpsMgr-provided role definitions:

• Operations Manager Administrators - can do everything
• Operations Manager Advanced Operators - limited change access to the OpsMgr configuration, able to create overrides within the defined scope (which could be customized by adding your groups uwing the Advanced Operator profile)
• Operations Manager Authors - similar to the MOM Authors group in MOM 2005. Again, the ability to customize the scope by adding your own groups using the Author profile)
• Operations Manager Operator - similar to the MOM Users group in MOM 2005, but with the ability to customize the scope by creating groups using the Operator profile)
• Operations Manager Read Only Operator - view alerts and access views based on scope.
• Operations Manager Report Operator - ability to view reports based on configured scope.
• Operations Manager Report Security Administrators - integrates SQL Reporting Services security with OpsMgr roles. Users assigned to this role have access to all report data in the data warehouse. This role cannot be scoped.

To scope access, you can create additional roles based on one of the provided profiles (with the exception of the Administrator and Report Security Administrator roles, which cannot be scoped).

One other thing. In OpsMgr 2007, roles are enforced at the SDK level. Since that encompasses anything that uses the OpsMgr class libraries to connect to the SDK service, we secure access outside the console - including PowerShell cmdlets and custom clients.

Once you've digested this, keep this in mind: you want to plan who has access to which role, and how to best specify your own user-defined roles and grant membership to those roles.