The trusted root key provides a mechanism for clients to verify the authenticity of the management point and its certificate if they cannot query Active Directory Domain Services. Every primary site server generates a trusted root key, even if the site is running in native mode and even if Active Directory Domain Services publishing is enabled. If the primary site is joined to a parent site, the child site eliminates its own trusted root key and instead trusts the trusted root key of the parent site. The function of the trusted root key is somewhat like 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. 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 valid management points and rogue management points. Clients require the trusted root key only if they cannot query the Global Catalog for Configuration Manager 2007 information, either because they are in a workgroup or remote forest, or because the Active Directory Domain Services schema is not extended for Configuration Manager 2007. The trusted root key is stored in WMI in the root\ccm\locationservices namespace.

When a new management point is created, regardless of the site mode, it creates a self-signed certificate in the certificate store. In mixed mode, the self-signed certificate is then saved to a location in the registry. In native mode, the management point certificate issued by the PKI is saved to the registry location. Site component manager collects the certificate from the registry and sends its certificate to its site server. If its site server is not the central site, the certificate is passed up through the hierarchy until it arrives at the central site where the trusted root key is kept. The central site server signs the management point’s certificate with the private trusted root key and sends it back down through the hierarchy to the management point, along with a copy of the public trusted root key. When the management point receives the copy of the public trusted root key, it signs the trusted root key with its own private key. This aids in recoverability, as discussed later in this section. At this point, the management point has several keys used in the trusted root key process:

• The management point’s certificate (either self-signed for mixed mode or PKI-issued for native mode)
  
  
• The management point’s certificate signed by the trusted root key
  
  
• A copy of the public trusted root key from the central site
  
  
• A copy of the public trusted root key signed by the management point’s private key
  
  

The client stores the following key and certificate information in classes in WMI:

• Information about each management point in the management point list, including the management point’s certificate
  
  
• The copy of the public trusted root key
  
  
• The list of management points the client communicates with
  
  

  Note
  If the management point is in an NLB cluster, the list of management points the client trusts will contain all of the site systems in the cluster. If there is no NLB cluster in the site, the list will contain just the default management point.

When the client makes a request to the management point, it attempts to verify the response. The client looks to see if the management point for the site code is in the management point list in WMI. If it is, the client attempts to retrieve a copy of the management point certificate from WMI. Assuming it finds the certificate, it verifies the message. Every message must be verified, otherwise it is discarded.

If the client does not have the management point certificate stored in WMI, it checks to see when the management point list was last updated. If the last updated time is greater than five minutes, the client retrieves a new management point list. Also, if there was no management point list in WMI, the client must retrieve a management point. Where the client retrieves the list of management points depends on the client mode and whether you have extended the Active Directory Domain Services schema for Configuration Manager 2007.

The client can be configured in one of three modes by running client setup with the installation property SMSDIRECTORYLOOKUP=<switch>. The following table describes each mode and its associated management point authentication process.

If no switch is specified, the client installs in Secure WINS mode. Active Directory Only mode is the most secure, relying on the underlying security of the Active Directory Domain Services querying process, but can be used only if your clients can query the Global catalog so it should not be used for clients in remote forests or workgroups. The Any WINS mode is not secure and is not recommended.

If you have extended Active Directory Domain Services and enabled publishing for Configuration Manager, clients in the same forest as the site server can retrieve the public copy of the trusted root key by querying the Global Catalog server. If the client is unable to retrieve an initial copy of the trusted root key from Active Directory Domain Services, you can pre-provision the trusted root key on the client during client installation.

If clients do not have the trusted root key, they will trust the trusted root key presented by the first management point they communicate with, meaning 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 could occur only within a limited time before the client retrieves the trusted root key from a valid management point. To reduce the risk of an attacker misdirecting clients to a rogue management point, you can pre-provision the clients with the trusted root key. For more information, see How to Pre-provision the Trusted Root Key on Clients.

Note
To reduce the risk of new clients being misdirected to a rogue management point, pre-provision the client with the trusted root key if it cannot query Active Directory Domain Services.

After the client has obtained a copy of the trusted root key, it keeps that copy in the registry. If the client encounters a failure to authenticate a message from a management point, the client refreshes the trusted root key, discards the current management point certificate, and obtains a new copy of the management point certificate signed by the trusted root key.

If the central site server needs to be recovered, it will generate a new trusted root key. Certificates from all management points from other sites in the hierarchy will be collected, sent to the central site, signed by the trusted root key, and eventually returned to each management point. Because a client in another site trusts the management point, it will accept the new trusted root key. If the client contacts a management point that it does not yet trust, and cannot verify the management point by querying Active Directory Domain Services, it will not accept information from the management point. The client will be unmanaged until it can verify the management point.

If there is no trusted management point for the client to contact, problems can arise. For example, clients might report to a central site server that also functions as the management point for the site and that site server is down. This often occurs in small deployments where there is only one site and the site server performs all roles for the site. In the case of a system failure on the site server, a new trusted root key is created during site server recovery and the management point receives a new certificate, either by creating a self-signed certificate for mixed mode or by getting a new PKI-issued certificate for native mode. The client has neither the current copy of the management certificate nor the copy of the trusted root key and has no automatic mechanism to get either. If the client cannot query Active Directory Domain Services to verify the management point, the client cannot communicate with the site until the administrator removes the old trusted root key from the client and then either pre-provisions the new trusted root key or allows the client to obtain the key from the first management point it contacts.

If clients can query Active Directory Domain Services, they do not rely on the trusted root key so compromise does not pose serious risk. Running in native mode requires a PKI-issued certificate for the management point, so trusted root key compromise is less risky in native mode than in mixed mode.

If you suspect that your trusted root key is compromised, you should monitor the site audit client status messages for indications of unauthorized site activity such as unrecognized packages running.

If you reinstall and restore the central site server, you will generate a new trusted root key. If you restructure your site hierarchy so that a child site is promoted to be the new central site, Configuration Manager 2007 creates a new trusted root key for the hierarchy. You can pre-provision the clients to use the new trusted root key as described earlier, however you still leave your network exposed to the risk that an attacker has established back doors in your systems. To truly recover from a trusted root key compromise, you should consider reinstalling all site servers, management points, and client computers.

After a distribution point is enabled to support multicast, the distribution point creates a self-signed certificate in the local certificate store and places the certificate signature in the registry. Site component manager locates the signature in the registry, notices that it has not been signed by the trusted root key, and then forwards it to the hierarchy manager to sign it with the site's trusted root key. After the certificate signature has been signed with the trusted root key, the signature is stored back in the registry. After the signing process is complete, the distribution point is ready to support multicast clients. If the self-signed certificate expires, the distribution point creates a new one and starts the signing process again.

Tasks