Better understanding ConfigMgr 2012 security controls


Many of the solutions we build and provide here at 1E have the option to be integrated with Microsoft’s System Center 2012 Configuration Manager. That kind of work quickly leads to working with SCCM security. In talking with many people about ConfigMgr 2012 security I’ve found that there can be a number of misconceptions or incomplete understandings.

ConfigMgr 2012 security is a very broad topic, so to be clear I’m only talking about some core concepts that apply to the SCCM console, and to what ConfigMgr administrators can do with it (or equivalent solutions, such as PowerShell scripts, that use the SMS provider).

Central to simplifying ConfigMgr hierarchies is removing the need to have primary sites to manage subsets of clients. With ConfigMgr 2007 you might have created a separate SCCM site to manage datacenter clients, another for your clients in Europe, and another for the executives’ computers. The same logic could have applied to managing their ConfigMgr objects, such as packages, task sequences, and software update deployments. SCCM 2012 gives you new options to put controls in place without having to add primary sites.

The first set of such controls are what we’ll call “assignment collections”, meaning collections used to define the clients and users that the administrators can manage. Those are collections that can be assigned to administrators (thus the name, but that’s not official Microsoft terminology). When setting up an administrator in the ConfigMgr console you should assign them one or more collections that the administrator can use. When the administrator is creating deployments or otherwise managing clients or users they can then use those collections to target the right clients or users, or use collections that are directly or indirectly limited to those assigned collections. Clients or users that are outside those assigned collections are not available to that administrator, no matter how the collections limited to those collections are defined.

The second set of controls are “security scopes”. Scopes control which ConfigMgr objects the administrators can see in the ConfigMgr objects (except for collections and the clients and users in those collections, which are limited as above). So scopes control which administrators can see applications, packages, deployments, task sequences, sites, distribution points, software metering rules, configuration items, and a wide variety of similar objects. When creating such objects the administrator can assign the objects only to scopes that they are assigned, and thus other administrators cannot see the objects they have created unless the other administrators also have that at least one of those scopes as one of their assigned scopes.

The third and final set of controls are “security roles”, meaning the ConfigMgr permissions that the administrators have. There are a number of predefined sets of permissions (roles) and you can easily create more.

Between these three sets of controls you can ensure that administrators can do only what you intend, using only their objects or the objects you want, to the appropriate set of clients or users. You can be confident that the administrators won’t do more than intended, no matter what site the administrators have access to.

I hope that’s reasonably clear. I find that SCCM experts know about Role Based Access Control (RBAC) and have no problem with the concept of roles and permissions. Scopes are fairly straightforward too, except that sometimes people think that collections or clients and users can be limited using scopes. Everyone knows about limiting collections (you can’t create a collection without one), but they don’t always appreciate that an administrator can be limited to one or more collections (one or more high-level limiting collections, if you will).

The concepts especially come together when creating deployments – you might want to limit which administrators can see the deployment, and which administrators can include their clients in the target of that deployment. So you might think that scope is the critical concept in that if the admins can’t see the deployment in the console they won’t be able to use it. For example, if your German administrator creates an Office 2013 deployment that is scoped to only the German administrators and targeted at a collection that is defined to contain only the German clients, you might think there’s no chance of anyone else receiving it. But that’s not the case if all your European administrators are ‘assigned’ to a collection that contains all the European clients. In that case an Italian administrator might see the “German Office 2013 Deployment” collection and he could change its rules so that it also includes the Italian clients. Scoping doesn’t stop him from doing that, nor does collection limiting. Of course your administrators are all professionals so this particular example won’t happen, but mistakes along these lines could.

Given this understanding, we should consider whether there are any implications for our processes. One possibility is that you could consider whether you need a process to coordinate object creation. For example, administrators from multiple scopes may require an Office 2013 application, but the second administrator to have such a need might not be able to see that another administrator has already created one because they are in different scopes. With appropriate coordination the second administrator could ask a senior administrator to add his scope to the already existing application, allowing him to see and use it as well.

Any SCCM administrator with even a little experience is aware of the dangers of changing a collection and thus changing the targeting of deployments  using that collection. However, we should extend that thinking to the extension of changing the ‘security boundaries’ of your administrators by changing collections. As a senior administrator you would check the Deployments tab of a collection before changing the rules of that collection to ensure that you don’t increase or decrease the targeting of deployments inappropriately. But do you also check the Security tab to see which administrators can see the clients or users in that collection? You could be unintentionally changing the ‘jurisdiction’ of some of your administrators. This is another good reason to limit the number of collections you use – this gets complicated very quickly.

We hope that this discussion based on our experiences here at 1E is helpful. Ultimately the SCCM 2012 administrator security controls are not complex, but it’s still appropriate to take a few minutes to think through the implications of your security design. Let us know if we can help.

Share this post

Share this post on your favourite social media platform.

Find this article useful?

If so please click here