One of the reasons to install multiple primary sites in a System Center Configuration Manager 2007 hierarchy often was due to the fact that Administrative access had to be separated between different departments within a company. Within large companies mostly a Central Primary Site would be installed, not servicing any clients, and under that Central Primary Site, several Primary Child Sites would be installed for each OpCo needing their own administrative boundary within the hierarchy.
With ConfigMgr 2012, this has changed for the better. Because Microsoft wanted to simplify the hierarchy for ConfigMgr 2012, they introduced several techniques to partition a Primary Site for use by multiple administrative departments. I often notice though that I have a hard time to convince people of the fact that for security reasons it’s not necessary anymore to create multiple primary sites within a hierarchy. There are of course reasons to create multiple primary sites and a Central Administration Site (CAS) above them, but they are often “non-technical” or due to scaling.
In ConfigMgr 2007 we used Object Access, where we could give a user or group access to either the entire class of object, like all collections. Or you could give access to only an instance of an object, like the All Windows 7 Computers collection. This was a nightmare to manage though, and quickly became very complex in large implementations. More information can be found in the Classes and Instances for Object Security in Configuration Manager for ConfigMgr 2007 article on Microsoft Technet.
Microsoft introduced several new configuration options in ConfigMgr 2012 in order to manage the security better, like:
- Limiting Collection
- Security Roles
- Security Scopes
- Client Settings
When you create a new collection in ConfigMgr 2012 you have to specify a limiting collection. For example, you can create a collection containing machines which have Adobe Reader version 9 installed by using a WMI Query Language (WQL) query, and provide the All Windows 7 Clients as Limiting Collection. The Collection you just created will present you with all Windows 7 Clients which have Adobe Reader version 9 installed. I will show you later where the limiting collection functionality comes in handy in the security context.
When you install ConfigMgr 2012, some administrative roles are already configured, and if needed you can create your own roles. The following roles are created out of the box:
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).
After installation of ConfigMgr 2012, two security scopes are created which can’t be deleted, the first is the All Security Scope which is an overlapping security scope for all to be created security scopes and the second is the default security scope, which is the security scope which each object gets when it’s created within ConfigMgr 2012. ConfigMgr Administrators can create their own Security Scopes, for example a Security Scope for OpCo1 and a Security Scope for OpCo2. After creating these security scopes, you can “tag” an object, like an application for example for one or more security scopes, allowing you to specify which security role rights should apply.
The Client Settings allow you to specify the client behavior. Client Settings work similar to Group Policy in Active Directory only instead of attaching them to OUs, you deploy them to one or more Collections. You can have several Client Settings within your hierarchy, and in case of multiple client settings being applied you can specify which one wins using priority settings on the Client Settings. The settings with the lowest number win over Client settings with a higher number.
If you want to know more about Role Based Access Control in ConfigMgr 2012 I suggest you read the following blog post by Howard Hoy who works for Microsoft Consultancy Services: Role-Based Administration in System Center 2012 Configuration Manager
The discussed new functionality, when brought together allow you to “partition” your ConfigMgr 2012 environment for use by different administrative organizations within your company. Allowing them to use the ConfigMgr functionalities totally independent from each other, while a central competence department manages the ConfigMgr hierarchy.
This was the introduction, in the next part I will walk you through a scenario which I recently implemented at a customer of mine.
All Articles in this serie: