Workgroup Clients in SMS 2003 (Trusted Root key)
Management points need to authenticate to the clients to prevent attackers from inserting unauthorized management points and redirecting clients to them. When a management point is created, it creates a certificate to be used for signing. The certificate is self-signed and is valid for 99 years. It is created and stored in the certificate store on the management point.When the Advanced Client receives a message from the management point, the client uses one of two ways to verify that the message came from a valid management point. The message can be verified using Active Directory or the trusted root key.If the AD schema has not been extended and SMS does not have permissions to publish to Active Directory, the Advanced Clients switch to an alternate method to verify the authenticity of the management point and its certificate. Each primary site server generates a trusted root key. If the primary site is joined to a parent site, it 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 similar to a root certificate in a public key infrastructure. By signing the management point certificates 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 Advanced Clients, clients can differentiate between valid management points and unauthorized management points. Advanced Clients require only the trusted root key if the Active Directory schema is not extended for SMS. The trusted root key is stored in WMI in the root\ccm\locationservices directory.
If the Advanced Client has the wrong trusted root key then it will throw following errors in CertificateMaintaince.log and locationservices.log
In my environment many of workgroup clients was giving above errors and so they are not reporting H/W inventory (Reporting to MP through Proxy management point)I tried to Manually Transferring Site Keys but I didn’t get any success and "removing of Key information" by running CCMSetup with the RESETKEYINFORMATION switch on many numbers of clients was not possible for me. Reinstalling of secondary site and reinstalling proxy management point solved my problem. And the clean log looks like this
The reason why problem has been resolved? (When a new management point is created, its self-signed certificate is saved to a location in the registry. 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 trusted root key and sends it back down through the hierarchy to the management point, along with a copy of the trusted root key. When the management point receives the copy of the trusted root key, it signs the trusted root key with its own private key.)
For Better understanding please go through SMS Certificate Infrastructure