Securing SMS Communications

SMS activity is never confined to a single computer. Examples include:

• The site server communicates with all site systems.

• Clients communicate with management points or client access points (CAPs).

• All domain members communicate with the domain controllers for authentication and authorization.

• Site hierarchies can be installed spanning wide area network (WAN) links with firewalls and virtual private networks (VPNs).

If you fail to secure SMS communications between sites, clients could be hijacked by unauthorized servers, high-rights credentials could be exposed, or bogus data could be inserted into SMS site database.

*SPThe reporting feature in SMS 2003 SP1 has been updated to support HTTPS. Client signing and encryption makes it more difficult to tamper with client data as it crosses the network. *SP

Disable Unsigned Communications Between Sites, Even in a Single Site Hierarchy

SMS 2003 signs all data sent between sites using private/public key pairs. SMS 2.0 sites that have not been upgraded to SP5 do not sign their data, so those SMS 2.0 sites cannot communicate securely with SMS 2003 sites. If you must support SMS 2.0 sites that are running SP4 in your SMS hierarchy, do not accept any unsigned data sent from that site to the parent site. This can result in the loss of some data sent from the SMS 2.0 SP4 child site, but mitigates the larger threat of forged communications from a parent site that could cause unauthorized software to be installed. Plan to upgrade all sites to SMS 2.0 SP5 or SMS 2003.

Note

SMS 2.0 sites that will report to an upgraded site must be running SMS 2.0 SP4 or later before the parent site is upgraded to SMS 2003.

Even if you have only one site in your hierarchy, disable unsigned communication between sites to reduce the risk of an attacker sending a bogus site control file from a non-existent parent or child site.

For the procedure, see Disabling Unsigned Communications Between Sites in Appendix E: “Appendix E: SMS Security Procedures.” For more information about the signed communication between SMS sites, see Signing Site-to-Site Communications in Appendix B: “Appendix B: SMS Certificate Infrastructure.”

Require Secure Key Exchange

The default configuration of a primary site implements a less secure key exchange algorithm that allows SMS 2003 sites to exchange the keys used for signing data transfers between sites. SMS 2.0 sites that have not been upgraded to SP5 cannot participate in secure key exchange. Even if you only have one site in your hierarchy, require secure key exchange between sites to reduce the risk of an attacker sending a bogus site control file from a nonexistent parent or child site. After you enable this setting, SMS exchanges keys through Active Directory if the schema has been extended and if SMS has permissions to publish to Active Directory. If the schema has not been extended or if SMS does not have the permissions to publish to Active Directory, the administrator must exchange the keys through the manual process.

Important

Regardless of whether you have extended the Active Directory schema, you must manually perform the initial key exchange between a parent site and a newly installed secondary site. If you do not manually transfer the key, the secondary site installs successfully but is unable to properly establish a connection to the parent site. After you manually transfer the key, the secondary site can connect to the parent site, allowing you to manage the secondary site from the parent site. After the secondary site is successfully connected to the parent site, you can change the site properties of the newly installed secondary site to Require Secure Key Exchange. The secondary site can then complete all future key exchanges through Active Directory (if the schema has been extended.).

For the procedures, see Requiring Secure Key Exchange and Manually Transferring Site Keys in Appendix E: “Appendix E: SMS Security Procedures.” For more information about the key exchange in SMS, see Signing Site-to-Site Communications in Appendix B: “Appendix B: SMS Certificate Infrastructure.”

Ensure that Advanced Clients Get an Authorized Copy of the Trusted Root Key upon Installation (Necessary Only If You Have Not Extended the Schema)

If you have not extended the Active Directory schema, clients rely on the trusted root key to authenticate valid management points. Without the trusted root key, the client has no way to verify that the management point is authorized in the site, allowing a skilled attacker to direct the client to an unauthorized management point. In SMS 2003 (without SP1) the client does not receive the trusted root key during installation but requests a copy of the key from the management point. In SMS 2003 SP1, clients 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 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: “SMS Feature Security (Appendix E: SMS Security Procedures).”

If you have already deployed your Advanced Clients without installing the trusted root key, the clients likely obtained a valid trusted root key and are already communicating securely with authorized management points. To verify that the trusted root key has been installed, see the procedure Verifying the Installation of the Trusted Root Key in Appendix E: “Appendix E: SMS Security Procedures.”

If you plan to move a client from one site hierarchy to another, you must remove the trusted root key before moving the client to the new hierarchy; otherwise, it will fail to communicate with the new management point. After you remove the trusted root key, you should force its installation for the new site. For the procedures, see Removing the Trusted Root Key and Reinstalling the Trusted Root Key in Appendix E: “Appendix E: SMS Security Procedures.”

Use IPsec to Encrypt Communications between Site Systems and the Site Server

Impersonation of SMS site systems can lead to compromise of SMS infrastructure. IPsec can help protect against attacks where an unauthorized site system impersonates a valid site system and uses the trusted connection to gain control of the site server or the site system database. To mitigate this threat, configure IPsec communications between most SMS site systems. Not all site systems should be members of the SMS IPsec group.

Run Internet Protocol Security (IPsec) for communications between the following computers:

• Primary site servers

• Secondary site servers

• Management points

• Reporting points

• Server locator points

• Client access points (CAPs)

• Remote SMS site database computers

Do not include distribution points unless the computer on which the distribution point role is enabled is already included because of another site system role. Do not include domain controllers.

Create an IPsec policy that requires ESP/3DES between the specified site systems. Use HOSTS and LMHOSTS files instead of Domain Name Service (DNS) and Windows Internet Name Service (WINS) to prevent attackers from impersonating valid site systems through name resolution attacks. Limit access to the specified site systems by limiting the computers that can be authenticated by IPsec Internet Key Exchange (IKE) with the SMS IPsec policy. The most secure way to limit access is to use certificate authentication from an offline root Certificate Authority (CA) that is dedicated only to the purpose of issuing certificates for use with SMS IPsec.

For detailed information about the recommended IPsec configuration for SMS, see Appendix G: “Appendix G: Recommended Configuration for IPsec with SMS.”

Configure Your Firewalls to Permit Required SMS Traffic

Firewalls can exist in many places throughout the network. Most networks use a perimeter firewall to prevent unauthorized Internet traffic from reaching the internal network, but many networks use additional firewalls internally to create secure network zones. For example, you might put a firewall on the lab network to prevent lab experiments from accidentally reaching the corporate network. Many client computers can run personal firewalls to provide defense in depth.

Perimeter firewalls

Security best practice dictates that you deny all ports in your firewall, except those explicitly configured. SMS is a complicated product requiring many ports for proper communication. For a comprehensive list of the ports required for SMS communications, see article number 826852 in the Microsoft Knowledge Base.

Note

In SMS 2003 (without SP1) Advanced Clients and management points are hard-coded to use port 80 when communicating with management points and server locator points. In SMS 2003 SP1, you can change the port. For more information, see “Consider Configuring the Advanced Client to Use a Non-Default HTTP Port” later in this document.

Client personal firewalls

Microsoft Windows® XP has a built in Internet Connection Firewall. In Windows XP SP2, this firewall was upgraded and renamed the Windows Firewall. The default configuration of Windows Firewall interferes with certain SMS operations. Evaluate the risk of reducing Windows Firewall restrictions against the benefit of SMS manageability. When you add an SMS port or a program to the exception list, change the scope to a custom list that allows communication only with the necessary SMS computers. Consider using Group Policy to create consistent configurations for Windows Firewall on all Windows XP SP2 clients.

Table 2   SMS Features That Might Be Impacted by Windows XP SP2

For the procedure to configure the Windows Firewall for Windows XP SP2, refer to the Windows XP Help and Support Center.

*SP Consider Configuring the Advanced Client to Use a Non-Default HTTP Port

SMS 2003 SP1 allows you to change the TCP port used to communicate with management points, server locator points, and BITS-enabled distribution points. Many organizations block TCP port 80 as a security precaution.

You configure ports on a site-by-site basis. However, if you do not configure the same ports in all sites in the hierarchy, the Advanced Clients can experience problems when roaming. To properly migrate to a new port, you should do the following.

1. Upgrade all existing Advanced Clients to SP1.

2. Configure all sites in the hierarchy to use the new port as the default port.

3. Deploy a package for the portswitch.vbs script to migrate all existing clients to the new port.

4. Verify that all Advanced Clients are using the new port.

5. Configure all sites in the hierarchy not to use the old port.

To change the ports used by the site systems, modify the Ports tab on the site property sheet. If you have not deployed Advanced Clients anywhere in your hierarchy, you can add a different port, set it to be the default port, and remove port 80 from the list. Advanced Clients that are newly installed using the Client Push method are configured to communicate on the default port. Advanced Clients installed locally using CCMSetup will not be aware of the default port change and you will need to use the CCMHTTPPORT option (i.e. CCMSetup.exe CCMHTTPPORT:8080). Making changes in the Ports tab has no affect on the port used by existing Advanced Clients.

Use the Portswitch.vbs script on the SMS CD to change the client port on existing Advanced Clients. Deploy Portswitch.vbs as a software distribution package and set the program to Run with administrative rights. After you have distributed the package, enable the SMS Advanced Client Ports class in the SMS_def.mof to collect Advanced Client port information through hardware inventory.

Important

If you remove port 80 from the site properties while existing Advanced Clients are configured to use that port, those clients will become orphans.

For the procedure to change the TCP port used by the Advanced Clients, see Configuring the Advanced Client TCP Port in Appendix E: Appendix E: SMS Security Procedures. For more information about using Advanced Client Installer, see Appendix I: “Installing and Configuring SMS Clients” in Scenarios and Procedures for Microsoft Systems Management Server 2003: Planning and Deployment (https://go.microsoft.com/fwlink/?linkid=29105). For detailed information about Portswitch.vbs, see the documentation included with the script on the product CD. *SP

*SP Enable Signing and Encryption of Advanced Client Data

By default, an SMS 2003 SP1 Advanced Client does not sign or encrypt messages. Reading client inventory and discovery data records (DDRs) on the network is usually not considered a high risk, but high security environments should encrypt all client-initiated communication, such as inventory and DDRs. Receiving invalid data through unauthorized clients presents a higher risk to site security, but is a relatively sophisticated attack. Enabling signing Advanced Client inventory reduces this risk.

Before you enable encryption for inventory messages, ensure that the site and its clients upgrade successfully to SMS 2003 SP1; otherwise, clients that have not yet upgraded will have their inventory rejected.

Important

After client inventory signing is enabled for a site, you cannot disable it. After SMS receives signed data from a client, it always requires signed data from that client because unsigned data could be sent by an attacker.

For the procedure to enable client authentication and encryption, see Enabling Client Signing and Encrypting of Inventory Data in Appendix E: “Appendix E: SMS Security Procedures.”

For more information about client signing and encryption, see Appendix B: Appendix B: SMS Certificate Infrastructure.

Note

SMS 2003 SP1 is supported only on Windows 2000 SP2 or later, but might install on earlier versions of Windows 2000. In this case, the cryptographic service provider used by SMS will fail to start and client communication will not be encrypted. However, client communication can still be signed.

Enable client signing at all sites to avoid rejecting data from clients changing site assignments

You are not required to enable client signing at all sites in the hierarchy. However, failing to do so can cause SMS to reject client inventory and discovery data records (DDRs) when a client is reassigned from a site that requires signing to a site that does not require signing.

When you reassign a client from one site to another, the client sends its identity key in a DDR to the new management point, which passes the DDR to the site server. Even if the new site does not require client signing, the Discovery Data Manager on the site server inserts the key as Client Identity in the SMS site database. All future messages from the client with that GUID must be signed by that key, even if the site policy does not require signing. At some point after being assigned to the new site, the client will receive the new site policy stating that signing is not required and future messages will not be signed. Although signing is not required, the site server still requires the key because it was already received and stored in the database, and consequently and will reject any inventory sent by the client. The site server will also request an inventory resynchronization, but will reject the unsigned inventory resynchronization sent by the client. Status message 682 indicates that data was rejected because the file was signed, but the authentication key did not match the recorded key for the client.

If you must reassign clients from a site that requires signing to another site in the hierarchy that does not require signing, you must do the following:

1. Wait until there is no pending inventory from that client anywhere in the hierarchy.

2. Unassign the client from its current site.

3. Delete the client record in that site and all parent sites.

Important

You must delete all client records in the hierarchy so that all Client Identity information is removed from every database. If you delete the client record only at the current site, a parent site might still have the Client Identity and would reject any unsigned data, even if it was accepted by a site lower in the hierarchy.

1. Assign the client to the new site.

If you have roaming clients, wait until all sites are upgraded to SMS SP1 before enabling client encryption, and then enable across all sites.

SMS 2003 (without SP1) does not support client encryption. If you have a mix of SP1 sites and sites with no service pack, clients who roam might have their inventory rejected. Client encryption is not enabled by default, even after upgrading to SP1. *SP