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:
Two other groups were created, although not on the management 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:
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:
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.
Kerrie Meyler, MVP, MCSE, MCTS, MCT, is an independent consultant and trainer with over fifteen years of experience in IT. While at Microsoft in Field Technical Sales for four years she focused on infrastructure and mangement, presenting at numerous product launches. Kerrie has presented Operations Manager 2007 at TechEd 2007, MMS 2009, MMS 2011, and internal Microsoft conferences, receiving company recognition and awards including a SPAR MGS award. Kerrie worked with Microsoft Learning to develop functional specifications for the original Operations Manager Microsoft courseware, 2550: Implementing Microsoft Operations Manager 2000 and did the beta teach for that course.She also participated in development for several System Center certification exams.
Kerrie is the lead author of Microsoft Operations Manager 2005 Unleashed, System Center Operations Manager 2007 Unleashed, System Center Configuration Manager (SCCM) 2007 Unleashed, System Center Operations Manager 2007 R2 Unleashed, System Center Opalis Integration Server 6.3 Unleashed and System Center Service Manager 2010 Unleashed.
Check out an excerpt from System Center Operations Manager 2007 Unleashed, Chapter 3: Looking Inside OpsMgr.
You can also check out an excerpt from System Center Configuration (SCCM) Manager 2007 Unleashed, Chapter 3: Looking Inside ConfigMgr.
Read a sample chapter of System Center Operations Manager 2007 R2 Unleashed at Chapter 1: Introduction and What's New.
You can also read a sample chapter of System Center Opalis Integration Server 6.3 Unleashed at Chapter 1: Introducing Opalis Integration Server 6.3 and System Center Service Manager 2010 Unleashed at Chapter 1:Service Management Basics.
System Center Service Manager 2010 Unleashed was selected as the September, 2011 book giveaway for Microsoft Subnet.