by Howard Hoy - MCS Consultant - Portland Oregon
Delegation of administration in SMS/SCCM/ConfigMgr has always been a challenge. I’ve never seen a company where there wasn’t some type of delegated administration when it comes to management of computers, both Desktop and Server. Many groups just don’t trust one another. This lack of trust leads to some very creative delegation solutions. I’ve seen some pretty creative and hard to support implementations. Usually these solutions are developed internally that start off small get adopted as the way of doing business. Thankfully with System Center 2012 Configuration Manager a new feature called Role-Based Administration (RBA) is included to make it easier to delegate and effectively permission administrative tasks.
First I would like to define “Delegation” and what that really means. The Bing dictionary list delegation as:
“condition of being given responsibility: the condition of being given to somebody else as a duty or responsibility”
Delegations that I normally encounter are in environments which have separate Desktop and Server support teams. Each team manages their assets with different standards, governance and processes that almost always are incompatible. “One Console to Rule Them All” is generally the desire from those who own the corporate Microsoft spending points. I mean, that really makes logical sense right? However, throw logic out the window because that is not reality. Groups will go at great lengths to ensure that they are the only administrators capable of inflicting damage via a management platform. We’ve all read about the horror stories from misguided advertisements that cause many support people to be up all night fixing the issues..
One creative implementation that comes to mind while thinking about RBA was a hard core support team from [insert your favorite company] that had responsibility for assets across the globe. They had a massive amount of AD Security groups, DCOM, NTFS Permissions and custom MMC’s to lock out admins to a very granular level. They spent a ton of time supporting and fixing their delegated solution. The increased support for creative solution consumed a lot of their time. Nobody was thinking into the future about supporting their creative solution, rather they were more focused on just solving their immediate problem. Furthermore, turnover causes knowledge loss which can make supporting these creative solutions a nightmare.
Now System Center 2012 Configuration Manager and RBA enter the picture. This is an excellent way to provide a level of delegation of duties for a management platform across all Windows (yes there are others) assets. Is it an answer to all those creative and hard to support delegation ideas? No it is not! For example, you could not provide a role for an admin to not see a particular application, yet still have the ability to deploy it within the console. Yes, I’ve been asked that before. RBA is the ability to apply a strict set of governance and delegation with permissions for logically grouped functions.
I use the following when consulting with my clients about RBA:
RBA provides Configuration Manager 2012 Administrators with a security model that provides the ability to assign and manage administrative permissions - Delegation. RBA is accomplished by using Security Roles, Security Scopes and Collections in Configuration Manager 2012. This controls Who, How, What, Which and Where Administrative tasks are performed. The Configuration Manager console further simplifies this process by showing ONLY a streamlined view that is customized to a given Role. This is sometimes referred to as “The Show Me” console.
This is a simplified logical design diagram which layers the key concepts in RBA:
Configuration Manager Console Layer - Who
Any person who requires Administrative/Management functions within Configuration Manager 2012
Configuration Manager 2012 is managed from a console application which groups administrative tasks into logical workspaces. They are as follows:
The console application can be distributed to the administrator’s workstations so long as they have network access. Please see the Appendix for the Operating System support and Network Port requirements.
Note that an Administrator will only see the objects that they are allowed to see. The following layer sections describe how RBA is accomplished.
Configuration Manager Site Layer – How
The Configuration Manager Site Layer consists of the infrastructure necessary to operate a functional System Center 2012 Configuration Manager environment delivering the RBA capabilities. Since this document focuses on RBA, no more details regarding the requirements for a functional environment are covered. For that you can read TechNet.
Configuration Manager Security Role Layer – What
Objects and Permissions (operations)
In Configuration Manager 2012, Security Roles are used to collectively group objects and permissions (operations) for assignment to an Administrator. Instead of an individual permission set on a single instance of object, the Security Role provides a single Role assignment to an administrator; reducing the overall complexity with permission management. An “object” in the Security Role is something that you want to manage access to and “permission” is the operational functions, such as Read, Modify and Delete.
For example you might have a requirement to create Roles for Server and Workstation administrators who should be limited to managing Configuration Manager Client Agent settings on their targeted assets. To solve this requirement a Role would be created and permissions could be assigned (see Security Scopes in the next section).
By default any Administrator assigned this Role would be able to change the settings on both the Server and Workstations. To limit the permissions specific Security Scopes are required to be configured. That will be covered in the next section.
Included are default built-in roles to cover some basic management separation:
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.
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.
Grants permissions to manage the Asset Intelligence Synchronization Point, 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.
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, and all collections.
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.
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.
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 Remote Control, 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.
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).
These roles can be copied and customized to fit many different sets of Role requirements.
Configuration Manager Security Scope Layer - Which
Specific permissions to specific instances
A Security Scope contains permissions to specific Configuration Manager instances. Unlike the Security Role, which grants rights at a class level such as “Modify”, a Security Scope is granular and defines which permission apply within an specific instance. Collectively, these instance permissions are assigned to a Security Scope and is used to limit administrative access to specific secured objects.
For example let’s review our Security Scope Roles defined in the previous section:
Each type, Server and Workstation Administrator must have the ability to manage specific Configuration Manager Agent Client settings for the targeted assets and would be added to the Client Setting Role.
To “limit” the administrator access two Security Scopes are defined:
In addition two Collections are defined and contain the targeted Assets:
Next the All Servers client agent settings are assigned to the Server Assets Security Scope and the All Desktops are assigned Workstation Assets Security Scope.
Finally the new Security Scopes are assigned to the applicable administrators. This process would prevent a Desktop Administrator from changing the client settings for any asset in the Server Collection. The opposite applies to the Server Administrator.
Additional Scopes and Collections can be generated to create very granular Security Scopes. For example a Security Scope could limit a Server Administrator to a specific set of assets and only allow Application Management.
There is a default scope that is generated during the installation of Configuration Manager 2012. All objects (if applicable) must have a Security Scope assigned. It is important to note that this default security scopes does not follow new objects. Any new object has a scope that is based upon the administrator’s security scope which is creating the new object.
Configuration Manager Collection Layer - Where
Collections of assets
A collection is group of resources that can be managed. In Configuration Manager 2012 there are two types of collections, Device and User. A Device Collection is a group of devices and a User Collection contains users. Collections support the ability to “Include” or “Exclude” resources in other Collections. For example a collection All Desktops could be “Include” all devices in the All Systems collection and have an “Exclude” for any device in the All Servers Collection. This would create a collection with just all Workstations.
Scenarios that you might have:
Here are some links for more information:
and one of my favorites:
Nice! Thanks for the consolidated information.
Thanks for this nice article
Elegant, Easy, To the point.
Thank you very much!
Thanks, One of the best written on the topic, What would you suggest for an international, politically charged environment?
This doesnt really help much. I need a custom "remote support user" RBA created for user. This user can only see workstations, users, primary device associated to primary users, and of course remote support rights from within client settings.
Mayson, did you get a role that does what you are looking for becuase I'm looking for exactly the same. Seems bizarre the Remote Tools Operator can't find the primary device for a user.
What wouldn't you just have two Admin users/groups (workstationAdmins and serverAdmins) and then assign them to the Client Agent Role giving each admin group a security scope based purely on the All Desktops and All Server collections with no need to create
a scope whatsoever?
Also you say "the All Servers client agent settings are assigned to the Server Assets Security Scope and the All Desktops are assigned Workstation Assets Security Scope". How? I can't see any way to assign a Security Role to a Security Scope. I can see how
to assign an instance of an object to Security Scope though.