Fundamentals of role-based administration for Configuration Manager

Applies to: Configuration Manager (current branch)

With Configuration Manager, you use role-based administration to secure the access that administrative users need to use Configuration Manager. You also secure access to the objects that you manage, like collections, deployments, and sites.

The role-based administration model centrally defines and manages hierarchy-wide security access. This model is for all sites and site settings by using the following items:

• Security roles are assigned to administrative users to give them permission to Configuration Manager objects. For example, permission to create or change client settings.

• Security scopes are used to group specific instances of objects that an administrative user is responsible to manage. For example, an application that installs the Configuration Manager console.

• Collections are used to specify groups of users and devices that the administrative user can manage in Configuration Manager.

With the combination of roles, scopes, and collections, you segregate the administrative assignments that meet your organization's requirements. Used together, they define the administrative scope of a user. This administrative scope controls the objects that an administrative user views in the Configuration Manager console, and it controls the permissions that a user has on those objects.

The following items are benefits of role-based administration in Configuration Manager:

• Sites aren't used as administrative boundaries. In other words, don't expand a standalone primary site to a hierarchy with a central administration site to separate administrative users.

• You create administrative users for a hierarchy and only need to assign security to them one time.

• All security assignments are replicated and available throughout the hierarchy. Role-based administration configurations replicate to each site in the hierarchy as global data, and then are applied to all administrative connections.

  Important

  Intersite replication delays can prevent a site from receiving changes for role-based administration. For more information about how to monitor intersite database replication, see Data transfers between sites.

• There are built-in security roles that are used to assign the typical administration tasks. Create your own custom security roles to support your specific business requirements.

• Administrative users see only the objects that they have permissions to manage.

• You can audit administrative security actions.

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 do their administrative tasks. These security permissions define the actions that an administrative user can do and the permissions that are granted for particular object types. As a security best practice, assign the security roles that provide the least permissions that are required for the task.

Configuration Manager has several built-in security roles to support typical groupings of administrative tasks. You can create your own custom security roles to support your specific business requirements.

The following table summarizes all of the built-in roles:

You can't modify the built-in security roles, other than add administrative users. 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've exported from another hierarchy like a lab environment. For more information, see Configure role-based administration.

Review the security roles and their permissions to determine whether you'll use the built-in security roles, or whether you have to create your own custom security roles.

Each security role has specific permissions for different object types. For example, the application author role has the following permissions for applications:

• Approve
• Create
• Delete
• Modify
• Modify folder
• Move object
• Read
• Run report
• Set security scope

This role also has permissions for other objects.

For more information on how to view the permissions for a role, or change the permissions for a custom role, see Configure role-based administration.

Use this process to plan for Configuration Manager security roles in your environment:

1. Identify the tasks that administrative users need to do in Configuration Manager. These tasks might relate to one or more groups of management tasks. For example, deploying operating systems and settings for compliance.

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

3. If some of the administrative users do the tasks of multiple roles, assign the users to the multiple roles. Don't create a custom role that combines the permissions.

4. If the tasks that you identified don't map to the built-in security roles, create and test custom roles.

For more information, see Create custom security roles and Configure security roles.

Collections specify the users and devices that an administrative user can view or manage. For example, to deploy an application to a device, the administrative user needs to be in a security role that grants access to a collection that contains the device.

For more information about collections, see Introduction to collections.

Before you configure role-based administration, decide whether you have 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.

For more information, see Configure collections to manage security.

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

• All: Grants access to all scopes. You can't assign objects to this security scope.

• Default: This scope is used for all objects by default. When you install Configuration Manager, it assigns all objects to this security scope.

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

• Alert subscriptions
• Applications and application groups
• App-V virtual environments
• Boot images
• Boundary groups
• Configuration items and baselines
• Custom client settings
• Distribution points and distribution point groups
• Driver packages
• Endpoint protection policies (all)
• Folders
• Global conditions
• Migration jobs
• OneDrive for Business profiles
• OS images
• OS upgrade packages
• Packages
• Queries
• Remote connection profiles
• Scripts
• Sites
• Software metering rules
• Software update groups
• Software updates packages
• Task sequences
• User data and profiles configuration items
• Windows Update for Business policies

There are also some objects that you can't include in security scopes because they're only secured by security roles. Administrative access to these objects can't be limited to a subset of the available objects. For example, you might have an administrative user who creates boundary groups that are used for a specific site. Because the boundary object doesn't support security scopes, you can't assign this user a security scope that provides access to only the boundaries that might be associated with that site. Because a boundary object can't be associated to a security scope, when you assign a security role that includes access to boundary objects to a user, that user can access every boundary in the hierarchy.

Objects that don't support security scopes include but aren't limited to the following items:

• Active Directory forests
• Administrative users
• Alerts
• Boundaries
• Computer associations
• Default client settings
• Deployment templates
• Device drivers
• Migration site-to-site mappings
• Security roles
• Security scopes
• Site addresses
• Site system roles
• Software updates
• Status messages
• User device affinities

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

• You have a group of administrative users who need to see production applications and not test applications. Create one security scope for production applications and another for test applications.

• One group of administrative users requires Read permission to specific software update groups. Another group of administrative users requires Modify and Delete permissions for other software update groups. Create different security scopes for these software update groups.

For more information, see Configure security scopes for an object.

Configure role-based administration for Configuration Manager