Hi, my name is Dharmendra Thotakura. I am an engineer at Microsoft, and I specialize in Configuration Manager Application Management, Application Catalog, Role Based Access and User Device Affinity.  For my first post on this System Center in Action blog, I am going to share some of our experiences with System Center 2012 Configuration Manager Role Based Access (RBA), specific to how we implemented it at Microsoft to integrate our application packaging and testing teams (P&T teams) into the Configuration Manager 2012 production setup/console.  We are also using RBA to differentiate access between Incident Management Teams, Problem Management Teams and Service Delivery Teams, but this blog post will focus on our P&T team scenario.

 

For background, our Microsoft application management team has around 500 enterprise applications, and we distribute about 4-5 required applications per month. Like many other enterprise organizations, we also have packaging and testing teams that wrap the applications to meet end-user experience requirements while also adhering to enterprise deployment standards. Historically, our P&T team used to have their own Configuration Manager site to test new packages. This isolation removed the risk of the P&T team accidentally changing the settings on the packages in production and also kept the P&T team from distributing the packages in test to all production DP’s.  In Configuration Manager 2007, we could have had the P&T team create and test packages in a production environment using instance and class security rights, but it was easier for us to implement a separate infrastructure, as workarounds in our environment were not foolproof nor were they role-based. Of course, the drawback to the dedicated site was that it was more expensive due to infrastructure costs and the services effort to keep it running, healthy, and up-to-date.

 

Configuration Manager 2012 includes a robust out-of-box RBA feature, which gave us the opportunity to sit back and think through what we’d been doing to date for our application deployment process and workflow and eventually implement a much more streamlined P&T plan. The first step though was to understand what the different opportunities were in Configuration Manager 2012, so we took some time to review the P&T roles, work through what the different access levels are, and what the scopes for these roles are. 

Understanding the Terminology

As we approached RBA, we first needed to think through Configuration Manager Security Roles and Security Scopes.  A Security Role is a set of permissions that gives users access to perform actions on certain types of objects.  Objects can be Applications, Packages, Global conditions, Distribution Groups, Configuration items, Configuration Baselines and Software Update Groups, among other objects.  Permission for the activity can be Read Collection, Create Application and Delete/Update DP Groups etc.  A Security Scope is used to further control which object instances the administrative user can see and it is used to limit the administrative access to the objects.

 

In other words just having permissions (role) will not let you control all the objects as you need to have been granted the scope to see these objects.  People with different scopes can create same type of objects without having the ability to see each other’s objects. For example, our administrators in Europe can create packages only they can see and deploy, and our administrators in Asia will not be able to see them to deploy and vice-versa even though all of these objects are sitting in the same folder in the console.

 

We can create various combinations of access and workflows among the  different  people involved in various roles by establishing a relationship between Role (permissions) and Scope (on set of objects) to a Collection (targeted machines/users).

 

One important thing to note here is that Collection as an object is not part of the scope. To understand in-depth about scopes and roles please refer to below link from the product group:

http://blogs.technet.com/b/configmgrteam/archive/2011/09/23/introducing-role-based-administration-in-system-center-2012-configuration-manager.aspx

 

Solution

Once we understood Security Scopes and Roles, we were able to craft a solution for integrating the P&T team into the Configuration Manager 2012 console by associating these constructs to a Security Group.

 

Security Scopes

As mentioned before, scope is nothing but a set of objects.  Out-of-the-box Configuration Manager 2012 comes with “Default” and “ALL” scopes.

We created 3 new security scopes:

a)      Packager Scope:  Users associated with Packager Scope can only see the objects in that scope and any objects created by them will inherit that scope.  We gave the packaging team this scope and they also have necessary Roles (permissions) to give them access to create objects.

b)      Tester Scope:  We created a Tester Scope for testing team. Along with this scope they also have access to Packager Scope and Deployment Scope. 

c)      Deployment Scope: Application Deployment Scope is for users who have permission to deploy Applications to the Production collections such as All Systems, All Users and Users Groups. So Applications that got moved to this Scope should have been test-passed by the testing team.

 

Security Roles

Configuration Manager 2012 comes out with out-of-the-box Security Roles, as well as the ability to create Custom Roles, both of which we used for our P&T solution.

 

1)      Packager Role: This role can be achieved by using the out-of-the box “Application Administrator Role” that will let you create and deploy applications/packages. But we created the Custom Role by copying this role and editing it to meet our custom needs. I exported our custom role and added it to this blog in the end for your reference. You can directly import this file as a role into your Console.

2)      Tester Role: This Custom role has only limited permissions like “Move Objects” and “Set Security Scopes”.  Because of their permissions, they can change the scope on the objects to another scope to which they have access. For example, they can change the scope of the Application from Packager Scope to “Application Deployment” scope.  I exported this role and added it to the blog for your reference.

3)      Deployment Admin Role: We used out-of-the-box role called “Deployment Manager Role”.  This role has permissions to only deploy Application/packages, create collections, among other permissions.

 

Packaging & Testing Workflow

 Packaging team creates the package/application in their scope.  When passed to the Testing team they will remove the Packager Scope if it passes testing and will add the “Application Deployment” Scope.  In the end, the Packager cannot edit the Application in production because he cannot see it as it is out of his scope. The Deployment Admin cannot edit the Package in production because he does not have access.  So it is secured process.

 

The table below better explains how we set up the roles. Please note the permissions provided below are not the exhaustive list.   

 

Role Name

Permissions

On Objects

Scope

Collections

Packager Role

Create, Modify, Retire etc.

Deploy, Read

Application/Package

 

Collection  

Packager

Testing Machine

Tester Role

Set Security Scope, Move Objects

Applications/Package

Packager, Tester,  Application Deployment

      -------

Deployment Admin Role

Read, Run Reports

Create , delete, deploy etc.

Application/Package

Collection

Application Deployment

All Systems, All Users and  Users Groups

 

 

Implementation

We continued with implementation by using distinct security groups for packagers, testers and deployment admins.

1)      The Packager’s Security group has Packager role and Read only Analyst Role (comes out of box) and access is to only the “Testing Machines” Collection. Scope assigned to this team is ‘Packager’ Security Scope, like shown below. We set the access this way so packagers create Applications/package in their own scope and deploy to only the test collections. Objects created here will have Packager Scope.  Here’s a screen shot of the Security Scopes:

2)      Tester’s security group has Tester Role and Read only analyst role but has no access to any collections. Scopes assigned to them are Tester, Packager and Application Deployment Security scopes like shown below. Access is set this way so that Testers can change the scope of the Test passed object to ‘Application Deployment’ scope and so Deployment Admins can see the object. The tester is signing off on the package that is being tested by changing the scope. Also, Testers will remove the ‘Packager scope on the Test passed object so Packagers do not get to modify the objects in production. If the objects fail in the test, Packager scope will be added back and will be sent back to the Packaging team.

 

3)      Deployment Admin security group has Deployment manager Role (comes out of box) and Read only analyst with access to “ALL Systems” and “ALL Users and User Groups” collections. The scope assigned to this group is ‘Application Deployment’ like shown below. Access is set this way so Deployment Admins can only deploy but cannot edit the applications that are only signed off by the testing group.  This security group cannot see the objects in Packaging/Testing scope.

 

 

4)      Apart from the roles and scopes shown above, we also created some folders to organize the objects in the console like shown below.  Please note that Folders are not controlled by RBA. If you have permissions to create the object you can create them in any folder and no restriction will be applied. In our environment Packagers create the objects in “Packaging Team” folder and move it to “Testing Team” when it is ready for the test. Testing team moves the object to “Staging for Deployment” folder if the object passes testing but if the object fails testing it will be moved back to Packaging team. Deployment Team moves the object to “Production” folder before deploying it to production collections.

 

This simple RBA approach is how we achieved integrating P&T teams into the production console based on their security Roles and Scopes without having to fear about unintended deployments.  Another benefit of this role based access is that we’ve been able to decommission the testing hierarchy we used prior to leveraging RBA in Configuration Manager 2012. 

 

I’ll be back in the future to share more application-based experiences.