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:
- 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.
- Map these administrative tasks to one or more of the built-in
security roles.
- 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.
- 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.