SCCM 2012 R2 comes up with new security model called . Role Based Access Control is found in many Microsoft products like Exchange 2010 & System Center 2012. With SCCM 2007, One of the reasons to install multiple primary sites often was due to the fact that Administrative access had to be separated between different departments within a company. In large companies mostly a Central Primary Site would be installed, doing nothing, and under that Central Primary Site, several Primary Child Sites would be installed needing their own administrative boundary within the hierarchy. With SCCM 2012 R2, this has changed for the better. Now, rather than deploying a bunch of primary sites just to enable granular administration, you can use SCCM 2012’s new Role Based Access Control function to achieve extremely granular administrative segregation. Not only it restricts what users can do, it limits what users can see when they’re in the console. RBAC hides interface elements based on user profile sothat the user is shown only what is relevant.
Role Based Access Control components
Role based access control in SCCM 2012 is made up of the combination of two distinct administrative elements. -Role -Scope
An SCCM Role identifies what a user is allowed to do. SCCM 2012 R2 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 R2 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.
So basically, when these two items are overlapped, you’re left with a look at a user’s abilities in the SCCM console.
SCCM 2012 R2 – RBAC
As mentioned above, SCCM comes up with 14 predefined security roles, but administrators can create additional roles to meet specific business needs. During the initial installation of SCCM 2012 r2, the administrative account is added to the Full Administrators role. Here’s a look at the list of roles available in SCCM 2012:
Role Role description Application Administrator Grants permissions to perform both the Application Deployment Manager role and the Application Author role. Administrative users who are associated with this role can also manage queries, view site settings, manage collections, and edit settings for user device affinity. Application Author Grants permissions to create, modify, and retire applications. Administrative users who are associated with this role can also manage applications, packages. Application Deployment Manager Grants permissions to deploy applications. Administrative users who are associated with this role can view a list of applications, and they can manage deployments for applications, alerts, templates and packages, and programs. Administrative users who are associated with this role can also view collections and their members, status messages, queries, and conditional delivery rules. Asset Manager Grants permissions to manage the Asset Intelligence SynchronizationPoint, Asset Intelligence reporting classes, software inventory, hardware inventory, and metering rules. Compliance Settings Manager Grants permissions to define and monitor Compliance Settings. Administrative users associated with this role can create, modify, and delete configuration items and baselines. They can also deploy configuration baselines to collections, and initiate compliance evaluation, and initiate remediation for non-compliant computers. Endpoint Protection Manager Grants permissions to define and monitor security policies. Administrative Users who are associated with this role can create, modify and delete Endpoint Protection policies. They can also deploy Endpoint Protection policies to collections, create and modify Alerts and monitor Endpoint Protection status. Full Administrator Grants all permissions in Configuration Manager. The administrative user who first creates a new Configuration Manager installation is associated with this security role, all scopes, andall collections. Infrastructure Administrator Grants permissions to create, delete, and modify the Configuration Manager server infrastructure and to perform migration tasks. Operating System Deployment Manager Grants permissions to create operating system images and deploy them to computers. Administrative users who are associated with this role can manage operating system installation packages and images, task sequences, drivers, boot images, and state migration settings. Operations Administrator Grants permissions for all actions in Configuration Manager except for the permissions that are required to manage security, which includes managing administrative users, security roles, and security scopes. Read-only Analyst Grants permissions to view all Configuration Manager objects. Remote Tools Operator Grants permissions to run and audit the remote administration tools that help users resolve computer issues. Administrative users that are associated with this role can run RemoteControl, Remote Assistance and Remote Desktop from the Configuration Manager console. In addition, they can run the Out of Band Management console and AMT power control options. Security Administrator Grants permissions to add and remove administrative users and to associate administrative users with security roles, collections, and security scopes. Administrative users who are associated with this role can also create, modify, and delete security roles and their assigned security scopes and collections. Software Update Manager Grants permissions to define and deploy software updates. Administrative users who are associated with this role can manage software update groups, deployments, deployment templates, and enable software updates for Network Access Protection (NAP).
As you can see from the table above, these roles all define what users that are members of the role can do. So, how do you control there “where” aspect?
That’s where security scopes come into play. SCCM 2012 ships with two default security scopes:
All. A built-in security scope that contains all securable objects. A Configuration Manager administrator associated with the All security scope will have the permissions of their role for every object in the Configuration Manager environment.
Default. A built-in security scope with which securable objects can be associated.
Neither of these security scopes can be changed or deleted.
Appropriate objects in SCCM 2012 are tagged with security scopes and can be added to new security scopes, where necessary. This is how you can avoid having to create multiple primary sites to form security boundaries.
Isn’t it the easy way for organizations to restrict access to SCCM’s powerful capabilities?
I would definitely recommend to have a look on the below link of Technet site to have more details about it.