Security

Microsoft SCCM 2012: Understand role-based access control

Scott Lowe explains the new security model in Microsoft's System Center Configuration Manager of role-based access control. Here are the basics.

In the olden days, implementing granular security in System Center Configuration Manager was a bit of a chore. To get really granular meant architecting the SCCM environment into multiple primary sites or creating custom consoles for specific classes of administrators.

With the newly released System Center 2012 Configuration Manager, the security paradigm has changed for the better. With this new version comes a new security model, which revolves around the concept of role-based access control (RBAC). Here are some of the benefits that are experienced with the new role-based access control:

  • Simplified security. The entire security experience in SCCM 2012 is a far cry from what it was in older versions of the software. It's much easier for an administrator to limit the activities of other administrators to specific sites, functions and collections.
  • Simplified architecture. No longer does SCCM have to be implemented with multiple primary sites in the name of easing security concerns. Now, an organization could conceivably implement just a single site and still maintain strong permissions.
  • Simplified administrative experience. Although it was possible to create custom consoles in older versions of SCCM, it took additional time to do so. With SCCM 2012's role-based access control, administrators see only what is relevant to their permissions. If a function is not allowed, it's not shown. Further, if a user is not allowed to perform certain actions, he is not provided an opportunity to see those actions.

Role based access control components

Role based access control in SCCM 2012 is made of up the combination of two distinct administrative elements. Actually, there is a third element, but we'll discuss the two primary elements first and then hit on that third one.

  • An SCCM role identifies what a user is allowed to do. SCCM 2012 includes 14 predefined security roles and you can create new ones as needed.
  • An SCCM scope encompasses the objects that a user can manipulate. SCCM 2012 ships with just two security scopes, but you can create new ones as needed. Objects in SCCM can be tagged with one or more of these scopes.

When these two elements are combined, you get a nice Venn diagram. In the middle of this diagram are the rights that a user actually has.

Figure A

A look at how RBAC operates
As mentioned above, you tag objects in SCCM 2012 with security scopes that you create. By default, there is a scope named All that includes all securable objects. There is also a scope named Default that is used, well, as a default. But, you could, for example, create a security scope called "Distribution Point managers" and then assign objects to it. Any administrators assigned to this scope would be able manipulate the objects tagged with this scope, but only insofar as the role permissions you've assigned allow. In Figure B, you can see that I'm tagging a distribution point with the "Distribution Point managers" security scope.

Figure B

There are three usable security scopes here.
So, I've now tagged the distribution point. Now, I just need to add a Read-only analyst user that has rights to that particular scope. You can see this happening in Figures C and D. Figure C gives you a look at a user with the appropriate role selected on the Security Roles tab. Figure D shows you the scopes that are assigned to this user.

Figure C

A user's assigned roles

Figure D

A user's assigned scopes and collections

You might note that Figure D has an extra element --a collection. If you've used SCCM in the past, you already know that a collection is a set of resources in SCCM. For example, you might create a collection that consists of all of the desktop computers assigned to the Sales group. With this security model, you can further limit an administrator to being able to manage only those collections to which you provide access, as you just saw.

Summary

Role based access control in SCCM 2012 is a replacement for the old administrative model found in previous versions of SCCM and provides easier ways for organizations to restrict access to SCCM's powerful capabilities.

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

1 comments
JLogan3o13
JLogan3o13

I'm currently contracting with a large health organization that recently implemented SCCM 2007 (decision made before my start date). Only after implementation did they realize the hurt they were in for, as they have about 4 different levels of access they wanted to deploy. In the end, the only option was to give everyone more access than they should have, and then create a custom console. I've spent months coding this custom console from scratch, and have it integrated with A.D. groups so the technician only sees the options he should (even though, in truth, he has much more security behind the scenes). I wish I could have taken a photo of the clients' faces as I explained to them: "Yes, I know this is a Microsoft product, but no you can't dole out permissions based on group membership." "No, grouping your applications by 'Site-Licensed' and 'Single-Licensed' doesn't by you anything. SCCM is unaware of sub-collections, so any collection you want them to have access to you will have to manually grant that access. I'm sorry you have almost 400 collections." "Yes, I know it is a Microsoft product, and I know they pretty much invented inheritance. They did not choose to make use of it in this product."

Editor's Picks