It seems you can mix and match, and make it up as you go along. I guess it's a bit like going to Subway. They have all the menu items listed, but you don't need to choose them, you can roll your own!
We needed to roll up some security in our environment to 'limit the damage'. We all know how easy it is to deploy a piece of software or configuration to a bunch of devices by accident, and how fast things deploy when you don't want them to! Thankfully, the new Role Based Administration in ConfigMgr 2012 is here to save us!
Enter RBA
Our requirements are fairly simple, but the spread of devices is what adds the complexity. Let me explain.We have around 230 sites, each with their own fleet of devices. They range from sites with 20 devices, to sites with 1600. Most are in between these extremes. To support these sites, we have around 150 support staff who provide all the front line desktop support services. Next up, we have around 8 support staff that look after the SoE - that is Drivers, Task Sequences, Desired Configuration Management, and other things related to Operating System Deployment. Finally, there are the ConfigMgr admins, who just ensure things tick, and repair components when they fall down.
In our ConfigMgr 2007 environment, all users are added individually, and the permission set is pretty vague. We wanted much more granularity when it came to 2012. Each of our front line support staff look after 5-10 sites, and don't often have to manage devices outside these scopes.
Components of RBA
The components that make up RBA are:- Security Scopes: Used to limit the objects that an administrative access can manage.
- Security Roles: Grant actions that can be performed on a securable object.
- Administrative Users/Groups: Are Users/Groups from Active Directory, that are assigned Roles, Scopes and Collections to define a set of permissions to objects.
- Collections: Are groups of resources such as Users or Devices.
Our Requirements
To kick off, we thought about what are the minimum requirements for each of our support roles.Front line support:
As a front line support person, you need to be able to see what devices are in which collections, and which deployments are/should be targeting your clients. You should also be able to see which packages and applications have been created and deployed, and which are still in development.Front line support staff also have some other requirements.
- Package/Application Creation and Testing.
- Deploy a Tested and Approved Application.
SoE Admin:
As a SoE administrator, you need to be able to update drivers and driver packages, work with task sequences, distribute packages and applications, and generally do just about anything related to OSD.ConfigMgr Admin:
These staff need access to configuration settings, security, site systems, SUP & FEP etc.Getting there
To achieve these requirements, we needed to use a mixture of Collection limiting, Security Roles, Security Scopes and Administrative Users (Groups).First of all, we determined that we needed a collection structure that we could use for limiting device and user scope. Our Active Directory environment was already pretty well laid out, and as such, each site has its own Organisational Unit and Workstations sub-OU's.
I scripted the creation of these collections based on OU Name, using a query rule for the OU itself. This collection is limited to the All Workstations built in collection. We created two other base collections, one was called All Workstation Deployments, which had an include rule for the All Workstations collection. This one was to be used when targeting deployments. The reason for not using the All Workstations collection is that when you grant permission to a collection, you also get all the child collections (all collections based on a collection). The other base collection was 'All Test Workstation Deployments' which is based on an Active Directory group for deployment testing.
Next up, we determined that we needed some security scopes for the different states of package/application creation and deployment. We created:
- Production Ready Applications
- In Development Applications
- SoE Applications
(We may add another scope down the track to limit things like FEP/SUP)
Now came the roles. We had already determined the support requirements, so we made some roles to suit those. In building the roles the RBAViewer application included with the ConfigMgr 2012 Toolkit was immensely helpful.
- Role-SCCMRead - Providing read-only access to just about everything. This role was a copy of the Read-only Analyst built in role, with a few irrelevant items removed (irrelevant to our environment)
- Role-ITStaff - Providing the ability to remote manage clients and update collection membership. This role was based on the Remote Tools Operator built in role.
- Role-SCCMApplicationCreator - Provides almost the same functionality as the Application Author role on which it as based, we removed a few permissions like being able to change the security scope of a package or application as well as a couple of other changes. (The Application Author role has 7 more permissions)
- Role-SCCMApplicationDeployer - Grants the permission required to deploy an application to a collection. This role was based on the Application Deployment Manager - removing 23 permissions, mostly around Alerts, Boundaries and Boundary Groups.
- Role-SCCMSoEAdmin - Is a copy of the built in Application Administrator role. We didn't make any changes, but decided to make a new role anyway so that we could easily add or remove permissions down the track as we see necessary.
With the roles created, all that was left was to create the Active Directory Groups, and then add them into the console.
For easy identification, we named the groups the same as the Roles, with the exception of the Role-ITStaff.
This group is a bit different, because, there is one for each of the sites that contains the IT staff that look after that particular site.
Here's how the Administrative Users/Groups ended up:
Role-SCCMRead - This is the base role assigned to a front line support person. It has a Security Scope of Default, and a base collection of All Workstation Deployments. This collection scope allows the staff to see all collections based on this collection.
TTX - IT Staff - there will end up being 230 entries for these groups, one per site. This allows us to scope a front line support person to their specific site(s).
As you can see from the screen shot, the group is set to only be assigned to instances in the security scopes and collections. Here I have added the Default Scope - which doesn't contain much, and the Workstations collection that is specific to that site. The role assigned is the Role-ITStaff role.
Role-SCCMApplicationCreator - This role is assigned the Security Scope of Application Development. This scope will be applied to all applications created by the user in this group. What this means is that applications in this specific scope, can only be deployed to collections within the All Test Computers collection. This is how we distinguish between production and development applications.
Role-SCCMApplicationDeployer - Users with this role are able to deploy applications and packages that have been assigned the scope of Production Applications. They can do so to only the All Workstation Deployments collection, and sub-collections of this. This does still leave some room for error. I'll let you know or way around that shortly.
Wrap Up
This gets us to the end of our quest for secure and safe in the console.
Except, as i mentioned, the Role-SCCMApplicationDeployer still has a fair amount of scope for error.
To alleviate this, we have devised a plan whereby, once the Application Creator has finished their part, they log a service request in System Center Service Manager, this service request is then approved/denied by one of the SoE Admin team based on their check of the package. If approved, the service request initiates a runbook in System Center Orchestrator. This runbook takes care of the following steps:
Creates AD Groups if they don't exist.
Creates Collections, with Query Rules targeting the newly created AD Groups.
Create a Deployment Rule targeting the newly created collection.
Service Manager then emails the requestor with the group name, which they then add their machines to, and the software is deployed to the clients as desired.
This removes the scope for error that we have with people deploying software manually. It also brings us some standardisation of naming and collection evaluation scheduling.
Of course, this wont work for every situation, but for the majority, it should suffice.
We have around 1000 differenet applications being deployed in ConfigMgr 2007 at present, we hope to cut that back a bit in 2012, but, for now this is the plan!