In the previous post I introduced Role Based Access Control in ConfigMgr 2012 as the new way to delegate administrative access to a ConfigMgr hierarchy. In this post I’m going to walk you through a scenario and show you how we can delegate the access in order to meet the requirements.
The Customer is a very large company, which has a Shared Service Center responsible for the ConfigMgr environment. Each OpCo has its own IT department which manage their own servers and workstations. In the past each OpCo had their own Primary Site, and they should now be able to operate the environment in a similar way, while the Shared Service Center manages the environment. With operating you should think about:
- Create Packages and Applications
- Create Task Sequences
- Specify their own Client Settings
- Create Deployments
- Install Distribution Points
The company wants to facilitate sharing between OpCo’s though, therefore objects created by OpCo’s should be able to be shared
1. Creating the Discoveries
The first thing that we need to do, is to make sure that the Computers, Users and Groups of the OpCo are discovered by ConfigMgr. How you configure this depends on the scenario, in my case eacht OpCo managed one or more domains and within those domains specific OU’s were created for Users, Computers and Groups. For each OpCo I modified the the following discovery types in order to import the computers, groups and users of that OpCo:
- Active Directory System Discovery
- Active Directory User Discovery
- Active Directory Group Discovery
2. Creating the OpCo Collections
The second thing we are going to do, is create the OpCo collections, we are going to create the following collections:
- OpCo1 – All Systems
- OpCo2 – All Systems
- OpCo1 – All Users
- OpCo2 – All Users
- OpCo1 – All User Groups
- OpCo2 – All User Groups
In my case I created the OpCo – All Systems collection based on the domain the machine is a member of, and the same for the All Users or All User Groups collections. When creating the collections use the All Systems, All Users and All User Groups collections as limiting collections.
When using the Domain as the identifier you can use the Computer System attribute class, which contains the Domain Attribute, but you can also use Computer Resource, which contains the System OU Name attribute if you want to make a selections based on OU.
Use similar mechanisms to create the OpCo – All User and OpCo – All Groups collections.
3. Creating the Security Scopes
Next thing we are going to do is to create 3 new security scopes, the first is called SSC and the other two OpCo1 and OpCo2
Go to the Administration pane, and select the security folder. Click on Security Scopes and select Create Security Scope from the ribbon.
Creating the OpCo Client Settings
Next thing we are going to do is create OpCo Client Settings and scope them to the corresponding OpCo security scope
Select Client Settings from the Administration pane and using the Create Custom Device Settings and Create Custom Client User Settings buttons from the Ribbon create new settings for each OpCo. After you created the custom client device and custom client user settings assign the OpCo specific security scope to them.
4. Mapping the OpCo roles to the ConfigMgr roles
Now the more difficult part starts, we are going to discuss this in the next blog post. We are going to map the OpCo administrative roles to the ConfigMgr roles and scope those roles to the Security scopes.
All Articles in this serie:
1 thought on “Role Based Access Control in ConfigMgr 2012: Part 2 Scenario”