Export (0) Print
Expand All

Overview of Configuration Manager Cryptographic Controls

Updated: October 1, 2009

Applies To: System Center Configuration Manager 2007, System Center Configuration Manager 2007 R2, System Center Configuration Manager 2007 R3, System Center Configuration Manager 2007 SP1, System Center Configuration Manager 2007 SP2

To protect data on the network, you can sign the data so that if it has been altered in transit, the data will be discarded. You can also encrypt data to prevent an attacker from reading it through a network protocol analyzer like Network Monitor. Microsoft System Center Configuration Manager 2007 uses both signing and encryption in both mixed and native modes, as described in the following sections.

Cryptographic Controls in All Site Modes

Certain information in Configuration Manager 2007 can be signed and encrypted, regardless of the site mode.

Hashing Content

The distribution manager service on the site server hashes the content files for all packages. The policy provider includes the hash in the software distribution policy. If an advertisement is set to Download content from distribution point and run locally, when the client downloads the content, it regenerates the hash locally and compares it to the one supplied in the policy. If the hashes match, the content has not been altered and the client can install it. If a single byte of the software has been altered, the hashes will not match and the software will not be installed. Additionally, this check helps ensure that the correct software is installed because the actual content is crosschecked with the policy. However, if the advertisement is set to Run program from distribution point, the client does not verify the hash.

Hashing Policy

When Configuration Manager 2007 clients request policy, they first get a policy assignment so that they know which policies apply to them, and then request only those policy bodies. Each policy assignment contains the calculated hash for the corresponding policy body. The client retrieves the applicable policy bodies and then calculates the hash on that body. If the hash on the downloaded policy body does not match the hash in the policy assignment, the policy body is discarded.

Signing Desired Configuration Management Data

Before Configuration Manager 2007 imports configuration data, it verifies the file's digital signature. If the files have not been signed, or if the digital signature verification check fails, you will be warned and prompted to continue with the import. Continue importing the configuration data only if you explicitly trust the publisher and the integrity of the files.

Site-to-Site Signing and Encryption

The site control file contains all the configuration properties for a site and any child sites. When an administrator changes the configuration for a child site, the parent sends the changes in a site control file to the child site server. If the administrator in a child site changes the configuration, the changes are sent in a site control file to the parent site. Child sites also send data such as inventory and status to the parent site, while parent sites send data such as packages and collection definitions to the child sites.

Before sending any data between sites, the sending site server generates a hash and signs it with its private key. The receiving site server checks the signature by using the public key and compares the hash with a locally generated value. If they match, the receiving site accepts the site control file. If the values do not match, the site control file is rejected.

A related configuration allows Configuration Manager 2007 to automatically distribute the site-to-site communication keys to the parent or child site, even if the communication channel is not secure. If you do a fresh installation, Require secure key exchange is enabled by default, however if you are upgrading the current setting is preserved.

After Require secure key exchange is enabled, the site-to-site communication public key can be exchanged in one of two ways:

  • If the Active Directory Domain Services schema has been extended for Configuration Manager 2007 and Configuration Manager 2007 has permissions to publish to Active Directory, the site server will automatically publish its site-to-site communication public key to its site object in the System Management container.

  • If the Active Directory schema has not been enabled, or if Configuration Manager 2007 does not have permissions to publish to Active Directory, the Configuration Manager 2007 administrator must dump the public key using the Preinst command, and then manually copy the public key to the destination site.

    ImportantImportant
    Automatic key exchange does not work between forests. If the site hierarchy spans forest boundaries, the administrator must manually exchange the keys even if both forests have extended the schema and Configuration Manager 2007 is publishing to Active Directory.

Some information within the site control file is encrypted; however the site control file itself is not encrypted when transferred between sites. You should use IPsec to enable encryption for site-to-site communication. For more information, see Implementing IPsec for Configuration Manager 2007.

Inventory Signing and Encryption

Inventory is always signed for computers, regardless of the mode, however inventory for mobile devices is signed only in native mode. In mixed mode, encryption is optional, but recommended. For more information, see How to Encrypt Client Inventory Reports.

State Migration Encryption

Data stored on state migration points for operating system deployment is always encrypted.

Signing in Software Updates

All software updates must be signed by a trusted publisher to protect against tampering. On client computers, the Windows Update Agent (WUA) will scan for the updates from the catalog, but will fail to install the update unless it can locate the digital certificate in the Trusted Publishers store on the local computer. If a self-signed certificate was used when publishing the updates catalog, such as WSUS Publishers Self-signed, the certificate must also be in the Trusted Root Certification Authorities certificate store on the local computer to verify the validity of the certificate. WUA also checks whether the Allow signed content from intranet Microsoft update service location Group Policy setting is enabled on the local computer. This policy setting must be enabled for WUA to scan for the updates that were created and published with Updates Publisher.

When software updates are published in System Center Updates Publisher, a digital certificate signs the software updates when they are published to an update server. You can either specify a PKI certificate or have Updates Publisher generate a self-signed certificate to sign the update.

Certificates in Mobile Device Management

If the mobile device has not been locked by the mobile operator, Configuration Manager 2007 can help install certificates needed for signature verification of mobile applications by sending certificates as configuration items or by installing the certificates along with the client software. If your mobile device is locked, you cannot use Configuration Manager 2007 to deploy certificates. For more information, see Deploying Certificates to Mobile Device Clients.

If you enable hardware inventory for mobile devices, Configuration Manager 2007 also inventories the certificates installed on the mobile device.

Certificates in Out of Band Management (Configuration Manager 2007 SP1 and Later)

Out of band management uses at least two types of PKI-issued certificates: an AMT provisioning certificate and a Web server certificate.

The out of band service point uses an AMT provisioning certificate to prepare computers for out of band management. The AMT-based computers that will be provisioned must trust the certificate presented by the out of band management point. By default, AMT-based computers are configured by the computer manufacturer to use external certification authorities (CAs), such as VeriSign, Go Daddy, Comodo, and Starfield. If you purchase a provisioning certificate from one of the external CAs and configure Configuration Manager to use this provisioning certificate, AMT-based computers will trust the CA of the provisioning certificate and provisioning can succeed. However, it is a security best practice to use your own internal CA to issue the AMT provisioning certificate. For more information, see Out of Band Management Security Best Practices and Privacy Information.

The AMT-based computers run a Web server component within their firmware and that Web server component encrypts the communication channel with the out of band service point using Transport Layer Security (TLS). There is no user interface into the AMT BIOS to manually configure a certificate, so you must have a Microsoft enterprise certification authority that automatically approves certificate requests from the primary site server and installs the certificates on the AMT-based computers. The request uses PKCS#10 for the request format, which in turn, uses PKCS#7 for transmitting the certificate information to the AMT-based computer.

Although the AMT-based computer is authenticated to the computer managing it, there is no corresponding client PKI certificate on the computer managing it. Instead, these communications use either Kerberos or HTTP Digest authentication. When HTTP Digest is used, it is encrypted using TLS.

An additional type of certificate might be required for Configuration Manager 2007 SP2: an optional client certificate for 802.1X authenticated wired networks and wireless networks. The client certificate might be required by the AMT-based computer for authentication to the RADIUS server. When the RADIUS server is configured for EAP-TLS authentication, a client certificate is always required. When the RADIUS server is configured for EAP-TTLS/MSCHAPv2 or PEAPv0/EAP-MSCHAPv2, the RADIUS configuration specifies whether a client certificate is required or not. This certificate is requested by the site server and installed on AMT-based computers by using the same processes as the Web server certificate request and installation for AMT-based computers.

For more information, see About Certificates for Out of Band Management.

Encryption for Multicast Packages (Configuration Manager 2007 R2)

For every operating system deployment package, you have the option to enable encryption when transferring the package using multicast. If you enable encryption, no additional certificate configuration is required. The multicast-enabled distribution point automatically generates symmetric keys for encrypting the package. Each package has a different encryption key. The key is stored on the multicast-enabled distribution point using standard Windows APIs. When the client connects to the multicast session, the key exchange occurs over a channel encrypted with either the PKI-issued client authentication certificate (native mode) or the self-signed certificate (mixed mode). The client stores the key in memory only for the duration of the multicast session.

Cryptographic Controls in Native Mode

Native mode is the recommended mode because it offers a higher level of security by integrating with a public key infrastructure (PKI) to help protect client-to-server communication. However, implementing native mode without a thorough understanding of PKI planning, deployment, and operations could still leave you vulnerable. For example, if you do not properly secure your root CA, attackers could compromise the trust of your entire PKI infrastructure. Also, if you do not properly deploy and manage the necessary native mode certificates, you could leave all of your clients in an unmanaged state such that they cannot receive critical software updates or packages.

ImportantImportant
Native mode helps protect only communication between the client and some site systems. Native mode does nothing to protect the communication channel between the site server and site systems or between site servers.

Native Mode Certificates

Native mode requires several types of certificates:

Site systems that require IIS require Web server certificates to encrypt communications with clients over SSL. The following site systems require Web server certificates.

  • Management point

  • Proxy management point

  • Distribution point

  • Software update point

  • State migration point

All clients, both client computers and mobile device clients, require client authentication certificates. You must also deploy a client authentication certificate to the management point and state migration point, even if they do not have a Configuration Manager 2007 client installed on them. If your clients already have client authentication certificates, Configuration Manager 2007 might be able to use your existing certificates.

The site server requires a custom site server signing certificate to sign policy sent to clients. This certificate must have document signing capability and have a specific text string as the subject name. All clients must have a copy of the site server signing certificate, so they can verify the signature on the policy.

For more information, see Certificate Requirements for Native Mode.

If all the computers in your Configuration Manager 2007 hierarchy use certificates from the same certification authority, you need to deploy only a single trusted root certification authority. However, there is no requirement to use the same certification authority, so you might have to install multiple root CAs on your clients and servers. If you are not using a Microsoft PKI solution, you might also need to install intermediate CA certificates on your site systems.

For more information, see Deploying the PKI Certificates Required for Native Mode.

noteNote
All Configuration Manager 2007 certificates must contain only single-byte characters in the subject name or subject alternative name. For more information, see Native Mode Certificates and Double-Byte Character Sets.

Internet-based Client Management Certificates

Internet-based client management requires native mode and all of the native mode certificate infrastructure. In addition, if the site supports Internet-based client management and you are using a proxy server with SSL termination (bridging) for incoming Internet connections, you must configure a certificate for Server authentication and client authentication on the proxy server. If you are using a proxy server without SSL termination (tunneling), no additional certificates are required on the proxy server. For more information, see Determine Requirements for Proxy Web Servers to Use With Internet-Based Client Management.

Mobile Device Client Certificates in Native Mode

If you have mobile devices assigned to a native mode site, they require certificates to support native mode. Native mode mobile device clients require a copy of the site server signing certificate, a copy of the Web server certificate for management points and distribution points that support mobile devices, and copies of the intermediate CAs and root CAs. Mobile devices require a certificate in the Personal store with client authentication capabilities. For more information, see About Native Mode Certificates for Mobile Device Clients.

Unlike client computers, which require a certificate for computer authentication, mobile devices require user authentication certificates to authenticate to native mode site systems.

Operating System Deployment Certificates in Native Mode

When you use Configuration Manager 2007 to deploy operating systems in native mode, a client computer must also have a certificate to communicate with the management point, even if the computer is in a transitional phase like booting from task sequence media or a PXE service point. To support this scenario, a PKI client authentication certificate must be created and exported with the private key and the certificate for the trusted root CA for the management point must be configured in the site server properties.

If you are creating bootable media, you import the client authentication certificate when you create the bootable media. You should set a password on the bootable media to help protect the private key and other sensitive data configured in the task sequence. Every computer that boots from the bootable media will present the same certificate to the management point as needed for client functions such as requesting policy.

If you use PXE boot, you import the client authentication certificate to the PXE service point and it loans the same certificate to every client booting from that PXE service point. You should require users connecting to the PXE service point to supply a password to help protect the private key and other sensitive data in the task sequences.

If either of these client authentications certificates is compromised, you should block the certificates in the site properties in the Certificates node. Managing these certificates requires the Manage operating system deployment certificate right.

After the operating system is deployed and the Configuration Manager 2007 is installed, the client will need its own PKI client authentication certificate for native mode communication, as described earlier in this section.

For more information, see How to Manage Native Mode Certificates and Operating System Deployment.

Support for Extending Configuration Manager in Native Mode

Independent Software Vendors (ISVs) can create applications that extend Configuration Manager 2007. For example, an ISV could create extensions to support non-Windows client platforms such as Macintosh or UNIX computers. However, if the site is in native mode, even extended clients must use certificates to communicate with the Configuration Manager 2007 management point. Configuration Manager 2007 includes the ability to assign a certificate to the ISV proxy that enables communications between the ISV proxy clients and the management point. If you use extensions that require ISV proxy certificates, consult the documentation for that product. If you need to create ISV proxy certificates, see the Configuration Manager 2007 Software Developer Kit (SDK) for more information.

If the ISV certificate is compromised you should block the certificate in the site properties in the Certificates node.

Communication That Is Unencrypted in Native Mode

In native mode, communications are usually encrypted over SSL. However, in the following situations, native mode clients communicate with site systems without using encryption:

  • Advertisements are configured for the option Run program from distribution point

  • Client fails to make an HTTPS connection to the distribution point

  • Client is communicating with the following site systems:

    • Fallback status point

    • Server locator point

    • PXE service point

    • System Health Validator point

  • In native mode, client computers are configured for HTTP communication for roaming and site assignment to communicate with a server locator point

  • Branch distribution points, which always use the server message block (SMB) protocol, even in native mode

  • Distribution points not configured to Allow clients to transfer content from this distribution point using BITS, HTTP, and HTTPS. Without this setting, clients always use SMB, even in native mode.

Reporting points are configured to use HTTP or HTTPS independently of the site mode.

For more information, see Client Communication in Mixed Mode and Native Mode.

Signing in Native Mode

In native mode, client policy assignments are signed by the site server signing certificate to help prevent the security risk of a compromised management point sending policies that have been tampered with. This safeguard is particularly relevant if you are using Internet-based client management because this environment requires a management point that is exposed to Internet communication. Also, client communication between clients and servers is signed, except as described in the section "Communication That Is Unencrypted in Native Mode".

CRL Checking

Certificate revocation list (CRL) checking is enabled by default in IIS, so if you are using a CRL with your PKI deployment, there is nothing additional to configure on most Configuration Manager site systems. The exception is for software updates, which requires a manual step to enable CRL checking to verify the signatures on software update files. For more information, see How to Enable CRL Checking for Software Updates.

CRL checking is enabled by default for client computers in native mode when the site is installed in native mode but is disabled by default when the site is installed in mixed mode and then migrated to native mode. Enabling CRL checking increases administrative and processing overhead but is more secure. However, if CRL checking is enabled but the client cannot access the CRL, the client cannot communicate with the site. For more information, see Determine Whether You Need to Enable Certificate Revocation Checking (CRL) On Clients (Native Mode).

Cryptographic Controls in Mixed Mode

In mixed mode, some certificates are still used but they are self-signed and require no PKI infrastructure. In most cases, the self-signed certificates require no administrator action.

Policy Signing

When clients request policy in mixed mode, the policy assignment sent back is signed by the management point's self-signed certificate. One of the reasons native mode is more secure is the policy is signed by the central site server signing certificate in addition to the management point PKI-issued certificate. In mixed mode, an attacker who compromises a management point can create and sign arbitrary policy. If the client cannot verify the signature on the policy assignment, the client discards the policy assignment.

Operating System Deployment Certificates

When you use Configuration Manager 2007 to deploy operating systems in mixed mode, a client computer must also have a certificate to communicate with the management point, even if the computer is in a transitional phase like booting from task sequence media or a PXE service point. To support this scenario in mixed mode, Configuration Manager 2007 generates self-signed certificates. If the self-signed certificates are compromised, you should block the certificates in the site properties in the Certificates node to prevent attackers from using them to impersonate trusted clients.

Client and Server Authentication

In mixed mode, clients authenticate their management points using either Active Directory Domain Services or by using the Configuration Manager 2007 trusted root key, as described in About the Trusted Root Key. Clients do not authenticate other server roles, such state migration points or software update points. Clients in mixed mode generate self-signed certificates and management points use them to authenticate the clients. Because any client can generate a self-signed certificate that will be accepted by the management point, mixed mode provides minimal security. However, only clients that are approved are trusted enough to receive any policy containing sensitive information.

Cryptographic Algorithms Used in Configuration Manager

The primary hashing algorithm used in Configuration Manager 2007 is SHA-1. When two Configuration Manager 2007 sites communicate with each other, they sign their communications using SHA-2. The primary encryption algorithm implemented in Configuration Manager 2007 is 3DES. Also, if native mode is implemented, you can configure your PKI to use RSA certificates with the maximum key lengths documented in Certificate Requirements for Native Mode. For most cryptographic operations, Configuration Manager uses the SHA-1, SHA-2, 3DES, and RSA algorithms from the Windows CryptoAPI library rsaenh.dll.

noteNote
If you have SMS 2003 sites in the site hierarchy, Configuration Manager 2007 uses MD5 hashes to sign communication with the SMS 2003 child sites. Packages created in SMS 2003 (no service pack) are hashed with MD5 until they are updated using the Update Distribution Points Wizard in SMS 2003 (with any service pack) or in Configuration Manager 2007, after which the packages are hashed with SHA-1.

See Also

For additional information, see Configuration Manager 2007 Information and Support.
To contact the documentation team, email SMSdocs@microsoft.com.
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft