In the first part of this series I outlined what Microsoft changed in ConfigMgr 2012 in order to introduce Role Based Access Control. In the second part I outlined a possible scenario and started building the scenario. In the third part we mapped the business roles to the ConfigMgr roles and configured them in the ConfigMgr console. In this part we are going to see, what the outcome of this mapping has become.
SSC Operations Administrator
The SSC Operations Administrator can manage the whole environment, except for the security. As you can see, when a SSC Operations Administrator opens the ConfigMgr Console, he isn’t able to modify the security under Administrative Users.
Looking at the Applicaitons though, the SSC Operations Administrator can see all of the applications, because the role is scoped to the All Security Scope.
OpCo1 ConfigMgr Full Admin
The OpCo1 ConfigMgr Full Admin role provides access the console, but the person member of this role can only see the OpCo1 and SSC Security scope.
If he or she opens an object scoped to the SSC security scope though, he or she is not able to modify its settings, because of the Read-Only operator rights.
The account is also able to create Boundaries, Boundary Groups and can even add Site Systems to the hierarchy because it’s an Hierarchy Administrator.
Note: Keep in mind though that if you want to let the OpCo1 ConfigMgr Full Admin to be able to create site systems under the PSS, you should scope the Primary Site to the OpCo1 security scope.
Looking at the Device Collections, the OpCo1 ConfigMgr Full Admin can only see the OpCo1 – All Systems collection, and therefore when he or she decides to create a collection, it can only provide the OpCo1 – All Systems collection as a limiting collection.
Therefore, the Systems of OpCo2, when specified correctly can never by impacted by the OpCo1 Administrators, because we can’t target them either in new collections, or by deploying packages, applications or task sequences to them.
OpCo2 Desktop Team
When starting the console as someone who is member of the Desktop Team of OpCo2 you will notice that the console doesn’t display the Administration and the Software Library panes. The Opco2 Desktop Team member only sees the OpCo2 – All Systems (and any new collection created which is scoped to OpCo2 – All Systems).
We now have created 3 different security roles based on our security matrix. OpCo1 and OpCo2 can operate the ConfigMgr environment independently from each other, both OpCo1 can see the SSC scoped objects which are supplied by the Shared Service Center department, like fore example the install.wim for installation of Windows 7. We also created a reference Task Sequence on the SSC level, which eacht OpCo can then copy and scope to its own level allowing the OpCo to modify the Task Sequence to their own specific needs.
Some things to keep in mind
While these series only provided a basic scenario, more advanced scenario’s are possible. When designing your RBAC you can use the Role Based Access Viewer as part of the ConfigMgr Toolkit, the RBA Viewer can help you to model the Roles within ConfigMgr. More information about the RBA viewer can be found at the blog of Anoop C Nair here.
1. Make sure you inventory what OpCo users need to be able to do, so think in terms of:
- Needs to be able to create deployments of Applications on Collections
- Must be able to create an Application
Then try to map these requirements to business roles, and translate them to the ConfigMgr roles. Use the default roles available as much as possible, and only create custom roles if really needed. Try to keep it simple, by presenting your OpCo’s with a default configuration to begin with.
2. When you don’t use unknown computer support, a computer which is imported is only available initially in the All Systems Collection. If you make it a direct member of a collection which doesn’t have the All Systems collection as a limiting collection, you will not see the computer object. Therefore you should create a second Collection besides OpCo – All Systems, for example OpCo – New Systems OSD and make a query based on the Computer name, which should the All Systems collection as a limiting collection. We must do this because the OpCo – All Systems collection is based on inventory data and machines which are imported don’t have this data available
3. Keep in mind that newly created object get the “default” security scope. This means in our case, that that application can be seen by all the Opco’s (because they are all scoped to the default security scope). We instructed the OpCo admins to scope the Objects to their own OpCo Security Scope.
4. When you want an OpCo infrastructure administrator to be able to install Site Systems under your only primary site, you need to scope your primary site to that OpCo security scope as well. That means, that the Opco infrastructure administrator also gets all the rights on properties tab of that Primary Site. Make sure that you educate your OpCo Infrastrucure Administrators on this, and make them aware of the impact this can have.
All Articles in this serie: