Planning for Security in Configuration Manager 2012

Updated: March 15, 2011

Applies To: System Center Configuration Manager 2012, System Center Data Protection Manager 2010

Use the following information to help you plan for security in Microsoft System Center Configuration Manager 2012.

Planning for Role-Based Administration

Role-based administration allows you to design and implement administrative security for the Configuration Manager 2012 hierarchy by using any or all of the following:

  • Security roles

  • Collections

  • Security scopes

Planning for Security Roles

Use security roles to grant security permissions to administrative users. Security roles are groups of security permissions that you assign to administrative users so that they can perform their administrative tasks. These security permissions define the administrative actions that an administrative user can perform and the permissions that are granted for particular object types. As a security best practice, assign the security roles that provide least privileges.

Configuration Manager 2012 has several built-in security roles to support typical groupings of administrative tasks and you can create your own custom security roles to support your specific business requirements. Examples of the built-in security roles:

  • Full Administrator: This security role grants all permissions in Configuration Manager.

  • Asset Analyst: This security role allows administrative users to view data collected by using Asset Intelligence, software inventory, hardware inventory and software metering. Administrative users can create metering rules and Asset Intelligence categories, families, and labels.

  • Software Update Manager: This security role grants permissions to define and deploy software updates. Administrative users who are associated with this role can create collections, software update groups, deployments, templates, and enable software updates for Network Access Protection (NAP).

Each security role has specific permissions for different object types. For example, the Application Administrator security role has the following permissions for applications: Approve, Create, Delete, Modify, Modify Folders, Move Objects, Read/Deploy, Set Security Scope. You cannot change the permissions for the built-in security roles but you can copy the role, make changes, and then save these changes as a new custom security role. You can also import security roles that you have exported from another hierarchy (for example, from a test network). Review the security roles and their permissions to determine whether you will use the built-in security roles or you need to create your own custom security roles.

Use the following steps to help you plan for security roles:

  1. Identify the tasks that the administrative users will perform in Configuration Manager 2012. These tasks might relate to one or more groups of management tasks, such as deploying applications and packages, deploying operating systems and settings for compliance, configuring sites and security, auditing, remotely controlling computers, and collecting inventory data.

  2. Map these administrative tasks to one or more of the built-in security roles.

  3. If some of the administrative users will perform the tasks of multiple security roles, assign the multiple security roles to these administrative users rather than creating a new security role that combines the tasks.

  4. If the tasks that you identified do not map to the built-in security roles, create and test new security roles.

Be careful when you assign multiple security roles to a user or group and each security role is assigned to different collections and security scopes. For example, you assign the following two security roles to an administrative user:

  • The Application Administrator security role, which allows her to author and deploy applications and packages to a collection of test computers.

  • The Software Update Manager security role, which allows her to deploy software updates to all computers in the company.

The result of these security role assignments is that this administrative user can deploy to any collection in the company, and she can read and deploy all applications from the test collection and security scope. For example, she can deploy any test application to all computers in the company, which might not be your intention.

To avoid this scenario, use multiple Windows accounts for the administrative user. Configure each security role to use a separate Windows account and instruct the administrative user to log on with the appropriate account before they perform administrative tasks.

Planning for Collections

Collections specify the user and computer resources that an administrative user can view or manage. For example, for an administrative user to deploy applications or to run remote control, they must be assigned to a security role that grants access to a collection that contains these resources. You can select collections of users or devices.

For more information about collections, see Introduction to Collections in Configuration Manager 2012.

Before you configure role-based administration, check whether you need to create new collections for any of the following reasons:

  • Functional organization. For example, separate collections of servers and workstations.

  • Geographic alignment. For example, separate collections for North America and Europe.

  • Security requirements and business processes. For example, separate collections for production and test computers.

  • Organization alignment. For example, separate collections for each business unit.

Planning for Security Scopes

Use security scopes to provide administrative users with access to securable objects. Security scopes are a named set of securable objects that are assigned to administrator users as a group. All securable objects must be assigned to one or more security scopes. Configuration Manager has two built-in security scopes:

  • All: This built-in security scope grants access to all scopes. You cannot assign objects to this security scope.

  • Default: This built-in security scope is used for all objects, by default. When you first install Configuration Manager 2012, all objects are assigned to this security scope.

If you want to restrict the objects that administrative users can see and manage, you must create and use your own custom security scopes. Security scopes do not support a hierarchical structure and cannot be nested. Security scopes can contain one or more object types, which include the following:

  • Applications

  • Packages

  • Boot images

  • Sites

  • Custom client settings

  • Distribution points and distribution point groups

  • Software update groups

There are also some objects that you cannot include in security scopes. Instead, they are secured by security roles. These objects include the following:

  • Administrative users

  • Security roles

  • Security scopes

  • Default client settings

  • Boundaries

  • Exchange Server connector

  • Site addresses

  • Active Directory forests

  • Site system roles

Create security scopes when you need to limit access to separate instances of objects. For example:

  • Administrative uses who are assigned to the Production Desktops collection must be able to see production applications and not test applications. Create one security scope for production applications and another for the test applications.

  • Administrative users require different access for some instances for an object type. For example, one group of administrative users require Read permission to specific software update groups, and another group of administrative users require Modify and Delete permissions for other software update groups. Create different security scopes for these software update groups.

  • You want to ensure that some securable objects can only be viewed or managed by specific administrative users. For example, only the Domain Administrators group can configure custom client settings. Create a security scope for custom client settings.

See Also