A single SCCM 2012 R2 system may be segmented for use by different teams by creating security scopes. This is extremely useful for delegating full rights to project and test teams without risking the deployment of development artefacts to production environments.
A Security Scope for SCCM 2012 R2 initially begins with nothing more than a Scope name. The linking of “securable objects” to a scope occurs on the individual objects and not within the Security Scope node.
With this example a new scope for Project Rhubarb is being created. The goal is to allow an independent, internal development project team the use of the organisational SCCM system for supporting their development machines.
As the project will be creating and deploying applications to test machines, Role Based Administration is used to limit the scope of what can be deployed so the rest of the organisation can’t be affected by potential shenanigans within the development project.
To use the Security Scope, a new collection of project machines has been created.
A user based collection for Project members is also created.
A user collection, machine collection and scope can now be associated with an administrative account for the project. This occurs under the Administration -> Security -> Administrative Users node of the SCCM console.
The “Default” Security Scope will also need to be removed. This occurs in the section stating “Only the instances of objects that are assigned to the specified security scopes and collections”.
The project account must also have the default “All Systems” and “All Users and User Groups” collections removed to restrict its power to the designated scope only
What has been created is a full Admin account for a project “scope” that resides within SCCM. That administrator will also have the ability to modify a user collection and a machine collection (and create collections as subsets of those collections.
Securable Objects
Securable objects within SCCM can be directly associated with a Security Scope. This includes all Applications, Packages, Task Sequences, Boot Images, Operating System Images, Software Update Groups as well as Sites and Distribution Points. All of these objects have the “Set Security Scope” padlock icon available on their toolbar.
Collections however, are not “securable objects” and must be associated directly with the specified admin account. The delegation of rights for collections flows down from the specified Limiting Collection.
With this example the Administrator for project Rhubarb had been explicitly given rights to the collection “Project Rhubarb Machines”. The Administrator will inherit rights to any additional collections that specify the “Project Rhubarb Machines” collection as its Limiting Collection.
When the administrator for Project Rhubarb logs in, not only can they see (and modify) the collections explicitly named by establishing the administrative user, they can also manipulate any collection that uses the authorised collection as its root (or limiting) collection.
The Administrator will have the rights to create new collections that are limited within their limiting collections.
By establishing new scopes within SCCM it’s possible to effectively create test environments that can have their own administrators without risking the accidental deployment of applications to production machines.
- Log in to post comments