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.

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.

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.

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.
  
  

  Important
  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 in Configuration Manager 2007.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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

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.

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.

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.