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

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.
  
  

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.

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 clients will select the certificate to use for Configuration Manager.

In many cases, the default configuration and behavior will be sufficient. The Configuration Manager client 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.

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.

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 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. For more information, see How to Monitor Database Replication and SQL Server Status for Database Replication.
   
   
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.

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>.

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>

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.

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.
   
   

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.
  
  

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
  
  
• Antimalware policies
  
  
• 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
  
  
• 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.