Network Security

You should understand network security concepts so that traffic between SMS sites, SMS site systems, and SMS clients is kept secure. SMS can use encryption, hashing, and signing algorithms when sending data across a network connection.

Encryption, Hashing, and Signing

Encrypting data is required to either ensure that data cannot be read or modified by unauthorized people or programs, or to ensure that it came from a known source. Encrypting data is particularly important when the data is not always contained within a secure environment, for example if the data is transferred over a shared network.

A common method for encrypting data involves the use of pairs of public and private keys. The keys are large, randomly generated, numbers or strings of characters. The private key is securely kept at the computer where the keys are generated. The public key can be available to any other computer that can use it.

The data is encrypted by using either the private key of the originating computer or the public key of the receiving computer and then sent out. The receiving computer decrypts the data using the corresponding public or private key, which is the only key that can decrypt data encrypted by the other key.

Encrypting data by using algorithms based on public and private keys is very slow, especially for large amounts of data. To avoid this issue, a small amount of predefined data, known as a signature, can be encrypted and sent with the rest of the data. The receiving computer can decrypt the signature to ensure it is valid. If it is valid, the rest of the data is valid, even though it is not encrypted.

If it is important to ensure that the data accompanying the signature has not been changed, a hash value can be calculated for the data when it is sent and included with the signature. The hash value is then recalculated when the data is received and the two hash values are compared. If the hash values are the same, the data has not been modified. Hash values can be calculated in a wide variety of ways, but generally they are based on the size of the file and regular samplings of the contents.

SMS 2003 signs all data sent between sites using private/public encryption key pairs. SMS does not encrypt or hash site-to-site communications, except for the following exceptions:

• Packages have hash values, which SMS signs.

• SMS encrypts SMS account names and passwords.

The sending site signs the data it sends using its private key and places the signature in the instruction file for the data being sent. The receiving site then verifies the signature by using the sending site's public key. If the signature cannot be verified, the data is rejected. 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 or earlier in your SMS hierarchy, and you do not want to accept any unsigned data sent from that site to the parent site, then you set that option through the SMS Administrator console. Navigate to the Advanced tab in the Site Property dialog box for the SMS 2003 site that is the parent of the SMS 2.0 SP4 site, and enable the option. Do not accept unsigned data from sites that are running SMS 2.0 SP4 and earlier. This ensures that the parent site only accepts signed data, but it can result in the loss of some data sent from the SMS 2.0 SP4 or earlier child site.

The keys are generated at each site when the sites are set up. The value of the private key is only known by the operating system of the site server. The keys change when the SMS Service Account is changed for the site. The site automatically transfers the new public key to its parent site and all its direct child sites.

Sites can exchange keys most securely by:

• Receiving the intersite key exchange files during the establishment of a parent/child site relationship and then verifying their validity by reading the public keys from Active Directory. The serviceBindingInformation attribute of mSSMSSite objects are used to store the public key for each site. The ability to write public keys to Active Directory requires significant rights, so this ensures that the site is not a rogue site. This method of key exchange happens automatically, but it requires Active Directory and that the account being used to set up the sites has sufficient rights to write to the Active Directory objects. This method also does not work across forests.

• Manually transferring the keys by running the SMS Preinst.exe tool with the appropriate switches and then transferring the generated files using your rights. Table 5.1 lists the relevant Preinst.exe switches. Preinst.exe is in the \SMS\bin\i386\<language code> directory on your SMS 2003 or SMS 2.0 SP5 site server.

• Enabling the Require secure key exchange between sites option on the Advanced tab in the Site Property dialog box to ensure that only trusted keys are exchanged between sites.

Table 5.1 Preinst.exe Switches for Exchanging Site Keys

SMB Signing

Server message block (SMB) is a network protocol that is commonly used by Windows systems and by SMS to transfer files between computers. Without SMB signing, a device could intercept SMB network packets from an originating computer, alter their contents, and broadcast them to the destination computer. Where this is a concern, SMB signing should be enabled or required. SMB signing is available for computers that are running Windows NT 4.0 SP3 or later.

In order to use SMB signing, you must either enable it or require it on both the client and the server. If SMB signing is enabled on a server, clients that are also enabled for SMB signing use the signed SMB protocol during all subsequent sessions and clients that are not enabled for SMB signing use the original SMB protocol. If SMB signing is required on a server, then a client cannot establish a session unless it is enabled for SMB signing. SMB signing is disabled by default on servers and clients running Windows operating systems.

The registry values for enabling or requiring SMB signing are:

• On the server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters Value Name: EnableSecuritySignature Data Type: REG_DWORD Data: 0 (disabled, the default), 1 (enabled) Name: RequireSecuritySignature Type: REG_DWORD Value: 0 (disabled, the default), 1 (enabled)

• On the client:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters Value Name: EnableSecuritySignature Data Type: REG_DWORD Data: 0 (disabled, the default), 1 (enabled) Name: RequireSecuritySignature Type: REG_DWORD Value: 0 (disabled, the default), 1 (enabled)

Important:

• Using SMB signing slows down performance. Use this setting only when network security is a concern. The decrease in network throughput performance usually averages between 10 to 15%. SMB signing requires that every packet is signed and every packet must be verified.

Management Point Communications

Management points and proxy management points communicate with the SMS site database for policy and assignment data. It might be possible for such communications to be compromised. Therefore it is recommended that you implement one or more of the following solutions to secure communications between management points and the SMS site database:

• Install the management point, the SMS site database, and the SMS site server on same physical computer.

• Isolate the management point, the SMS site database, and the SMS site server on a private network and secure the private network.

• Run Internet Protocol Security (IPSEC), or SMB signing for communications between the management point, the SMS site database, and the SMS site server.

It is recommended that you use IPSEC to secure communications between proxy management points and the SMS site database.

For More Information

Did you find this information useful? Please send your suggestions and comments about the documentation to smsdocs@microsoft.com.