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.
A look at how RBAC operatesAs 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.
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.
A user's assigned roles
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.
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.
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 with CampusWorks, Inc. Scott is available for consulting, writing, and speaking engagements and can be reached at firstname.lastname@example.org.