Appendix B: SMS Certificate Infrastructure

To protect data on the network, you can sign the data to prevent an attacker from altering it in transit. You can also encrypt data to prevent an attacker from reading it through a network protocol analyzer like Network Monitor.

In order to encrypt data, you need keys. A key is a string of bits that is used to vary the results of an algorithm. Keys can be symmetric, meaning the same key is used to encrypt and decrypt the data; or they can be asymmetric, meaning one key is used to encrypt the data and a different, but mathematically related, key is used to decrypt the data. Asymmetric keys are usually referred to as public/private key pairs. The key used to encrypt the data is made public, so that anyone can encrypt data using that key; however, the key used to decrypt the data is kept private and secure, so that only the holder of the private key can perform the decryption.

Keys can also be used to digitally sign data to verify that it has not been altered. Usually, the data is hashed first. A hash function is a type of encryption that takes data of any length and encrypts it to create a fixed-size string of data, called a hash. A hash is also sometime referred to as a digest. When sending signed data, the sender hashes the data, signs it with the private key, and sends the hash along with the data. The recipient hashes the data and then decrypts the enclosed hash using the public key. If the results match, it verifies who sent the data (assuming the private key has not been compromised) and it verifies that the data has not been altered since it was signed. Changing even a single character in the data means that the hashes would not match and the data would be considered compromised.

A certificate, ** sometimes called a digital certificate, is a digital document that is commonly used for authentication and for secure exchange of information about open networks, such as the Internet, extranets, and intranets. A certificate securely binds a public key to the entity that holds the corresponding private key. For example, you can send a certificate with a signed e-mail message. The recipient uses the certificate to verify the sender of the message. You can also use the public key that is included with the certificate to sign, encrypt, or decrypt data.

SMS Cryptography

Microsoft Systems Management Server (SMS) 2003 does not require a public key infrastructure to manage certificates. With the exception of SSL certificates for encryption of reporting point traffic, the SMS site systems maintain their own certificate infrastructures and public/private key pairs.

Signing and encrypting SMS communications can mitigate several types of attacks.

Table B.1  How SMS Encryption Mitigates Attacks

1. These features are available only with SMS 2003 SP1.

Management Point Authentication to Clients

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.

What is the trusted root key?

If the Active Directory® 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.

How do management points obtain the trusted root key?

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. This aids in recoverability, as discussed later in this document. At this point, the management point has several keys:

• The management point’s self-signed certificate

• The management point’s certificate signed by the trusted root key

• A copy of the trusted root key from the central site

• A copy of the trusted root key signed by the management point’s private key

How do Advanced Clients authenticate the management point?

• The Advanced Client stores the following key and certificate information in classes in WMI:

• The list of management points the client trusts

• Information about each management point in the management point list, including the management point’s certificate

• The trusted root key

When the Advanced Client makes a request from the management point, it attempts to verify the response. First it checks the site code. If the site code is valid, it looks to see if the management point is in the management point list in WMI. If it is, it 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 list. Where the client retrieves the list of management points depends on the client mode and whether you have extended the Active Directory schema for SMS, as discussed in Table B.1.

The client can be configured in one of three modes by running client setup with the installation property SMSDIRECTORYLOOKUP=<switch>. If no switch is specified, the client installs in Secure WINS mode. Active Directory Only mode is the most secure, but can be used only if your schema has been extended. The Any WINS mode is not secure and is not recommended. Table B.2 describes each mode and its associated management point authentication process.

Table B.2  Management Point Authentication Process

For more information about using Advanced Client Installer, see Appendix I, “Installing and Configuring SMS Clients” in the Scenarios and Procedures for Microsoft Systems Management Server 2003: Planning and Deployment .

How do Advanced Clients obtain the trusted root key?

In SMS 2003 SP1, clients that are installed using the following methods automatically receive the trusted root key during installation and require no additional action for secure installation.

• Logon Script-initiated Client Installation (Capinst.exe)

• Manual Client Installation (Ccmsetup.exe)

• Client Push Installation

If you use Windows Group Policy installation (Client.msi), you must perform additional steps to ensure that the Advanced Client receives the trusted root key during installation. For the procedure, see Installing the Trusted Root Key using Windows Group Policy installation (Client.msi) in Appendix E: “Appendix E: SMS Security Procedures.”

If the Advanced Client has not yet received a copy of the trusted root key, it requests a copy from the management point. If the client is unable to retrieve an initial copy of the trusted root key, it will trust the certificate presented by the management point.

In the absence of a trusted root key, a client might be misdirected to an attacker’s management point where it would receive policy from the unauthorized 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.

How do Advanced Clients refresh the trusted root key?

After the Advanced Client has obtained a copy of the trusted root key, it keeps that copy in WMI. Periodically, the client refreshes the trusted root key, discards the current management point certificate, and obtains a new copy of the certificate signed by the trusted root key.

How do Advanced Clients recover from a central site failure?

If the central site server needs to be recovered, it will generate a new trusted root key. Certificates from all management points 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 the client 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, it will not accept information from the management point. The client will be offline until it can contact a trusted management point and receive the new trusted root key.

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, you must create a new trusted root key and a new certificate for a new management point as a part of the recovery. The Advanced Client does not have a trusted management point or trusted root key or a mechanism to get either, and will not function until it establishes trust with a new management point.

To recover the client, you must remove the old trusted root key from the client as described below, and then either install the new trusted root key as described in Reinstalling the Trusted Root Key in Appendix E: “Appendix E: SMS Security Procedures”, or allow the client to obtain the key automatically, as described in Table B.2 Management Point Authentication Process

How do you remove the trusted root key from the client?

If the Advanced Client has the wrong trusted root key and there is no trusted management point to receive a valid copy of the new trusted root key, you must delete the trusted root key from the client. Also, if you plan to move a client from one site hierarchy to a different site hierarchy, you must first remove the trusted root key.

Running CCMSetup with the RESETKEYINFORMATION switch deletes the trusted root key from WMI. You must run this locally on the client because software distribution will not function until the client has a trusted management point. Running this switch requires local administrative rights on the Advanced Client. After running this switch, the client is vulnerable until it receives a new trusted root key because it has no way to differentiate between valid management points in the site and unauthorized management points created by attackers. You should reinstall the client along with the new trusted root key, as described earlier.

Advanced Client Policy Signing

For every change in the SMS Administrator console that affects the Advanced Client, the policy provider on the site server generates a new policy and generates an assignment that points to the URL for that policy body. The policy provider creates a SHA-1 hash of the policy body and stores the signed hash in the assignment.

The Advanced Client requests its assignments from the management point and downloads each policy in turn. It calculates a hash locally for each one. This is compared with the hash supplied with the assignment. If they match, the policy is accepted. This helps protect against “on-the-wire” security attacks where the policy might be intercepted and replayed. Because the communication between the client and the management point takes place using anonymous HTTP, it is essential for the client to ensure that the policy it has downloaded is valid. After the client downloads the policy, it checks the signature and compares the hash with a locally generated value. If they match, the policy is accepted.

Signing Packages that are Downloaded and Executed

An Advanced Client has two primary options for software installation:

• Run from network

• Download and execute

If an advertisement is set to download and execute, the distribution manager service on the site server hashes the content files. The policy provider includes the hash in the software distribution policy. The Advanced Client downloads the policy as described earlier in this document. 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.

Note

This check only takes place for downloaded software. The check does not take place for software installed directly from a distribution point (run from the network).

Site-to-Site Communication Signing

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.

By default, unsigned communications are allowed between sites. This allows for backwards compatibility with SMS 2.0 sites that have not upgraded to SP5, but it is not a secure configuration. For the procedure to change this configuration, see Disabling Unsigned Communications Between Sites in Appendix E: “Appendix E: SMS Security Procedures.”

A related configuration allows SMS to automatically distribute the site-to-site communication certificates to the parent or child site, even if the communication channel is not secure. By default, a secure channel is not required, but this configuration should be enabled for a secure environment. For the procedure, see Requiring Secure Key Exchange in Appendix E: “Appendix E: SMS Security Procedures .” After this setting is enabled, the site-to-site communication public key can be exchanged in one of two ways:

• If the Active Directory schema has been extended for SMS and SMS 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 SMS does not have permissions to publish to Active Directory, the SMS 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 SMS is published in Active Directory.

For the procedure, see Manually Transferring Site Keys in Appendix E: “SMS Security Procedures.”

Before sending the site control file, the sending site generates a hash and signs it with its private key. The receiving site checks the signature by using the public key in the certificate 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.

Encrypted account information in the site control file

The following privileged accounts and passwords are stored in the site control file:

SMS Service account

SMS Server Connection accounts

Client Push Installation accounts

Because a serious security compromise could result if an attacker gains these credentials, they are encrypted within the site control file. The site control file itself is not encrypted when transferred between sites. Other accounts stored in the site control file do not require Administrator rights on any computers and generally have very low rights.

Note

By using advanced security, most operations are performed with the LocalSystem account or the computer accounts, removing the need to store those account credentials in the site control file. The SMS Service account, the Site System Connection account, the Server Connection account, and the Site System Database account are not used in advanced security. The Client Push Installation account is used only if Client Push Installation is enabled or invoked from the Client Push Installation Wizard. For more information about SMS Accounts, see Appendix C: SMS Accounts, Groups, and Passwords.

Client Authentication and Encryption

Client authentication and encryption are new features in SMS 2003 SP1. Authentication and encryption are not enabled by default. They provide greater security, but with some performance cost and administrative overhead. Enabling signing and encryption has a negligible effect on client performance. Management points can experience a minor performance hit, but this does not impact the number of clients that a management point can support.

You need to enable client authentication and encryption individually for each site. Ensure that the site and all clients have upgraded successfully to SMS 2003 SP1, and then enable encryption and signing for all sites in the hierarchy to avoid problems with roaming clients having their inventory rejected. After client inventory signing is enabled, you cannot disable it. For the procedures, see Enabling Client Signing and Encrypting of Inventory Data in Appendix E: “Appendix E: SMS Security Procedures.”

SMS uses the Secure Hash Algorithm 1 (SHA1) and 1024-bit RSA keys for inventory signing. Inventory is encrypted using 3DES Cipher Block Chaining (CBC). Clients generate self-signed certificates for signing and encryption, and then store them in the certificate store of the local computer in the \SMS\Certificates directory. They can be identified by their friendly names.

Note

Troubleshooting authentication and encryption on an Advanced Client computer that hosts the management point has been simplified by friendly names assigned to Advanced Client and management point certificates during SMS 2003 SP1 installation. However, when a site is upgraded to SMS SP1, existing certificates are not modified to add new friendly names.

Client Identity is determined based on the SMS Unique ID and the signing certificate. If the client must be reimaged and the current certificate is not exported first, a new certificate is generated. This causes the client to be identified as a new computer; therefore, the history of the client will not be associated with the new computer. Prior to reimaging a client, export the certificate, including the private key, and import it to the new computer. For more information about managing certificates, see the Help and Support Center.

The flow of signed messages from the Advanced Client to its management point is as follows:

1. The client retrieves the trusted root key and management point keys from the site server and management point

2. The client sends its identity key in a discovery data record (DDR).

3. The Discovery Data Manager on the site server inserts the key as Client Identity in the SMS site database.

4. The SMS 2003 SP1 client signs only inventory messages.

5. When a signed message arrives from the client, the management point determines whether the public key of the client is in the SMS site database.

   • If the key cannot be found, the message is marked as not verified.

   • If the client's public key is found in the database, the signature of the message is validated.

   • If the signature is valid, the message is marked as verified and the message is processed.

   • If the signature is not valid, the message is discarded and an error message is logged.

The flow of encrypted messages from the Advanced Client to its management point is as follows:

1. The client generates an inventory and encrypts it using its symmetrical encryption key. The client also signs the inventory by using the client identity key.

2. The inventory contains the encryption key encrypted using the management point keys.

3. The management point retrieves the encryption key from the inventory message by using its own key.

4. The management point decrypts the message.

   • If the management point fails to decrypt the message, the message is discarded and a status message is generated.

   • If the decryption succeeds, the message is sent to the site server for client identity verification and message processing.