Partager via

ConfigMgr Admin permissions

  • Article

Setting up different levels of Admin UI permissions for SMS or SCCM is not always straight forward and obvious.  It is, however, fairly flexible and granular.  I’m not going to cover how to get console connectivity, as I think that is well covered elsewhere on the internet.  Things like membership in the SMS Admins group is assumed to already be in place.  Instead I’m going to focus on a few scenarios which, hopefully, will help folks build out their security model in the UI itself.

One quick point of clarification before we dive into this.  Class vs. instance level permissions.  Class level permissions are set at the top level of objects.  Classes are things like Collections, Packages, Queries, etc.  Instances of those classes can have their own permissions in most (but not all) cases.  So “All Systems” is an instance, as is the “Office 2010” package.  Class level permissions flow down to instances of those classes.  However, instance level permissions do NOT flow down to instances beneath them.  As an example use the following collection structure:

Collections
    All Systems
    Department1
        Laptops
        Desktops

Granting a user class level permissions to “Collections” will give that same permission to everything else.  Giving a user a permission to the “Department1” instance will not give them any permissions to “Laptops” or “Desktops”.

The typical groups I see companies want to utilize when setting up permissions are:  1) Uber-admins, 2) Department admins, and 3) Helpdesk operators.  Uber-admins have full permissions to everything, and are the easiest to configure.  When SMS or ConfigMgr is installed the uber-admin permissions are granted to the account that did the install.  They are also granted to the local system account.  You can clone either of these accounts to grant uber-permissions to another person or group.  I usually clone the system account simply because it has all the class level rights but does not have the clutter of instance level rights that would occur from a user account who has been active in the MMC console.

Helpdesk operators is the next easiest to setup.  What helpdesk folks may use ConfigMgr for tends to very.  For my example I will assume they will need to look at machine inventory information, put machines in pre-created collections to get software delivered to them (pre-advertised), and remote tools access to assist the end users.  The first step is permissions to collections.  Being the helpdesk I’m making the assumption that they need to assist all managed machines so we would want to grant them class level permissions.  We would grant them Read (to see the collections), Read Resource (to see details of those machines, such as inventory), Use Remote Tools (to remotely connect to machines), Modify (to allow adding machines to collections) and perhaps View collected files (to see anything brought back from software inventory).  At a minimum, that is all that is needed.  Perms to queries might let them do a little more self investigation of issues, but most companies I work with escalate that kind of activity to a higher support tier.

Now for the hard, yet common, request.  You have a company with several departments, each wanting a level of autonomy from each other.  The root of all this is to allow each group to only touch their own machines and not the machines of others.  From there you want to grant perms to shared objects or keep them separated carefully.  Shared objects would be things like packages, advertisements, patch deployments, etc.  For my example I will go for total isolation of each department, but allow each department to do their own software and patch deployments.

Step1 – Collections.  You want to start by creating a collection for each department.  In that collection make a query of the machines that belong to that department (hopefully based on OU membership, machine naming convention, or something similar).  At the collection class level you grant each dept. Create, Delegate, and Advertise.  Yes, this means they can create collections anywhere.  You have to instruct them to only create under their dept. specific collection to avoid confusion.  To avoid this, remove the Read permission so they can only see and grant on the collections you allow.  On their dept. specific collection grant instance permissions of Read, Read Resource, Advertise, Modify, Modify Resource, Modify Collection Settings, view collected files, and Use Remote Tools.  Any collections the dept. admins create they will have full control over.  There is a catch, which is that only they will have permissions on collections they create therefor they will need to get in the habit of granting perms to their admin group every time they create a new collection.

Step2 – SWDist.  We can’t keep people from different depts. from seeing each other’s packages, but we can isolate which ones they can use.  Note that you can use folders to visually organize things, but folders are simply UI display conveniences and do not carry or isolate permissions in any way.  At the package class level grant Read, Distribute, Delegate and Create.  Now when a user creates a package they will get full rights to use and distribute it, but only those packages they create (again, they need to grant perms to their dept. group).  For advertisements grant Read, Create, and Delegate.  This will unfortunately let dept. 1 advertise out packages made by dept. 2, but only to dept. 1 machines at the risk of dept. 2 admins changing something unexpectedly.

Step 3 – Site.  Up to now we have kept folks out of all the site settings.  Unfortunately, they need to get access to those settings to enumerate the distribution points for software distribution.  This means that at the site level we need to grant Read permission to each dept. group.

 

OS deployments, patch management, etc... these things have similar permission structures that need setup.  I can put those in a future blog post if folks express an interest.  If you take this, try it in your environment, and do some testing you may need to fine tune things to get your desired results.  Hopefully this will help many folks get started and help you understand a little better how the security model works.  If you find I messed up anything let me know and I will clarify or correct for the benefit of others.

Comments

  • Anonymous
    January 01, 2003
    Stephen - I make no promises, but I will put that on my list of things to add to this blog and see when I can get it written up.

  • Anonymous
    January 01, 2003
    I'm excited about the new Role Based Access Security (RBAC) model coming in SCCM 2012.  It should make this kind of permissions management MUCH easier going forward. One of my customers had the same frustration as you do.  There is something floating around the internet that sets up a custom SQL trigger to grant additional permissions when a collection is created, but we steered away from it since direct manipulation of the SQL DB like that puts folks into an unsupported state should related problems come up in the future.

  • Anonymous
    February 22, 2011
    Thanks for your guide but any which way you look at it delegating rights in SCCM is a pain. I’ve tried to set the permissions for departmental admins but they don’t get rights to the collections they create. When going through the New Collection Wizard, the security page shows they have full instance rights (all boxes ticked but with padlock icons next to them). However, when I look at properties after the collection has been created, they only have Read, Modify & Delete – all other boxes unticked and padlocks next to them. They do not have full rights and cannot modify them. Any idea why it might behave in this way? BTW it’s 2007 R3 Thanks

  • Anonymous
    February 24, 2011
    Thanks for your response; I hope SCCM 2012 lives up to the hype. I haven't come across the SQL trigger fix and wouldn't be keen on trying it anyway. I guess we'll just have to make do with what we've got for now.

  • Anonymous
    July 23, 2011
    Mike, This is a fantastic post. I'm struggling with trying to tackle this very subject. I'm also searching for a way to allow desktop support folks access to OSD w/o going to far. Can you post on this scenario as well? Thanks! Stephen