In this two part series, I will outline the changes to the security model in System Center Configuration Manager 2012 (SCCM 2012) compared to SCCM 2007.

SMS and Configuration Manager Administrators have struggled for years with managing access control over features within their site environments. Whether it be collections, packages, advertisements, site settings, queries, or reports, it’s been a real challenge at times. Most of the time it’s been sufficient enough to be bearable, but there were times when it was an outright hair-pulling experience. Why?

SCCM 2007 security model ^

The “old” security model was built upon two fundamental sets of “rights”: Class and Instance. A “class” right was of the scope that applied to all items of a given class, hence the name. For example, if you granted a user or group “Read” permissions as a Class right to Collections, they could read the contents and properties of all Collections.

An “Instance” right was of the scope that applied to a particular object, or instance, of a class. For example, if you granted a user or group “Read” permission to a Collection named “All Servers”, then they could read the contents and properties of that one Collection, but not necessarily other Collections.

SCCM 2007 security - Collections, Class, Instance

SCCM 2007 security - Collections, Class, Instance

 

The basic set of “Rights” available in SCCM 2007 were:

  • Administer
  • Advertise
  • Create
  • Delegate
  • Delete
  • Delete resource
  • Distribute
  • Modify
  • Read
  • View

SCCM 2007 security rights

SCCM 2007 security rights

There are quite a few more specialized rights available as well, but these are essentially the “basic” rights. You can always right-click on an instance, click Properties, and select the Security tab to see available permission types.

For a complete detailed table of Class and Instance rights for SCCM 2007 refer to Microsoft TechNet article bb632791. This seems like a reasonable set to work with, so then, what’s the problem? Let’s set up a scenario to illustrate where some of the shortcomings are:

SCCM 2007 Collections security ^

Let’s say you have created a lot of custom Collections for managing resources in your site, and one Collection named “Special”, that you’d like to basically “lock down”. Let’s also say you have several teams of Configuration Manager Administrators at remote locations, and you want only one of those teams to be able to modify this “Special” Collection. You could just grant “Modify” Instance rights to all of the other Collections, but grant “Read” Instance rights to this one special Collection. Easy enough. Or is it? What if you have 5,000 custom Collections in your site environment? You might get a little tired of having to touch 4,999 Collections to set permissions.

You might assume that you could do something like this to save time:

  1. Create a group named “CM Collection Admins”
  2. Create a group named “CM Collection Super Admins”
  3. Grant “Modify” Class rights to all Collections for “CM Collection Admins”
  4. Grant “Read” Instance rights to Collection “Special” for “CM Collection Admins”
SCCM 2007 Object Class Security Right Properties

SCCM 2007 Object Class Security Right Properties

If you expected the layering of rights to result in least-privileged access (e.g. Modify + Read = Read) you would be incorrect. Most-privilege wins out in this case. So, this approach doesn’t really work.

As you might expect, there are no Instance rights available on a base object for a given class, such as the root Collections object (see figure 4), or Packages, and so on.

SCCM 2007 Collections Class Rights

SCCM 2007 Collections Class Rights

There’s just no Deny Right ^

How about granting “Modify” Class rights to all Collections for “CM Collection Admins”, but then granting “Deny Read” Instance rights on the “Special” Collection? That would be pretty useful actually, but unfortunately, SCCM 2007 doesn’t offer such a feature. Unlike the infamous NTFS and Group Policy security models, there is no “Deny” option on Class or Instance rights within Configuration Manager 2007.

Another option would be to use a parent/sub-collection model, whereby you grant “Create” instance permissions on all of the Collections (e.g. “all instances”) to the group “CM Collection Admins”. Create a root-level Collection, such as “All Teams”, and grant “Read” and “Modify” to “CM Collection Admins” to allow members to create sub-Collections beneath it. Then create a separate root-level Collection, such as “Admin Collections”, and grant “Administer” or “Read” and “Modify” to the “CM Collection Super Admins” group. Have I lost you yet?

There is one drawback to this model however: When it comes time to migrate to SCCM 2012, you won’t be able to maintain sub-collections since the Collections framework model is different: there are no longer “sub-collections” in SCCM 2012.

SCCM 2012 RBAC ^

There is! It’s called Role-Based Administration, and it’s new to SCCM 2012. Instead of a monolithic “class” and “instance” model, Role-Based Access Control (RBAC) decouples the securable items from the things requesting access to them. In some respects, it brings the Active Directory Users and Groups security model inside of Configuration Manager.

In Part 2 of this article I’m going to explore the new RBAC features and compare them to the classic security features to see just how much has been improved upon with Configuration Manager 2012.

0 Comments

Leave a reply

Your email address will not be published.

*

© 4sysops 2006 - 2022

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account