SCCM 2012 security changes – Part 2: RBAC

In Part 1 of this article, I discussed the status quo of access control and security within Configuration Manager up to version 2007. I included a brief example of the limitations that security model imposed on SCCM admins. I also promised to follow that up with an exploration of what SCCM 2012 security brings to the table to address those limitations.

Author
Recent Posts

David Stein

David is an author and consultant, working for Endurance IT Services in Virginia Beach, Virginia, specializing in Microsoft enterprise systems and Business Process Automation.

SCCM 2012 Security Roles

Basically, Security Roles are templates for granting rights, and Security Scopes are templates for describing what the Security Roles can access. There are quite a few built-in Security Roles in SCCM 2012, such as:

Application Administrator
Application Author
Application Deployment Manager
Asset Manager
Compliance Settings Manager
Endpoint Protection Manager
Infrastructure Administrator
Operating System Deployment Manager
Operations Administrator
Read-only Analyst
Remote Tools Operator
Security Administrator
Software Update Manager
Full Administrator

As you can see, they’ve thought of just about everything. However, no one-size-fits-all model works in the real world, so they provide you with the tools to copy and create Security Roles as well. You cannot change permissions settings, delete or export the built-in Security Roles shown above, but you can configure them on your own custom Security Roles. You can also copy the above built-in Roles to create your own using a baseline to work with.

Be careful with combining Roles, as it doesn’t always work as well as you might expect. Microsoft provides “best practices” guidelines to help administrators get the most from their products, and one of their recommendations is to be as sparing as possible with creating new Roles. For example, if you want to grant rights to both create and deploy applications, to a particular group of users, it would be better to add the users (or groups) to the “Application Author” and “Application Deployment Manager” Roles, than to join these Roles into a new hybrid Role.

SCCM 2012 Security Scopes

A Security Scope “establishes security restrictions between the user and object instances” as described by Microsoft. The permissions the user will have with that object instance are determined by their assigned Security Roles.

As with Security Roles, there are built-in Security Scopes, but you can also create custom Security Scopes. Not all Object types can be included in a Security Scope. You can only include the following types:

Applications
Packages
Boot Images
Sites
Custom Client Settings
Distribution Points
Distribution Point Groups
Software Update Groups

You can view Security Roles by going into the Administration panel and expanding “Security” and selecting “Security Roles”. Built-in Roles cannot be deleted or modified, but you can copy them to create custom roles.

SCCM 2012 - Security Role

If you open the Properties for an existing Security Role, such as the “Application Administrator” role, the General properties, Administrative Users memberships, and Permissions are all accessible for viewing, provided you have sufficient rights.

SCCM 2012 security - Application Administrator Properties

If you click on the Permissions tab, you can view the security rights that are granted to the Role for each of the types of object classes that exist in SCCM 2012.

SCCM 2012 security - Permissions tab

If you have sufficient rights, you can create new Roles by first copying an existing role, and customizing it to your needs. You should only do this if you absolutely need to, as most of the existing Roles will usually suffice.

SCCM 2012 security – Copy Security Role

Once you have created a custom Security Role, you can then export it to an .XML file, which can be imported into other sites using the “Import Security Role” feature.

SCCM 2012 security - Export Security Role

Unlike Security Roles, you can create new Security Scopes without having to first copy an existing Scope. You have to provide a name, and select the assignments. You can (and always should) provide a Description comment, even though it is optional.

SCCM 2012 security - Create Security Scope

The security management process begins with defining your Administrative Users within the Site hierarchy. You can import Active Directory user accounts or security groups to create Administrative user accounts in Configuration Manager 2012. You can also define their Security Scope memberships and associate their access to either all instances of objects, or only specific instances which are associated with specific scopes or Collections.

SCCM 2012 security - Add Security Scope

How it mixes together

So we have Security Roles and Security Scopes. So what? What makes this so much more flexible than the security model we had in SCCM 2007 and prior?

Rather than setting permissions directly on classes and class instances (objects), we can now group classes and objects into a Scope and assign a Role to that Scope. This decouples the security mapping. If that doesn’t sound like an improvement, consider how this would be if you were managing permissions on a File share. Rather than putting users into groups, and nesting global groups into domain groups, and then granting groups permissions, you would assign users directly to resources. That doesn’t sound all that exciting does it? I know that’s not exactly an accurate comparison, but the general idea is pretty close. Basically, RBAC helps you abstract users from access rights from the resources they access.

Summary

I’ve only scratched the surface of Role-Based Administration in Configuration Manager 2012. I may cover more detailed aspects in future articles, but for now I hope this gives you at least an idea of how flexible and capable this new feature is for managing sites and security.

A word of caution

Before you start experimenting with Roles and Scopes, I strongly recommend you model and test any such changes in a testing environment, which is completely isolated from your production environment. It’s very easy to make a mistake that could cause serious problems within your SCCM 2012 environment. For example, you could end up cutting yourself out of having permissions to undo the problems you’ve created. In a production setting, that could be detrimental to one’s career.

References

Configuration Manager Role-Based Administration

Security and Privacy for Configuration Manager 2007

Book: Mastering System Center 2012 Configuration Manager
Steve Rachui, Kent Agerlund, Santos Martinez, Peter Dalmans (Sybex, ISBN 9-781118-128985)

Read the latest IT news and community updates!

Join our IT community and read articles without ads!

Do you want to write for 4sysops? We are looking for new authors.