Поділитися через

  • Стаття

Planning for Security in Configuration Manager

 

Updated: May 14, 2015

Applies To: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1

Note

This topic appears in the Site Administration for System Center 2012 Configuration Manager guide and in the Security and Privacy for System Center 2012 Configuration Manager guide.

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

  • Planning for Certificates (Self-Signed and PKI)

    • Planning for PKI Certificate Revocation

    • Planning for the PKI Trusted Root Certificates and the Certificate Issuers List

    • Planning for PKI Client Certificate Selection

    • Planning a Transition Strategy for PKI Certificates and Internet-Based Client Management

  • Planning for the Trusted Root Key

  • Planning for Signing and Encryption

  • Planning for Role-Based Administration

In addition to these sections, see Security and Privacy for Site Administration in Configuration Manager.

For additional information about how Configuration Manager uses certificates and cryptographic controls, see Technical Reference for Cryptographic Controls Used in Configuration Manager.

Planning for Certificates (Self-Signed and PKI)

Configuration Manager uses a combination of self-signed certificates and public key infrastructure (PKI) certificates.

As a security best practice, use PKI certificates whenever possible. For more information about the PKI certificate requirements, see PKI Certificate Requirements for Configuration Manager. When Configuration Manager requests the PKI certificates, such as during enrollment for mobile devices and AMT provisioning, you must use Active Directory Domain Services and an enterprise certification authority. For all other PKI certificates, you must deploy and manage them independently from Configuration Manager.

PKI certificates are also required when client computers connect to Internet-based site systems, and they are recommended to be used when clients connect to site systems that run Internet Information Services (IIS). For more information about client communication, see Planning for Client Communication in Configuration Manager.

When you use a PKI, you can also use IPsec to help secure the server-to-server communication between site systems in a site and between sites, and for any other scenario when you transfer data between computers. You must configure and implement IPsec independently from Configuration Manager.

Configuration Manager can automatically generate self-signed certificates when PKI certificates are not available, and some certificates in Configuration Manager are always self-signed. In most cases, Configuration Manager automatically manages the self-signed certificates, and you do not have to take additional action. One possible exception is the site server signing certificate. The site server signing certificate is always self-signed, and it ensures that the client policies that clients download from the management point were sent from the site server and were not tampered with.

Planning for the Site Server Signing Certificate (Self-Signed)

Clients can securely obtain a copy of the site server signing certificate from Active Directory Domain Services and from client push installation. If clients cannot obtain a copy of the site server signing certificate by using one of these mechanisms, as a security best practice, install a copy of the site server signing certificate when you install the client. This is especially important if the client’s first communication with the site is from the Internet, because the management point is connected to an untrusted network and therefore, vulnerable to attack. If you do not take this additional step, clients automatically download a copy of the site server signing certificate from the management point.

Scenarios when clients cannot securely obtain a copy of the site server certificate include the following:

  • You do not install the client by using client push, and any of the following conditions is true:

    • The Active Directory schema is not extended for Configuration Manager.

    • The client’s site is not published to Active Directory Domain Services.

    • The client is from an untrusted forest or a workgroup.

  • You install the client when it is on the Internet.

Use the following procedure to install clients together with a copy of the site server signing certificate.

To install clients with a copy of the site server signing certificate

  1. Locate the site server signing certificate on the client’s primary site server. The certificate is stored in the SMS certificate store and has the Subject name Site Server and the friendly name Site Server Signing Certificate.

  2. Export the certificate without the private key, store the file securely, and only access it from a secured channel (for example, by using SMB signing or IPsec).

  3. Install the client by using the Client.msi property SMSSIGNCERT= <Full path and file name> with CCMSetup.exe.

Planning for PKI Certificate Revocation

When you use PKI certificates with Configuration Manager, plan for how and whether clients and servers will use a certificate revocation list (CRL) to verify the certificate on the connecting computer. The certificate revocation list (CRL) is a file that is created and signed by a certification authority (CA) and contains a list of certificates that it has issued, but revoked. Certificates can be revoked by a CA administrator, for example, if an issued certificate is known or suspected to be compromised.

Important

Because the location of the CRL is added to a certificate when it is issued by a CA, ensure that you plan for the CRL before you deploy any PKI certificates that Configuration Manager will use.

By default, IIS always checks the CRL for client certificates, and you cannot change this configuration in Configuration Manager. By default, Configuration Manager clients always check the CRL for site systems; however, you can disable this setting by specifying a site property and by specifying a CCMSetup property. When you manage Intel AMT-based computers out of band, you can also enable CRL checking for the out of band service point and for computers that run the Out of Band Management console.

If computers use certificate revocation checking but they cannot locate the CRL, they behave as if all certificates in the certification chain are revoked because their absence from the list cannot be verified. In this scenario, all connections that require certificates and use a CRL fail.

Checking the CRL every time that a certificate is used offers more security against using a certificate that has been revoked, but it introduces a connection delay and additional processing on the client. You are more likely to require this additional security check when clients are on the Internet or on an untrusted network.

Consult your PKI administrators before you decide whether Configuration Manager clients must check the CRL, and then consider keeping this option enabled in Configuration Manager when both of the following conditions are true:

  • Your PKI infrastructure supports a CRL, and it is published where all Configuration Manager clients can locate it. Remember that this might include clients on the Internet if you are using Internet-based client management, and clients in untrusted forests.

  • The requirement to check the CRL for each connection to a site system configured to use a PKI certificate is larger than the requirement for faster connections and efficient processing on the client, and is also larger than the risk of clients failing to connect to servers if they cannot locate the CRL.

Planning for the PKI Trusted Root Certificates and the Certificate Issuers List

If your IIS site systems use PKI client certificates for client authentication over HTTP or for client authentication and encryption over HTTPS, you might have to import root CA certificates as a site property. The two scenarios are as follows:

  • You deploy operating systems by using Configuration Manager, and the management points only accept HTTPS client connections.

  • You use PKI client certificates that do not chain to a root certification authority (CA) certificate that is trusted by management points.

    Note

    When you issue client PKI certificates from the same CA hierarchy that issues the server certificates that you use for management points, you do not have to specify this root CA certificate. However, if you use multiple CA hierarchies and you are not sure whether they trust each other, import the root CA for the clients’ CA hierarchy.

If you must import root CA certificates for Configuration Manager, export them from the issuing CA or from the client computer. If you export the certificate from the issuing CA that is also the root CA, ensure that the private key is not exported. Store the exported certificate file in a secured location to prevent tampering. You must be able to access the file when you configure the site, so that if you access the file over the network, ensure that the communication is protected from tampering by using SMB signing or IPsec.

If any of the root CA certificates that you import are renewed, you must import the renewed certificates.

These imported root CA certificates and the root CA certificate of each management point create the certificate issuers list that Configuration Manager computers use in the following ways:

  • When clients connect to management points, the management point verifies that the client certificate chains to a trusted root certificate in the site’s certificate issuers list. If it does not, the certificate is rejected, and the PKI connection fails.

  • When clients select a PKI certificate, if they have a certificate issuers list, they select a certificate that chains to a trusted root certificate in the certificate issuers list. If there is no match, the client does not select a PKI certificate. For more information about the client certificate process, see the Planning for PKI Client Certificate Selection section in this topic.

Independently from the site configuration, you might also have to import a root CA certificate when you enroll mobile devices or Mac computers, and when you provision Intel AMT-based computers for wireless networks.

Planning for PKI Client Certificate Selection

If your IIS site systems will use PKI client certificates for client authentication over HTTP or for client authentication and encryption over HTTPS, plan for how Windows-based clients will select the certificate to use for Configuration Manager.

Note

Not all devices support a certificate selection method and instead, automatically select the first certificate that fulfills the certificate requirements. For example, clients on Mac computers, and mobile devices do not support a certificate selection method.

In many cases, the default configuration and behavior will be sufficient. The Configuration Manager client on Windows-based computers filters multiple certificates by using the following criteria:

  1. The certificate issuers list: The certificate chains to a root CA that is trusted by the management point.

  2. The certificate is in the default certificate store of Personal.

  3. The certificate is valid, not revoked, and not expired. The validity check includes verifying that the private key is accessible and that the certificate is not created by using a version 3 certificate template, which is not compatible with Configuration Manager.

  4. The certificate has client authentication capability, or it is issued to the computer name.

  5. The certificate has the longest validity period.

Clients can be configured to use the certificate issuers list by using the following mechanisms:

  • Is it published as Configuration Manager site information to Active Directory Domain Services.

  • Clients are installed by using client push.

  • Clients download it from the management point after they are successfully assigned to their site.

  • It is specified during client installation, as a CCMSetup client.msi property of CCMCERTISSUERS.

If clients do not have the certificate issuers list when they are first installed and are not yet assigned to the site, they skip this check. When they do have the certificate issuers list and do not have a PKI certificate that chains to a trusted root certificate in the certificate issuers list, certificate selection fails, and clients do not continue with the other certificate selection criteria.

In most cases, the Configuration Manager client correctly identifies a unique and appropriate PKI certificate to use. However, when this is not the case, instead of selecting the certificate based on the client authentication capability, you can configure two alternative selection methods:

  • A partial string match on the client certificate Subject name. This is a case-insensitive match that is appropriate if you are using the fully qualified domain name (FQDN) of a computer in the subject field and want the certificate selection to be based on the domain suffix, for example contoso.com. However, you can use this selection method to identify any string of sequential characters in the certificate Subject name that differentiate the certificate from others in the client certificate store.

    Note

    You cannot use the partial string match with the Subject Alternative Name (SAN) as a site setting. Although you can specify a partial string match for the SAN by using CCMSetup, it will be overwritten by the site properties in the following scenarios:

    • Clients retrieve site information that is published to Active Directory Domain Services.

    • Clients are installed by using client push installation.

    Use a partial string match in the SAN only when you install clients manually, and when they do not retrieve site information from Active Directory Domain Services. For example, these conditions apply to Internet-only clients.

  • A match on the client certificate Subject name attribute values or the Subject Alternative Name (SAN) attribute values. This is a case-sensitive match that is appropriate if you are using an X500 distinguished name or equivalent OIDs (Object Identifiers) in compliance with RFC 3280, and you want the certificate selection to be based on the attribute values. You can specify only the attributes and their values that you require to uniquely identify or validate the certificate and differentiate the certificate from others in the certificate store.

The following table shows the attribute values that Configuration Manager supports for the client certificate selection criteria.

OID Attribute

Distinguished name attribute

Attribute definition

0.9.2342.19200300.100.1.25

DC

Domain component

1.2.840.113549.1.9.1

E or E-mail

E-mail address

2.5.4.3

CN

Common name

2.5.4.4

SN

Subject name

2.5.4.5

SERIALNUMBER

Serial number

2.5.4.6

C

Country code

2.5.4.7

L

Locality

2.5.4.8

S or ST

State or province name

2.5.4.9

STREET

Street address

2.5.4.10

O

Organization name

2.5.4.11

OU

Organizational unit

2.5.4.12

T or Title

Title

2.5.4.42

G or GN or GivenName

Given name

2.5.4.43

I or Initials

Initials

2.5.29.17

(no value)

Subject Alternative Name

If more than one appropriate certificate is located after the selection criteria is applied, you can override the default configuration to select the certificate with the longest validity period and instead, specify that no certificate is selected. In this scenario, the client will not be able to communicate with IIS site systems by using a PKI certificate. The client sends an error message to its assigned fallback status point to alert you to the certificate selection failure so that you can modify or refine your certificate selection criteria. The client behavior then depends on whether the failed connection was over HTTPS or HTTP:

  • If the failed connection was over HTTPS: The client tries to make a connection over HTTP and uses the client self-signed certificate.

  • If the failed connection was over HTTP: The client tries to make another connection over HTTP by using the self-signed client certificate.

To help identify a unique PKI client certificate, you can also specify a custom store, other than the default of Personal in the Computer store. However, you must create this store independently from Configuration Manager and must be able to deploy certificates to this custom store and renew them before the validity period expires.

For information about how to configure the settings for client certificates, see the Configure Settings for Client PKI Certificates section in the Configuring Security for Configuration Manager topic.

Planning a Transition Strategy for PKI Certificates and Internet-Based Client Management

The flexible configuration options in Configuration Manager let you gradually transition clients and the site to use PKI certificates to help secure client endpoints. PKI certificates provide better security and enable clients to be managed when they are on the Internet.

Because of the number of configuration options and choices in Configuration Manager, there is no single way to transition a site so that all clients use HTTPS connections. However, you can follow these steps as guidance:

  1. Install the Configuration Manager site and configure it so that site systems accept client connections over HTTPS and HTTP.

  2. Configure the Client Computer Communication tab in the site properties so that the Site System Settings is HTTP or HTTPS, and select the Use PKI client certificate (client authentication capability) when available check box. Configure any other settings from this tab that you require. For more information, see the Configure Settings for Client PKI Certificates section in the Configuring Security for Configuration Manager topic.

  3. Pilot a PKI rollout for client certificates. For an example deployment, see the Deploying the Client Certificate for Windows Computers section in the Step-by-Step Example Deployment of the PKI Certificates for Configuration Manager: Windows Server 2008 Certification Authority topic.

  4. Install clients by using the client push installation method. For more information, see the How to Install Configuration Manager Clients by Using Client Push section in the How to Install Clients on Windows-Based Computers in Configuration Manager topic.

  5. Monitor client deployment and status by using the reports and information in the Configuration Manager console.

  6. Track how many clients are using a client PKI certificate by viewing the Client Certificate column in the Assets and Compliance workspace, Devices node.

    You can also deploy the Configuration Manager HTTPS Readiness Assessment Tool (cmHttpsReadiness.exe) to computers and use the reports to view how many computers can use a client PKI certificate with Configuration Manager.

    Note

    When the Configuration Manager client installs on client computers, the cmHttpsReadiness.exe tool is installed in the %windir%\CCM folder. When you run this tool on clients, you can specify the following options:

    • /Store:<name>

    • /Issuers:<list>

    • /Criteria:<criteria>

    • /SelectFirstCert

    These options map to the CCMCERTSTORE, CCMCERTISSUERS, CCMCERTSEL, and CCMFIRSTCERT Client.msi properties, respectively. For more information about these options, see About Client Installation Properties in Configuration Manager.

  7. When you are confident that a sufficient number of clients are successfully using their client PKI certificate for authentication over HTTP, do the following:

    1. Deploy a PKI web server certificate to a member server that will run an additional management point for the site, and configure that certificate in IIS. For more information, see the Deploying the Web Server Certificate for Site Systems that Run IIS section in the Step-by-Step Example Deployment of the PKI Certificates for Configuration Manager: Windows Server 2008 Certification Authority topic.

    2. Install the management point role on this server and configure the Client connections option in the management point properties for HTTPS.

  8. Monitor and verify that clients that have a PKI certificate use the new management point by using HTTPS. You can use IIS logging or performance counters to verify this.

  9. Reconfigure other site system roles to use HTTPS client connections. If you want to manage clients on the Internet, ensure that site systems have an Internet FQDN and configure individual management points and distribution points to accept client connections from the Internet.

    Important

    Before you configure site system roles to accept connections from the Internet, review the planning information and prerequisites for Internet-based client management. For more information, see the Planning for Internet-Based Client Management section in the Planning for Communications in Configuration Manager topic.

  10. Extend the PKI certificate rollout for clients and for site systems that run IIS, and configure the site system roles for HTTPS client connections and Internet connections, as required.

  11. For the highest security: When you are confident that all clients are using a client PKI certificate for authentication and encryption, change the site properties to use HTTPS only.

When you follow this plan to gradually introduce PKI certificates, first for authentication only over HTTP, and then for authentication and encryption over HTTPS, you reduce the risk that clients will become unmanaged. In addition, you will benefit from the highest security that Configuration Manager supports.

Planning for the Trusted Root Key

The Configuration Manager trusted root key provides a mechanism for Configuration Manager clients to verify that site systems belong to their hierarchy. Every site server generates a site exchange key to communicate with other sites. The site exchange key from the top-level site in the hierarchy is called the trusted root key.

The function of the trusted root key in Configuration Manager resembles a root certificate in a public key infrastructure in that anything signed by the private key of the trusted root key is trusted further down the hierarchy. For example, by signing the management point certificate with the private key of the trusted root key pair, and by making a copy of the public key of the trusted root key pair available to the clients, clients can differentiate between management points that are in their hierarchy and management points that are not in their hierarchy. Clients use WMI to store a copy of the trusted root key in the namespace root\ccm\locationservices.

Clients can automatically retrieve the public copy of the trusted root key by using two mechanisms:

  • The Active Directory schema is extended for Configuration Manager, the site is published to Active Directory Domain Services, and clients can retrieve this site information from a global catalog server.

  • Clients are installed by using client push.

If clients cannot retrieve the trusted root key by using one of these mechanisms, they trust the trusted root key that is provided by the first management point that they communicate with. In this scenario, a client might be misdirected to an attacker’s management point where it would receive policy from the rogue management point. This would likely be the action of a sophisticated attacker and might occur only in a limited time before the client retrieves the trusted root key from a valid management point. However, to reduce this risk of an attacker misdirecting clients to a rogue management point, you can pre-provision the clients by using the trusted root key.

Use the following procedures to pre-provision and verify the trusted root key for a Configuration Manager client:

  • Pre-provision a client by using the trusted root key by using a file.

  • Pre-provision a client by using the trusted root key without using a file.

  • Verify the trusted root key on a client.

Note

You do not have to pre-provision client by using the trusted root key if they can obtain this from Active Directory Domain Services or they are installed by using client push. In addition, you do not have to pre-provision clients when they use HTTPS communication to management points because trust is established by using the PKI certificates.

You can remove the trusted root key from a client by using the Client.msi property RESETKEYINFORMATION = TRUE with CCMSetup.exe. To replace the trusted root key, reinstall the client together with the new trusted root key, for example, by using client push, or by specifying the Client.msi SMSPublicRootKey property by using CCMSetup.exe.

To pre-provision a client with the trusted root key by using a file

  1. In a text editor, open the file <Configuration Manager directory>\bin\mobileclient.tcf.

  2. Locate the entry SMSPublicRootKey=, copy the key from that line, and close the file without any changes.

  3. Create a new text file and paste the key information that you copied from the mobileclient.tcf file.

  4. Save the file and place it somewhere where all computers can access it, but the file is secured to prevent tampering.

  5. Install the client by using any installation method that accepts Client.msi properties, and specify the Client.msi property SMSROOTKEYPATH=<Full path and file name>.

    Important

    When you specify the trusted root key for additional security during client installation, you must also specify the site code, by using the Client.msi property SMSSITECODE=<site code>.

To pre-provision a client with the trusted root key without using a file

  1. In a text editor, open the file <Configuration Manager directory>\bin\mobileclient.tcf.

  2. Locate the entry SMSPublicRootKey=, note the key from that line or copy it to the Clipboard, and then close the file without any changes.

  3. Install the client by using any installation method that accepts Client.msi properties, and specify the Client.msi property SMSPublicRootKey=<key>, where <key> is the string that you copied from mobileclient.tcf.

    Important

    When you specify the trusted root key for additional security during client installation, you must also specify the site code, by using the Client.msi property SMSSITECODE=<site code>

To verify the trusted root key on a client

  1. On the Start menu, click Run, and then type Wbemtest.

  2. In the Windows Management Instrumentation Tester dialog box, click Connect.

  3. In the Connect dialog box, in the Namespace box, type root\ccm\locationservices, and then click Connect.

  4. In the Windows Management Instrumentation Tester dialog box, in the IWbemServices section, click Enum Classes.

  5. In the Superclass Info dialog box, select Recursive, and then click OK.

  6. The Query Result window, scroll to the end of the list, and then double-click TrustedRootKey ().

  7. In the Object editor for TrustedRootKey dialog box, click Instances.

  8. In the new Query Result window that displays the instances of TrustedRootKey, double-click TrustedRootKey=@

  9. In the Object editor for TrustedRootKey=@ dialog box, in the Properties section, scroll down to TrustedRootKey CIM_STRING. The string in the right column is the trusted root key. Verify that it matches the SMSPublicRootKey value in the file <Configuration Manager directory>\bin\mobileclient.tcf.

Planning for Signing and Encryption

When you use PKI certificates for all client communications, you do not have to plan for signing and encryption to help secure client data communication. However, if you configure any site systems that run IIS to allow HTTP client connections, you must decide how to help secure the client communication for the site.

To help protect the data that clients send to management points, you can require it to be signed. In addition, you can require that all signed data from clients that use HTTP is signed by using the SHA-256 algorithm. Although this is a more secure setting, do not enable this option unless all clients support SHA-256. Many operating systems natively support SHA-256, but older operating systems might require an update or hotfix. For example, computers that run Windows Server 2003 SP2 must install a hotfix that is referenced in the KB article 938397.

Whereas signing helps protect the data from tampering, encryption helps protect the data from information disclosure. You can enable 3DES encryption for the inventory data and state messages that clients send to management points in the site. You do not have to install any updates on clients to support this option, but consider the additional CPU usage that will be required on clients and the management point to perform the encryption and decryption.

For information about how to configure the settings for signing and encryption, see the Configure Signing and Encryption section in the Configuring Security for Configuration Manager topic.

Planning for Role-Based Administration

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

  • Security roles

  • Collections

  • Security scopes

These settings combine to define an administrative scope for an administrative user. The administrative scope controls the objects that an administrative user can view in the Configuration Manager console and the permissions that user has on those objects. 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 information about how to monitor intersite database replication, see the How to Monitor Database Replication Links and Replication Status section in the Monitor Configuration Manager Sites and Hierarchy topic.

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 the least permissions.

System Center 2012 Configuration Manager 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).

Tip

You can view the list of built-in security roles and custom security roles you create, including their descriptions, in the Configuration Manager console. To do so, in the Administration workspace, expand Security, and select Security Roles.

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 have 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 perform in System Center 2012 Configuration Manager. 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 perform the tasks of multiple security roles, assign the multiple security roles to these administrative users instead of in 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.

For information about how to create and configure security roles for role-based administration, see the Create Custom Security Roles and Configure Security Roles sections in the Configuring Security for Configuration Manager topic.

Planning for Collections

Collections specify the user and computer resources that an administrative user can view or manage. For example, for administrative users 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.

Before you configure role-based administration, check 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 information about how to configure collections for role-based administration, see the Configure Collections to Manage Security section in the Configuring Security for Configuration Manager topic.

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 System Center 2012 Configuration Manager, 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:

  • Alert subscriptions

  • Applications

  • Boot images

  • Boundary groups

  • Configuration items

  • Custom client settings

  • Distribution points and distribution point groups

  • Driver packages

  • Global conditions

  • Migration jobs

  • Operating system images

  • Operating system installation packages

  • Packages

  • Queries

  • Sites

  • Software metering rules

  • Software update groups

  • Software updates packages

  • Task sequence packages

  • Windows CE device setting items and packages

There are also some objects that you cannot include in security scopes because they are only secured by security roles. Administrative access to these cannot 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 does not support security scopes, you cannot assign this user a security scope that provides access to only the boundaries that might be associated with that site. Because a boundary object cannot 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 are not limited by security scopes include the following:

  • Active Directory forests

  • Administrative users

  • Alerts

  • Antimalware Policies

  • Boundaries

  • Computer associations

  • Default client settings

  • Deployment templates

  • Device drivers

  • Exchange Server connector

  • Migration site-to-site mappings

  • Mobile device enrollment profiles

  • Security roles

  • Security scopes

  • Site addresses

  • Site system roles

  • Software titles

  • 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 must be able to see production applications and not test applications. Create one security scope for production applications and another for the test applications.

  • Different administrative users require different access for some instances of an object type. For example, one group of administrative users requires Read permission to specific software update groups, and 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 information about how to configure security scopes for role-based administration, see the Configure Security Scopes for an Object section in the Configuring Security for Configuration Manager topic.