Share via

Securing SMS Site Systems

  • Article

SMS uses a variety of site systems with specialized functions. Advanced Clients interact with management points. Management points interact with the site server and the SMS site database server. Clients might need a server locator point to find a management point. This unavoidably increases the attack surface of SMS across the enterprise. Failure to secure site servers, management points, CAPs, and SMS site database servers could allow an attacker to spoof site systems and distribute unauthorized software to SMS clients. Improperly secured site systems could also lead to a compromise of the site server. To mitigate these threats, each site system must be as secure as possible.

Use Windows Server 2003 Service Pack 1 for All Site Systems

Windows Server 2003 is the most secure Microsoft operating system, and the first one to benefit from the Trustworthy Computing Initiative. Because Windows Server 2003 was designed to be secure by default, it requires less effort to harden the operating system than Windows Server 2000. Also, Windows 2003 Server includes IIS 6.0, which is significantly more secure than IIS 5.0. Windows Server 2003 Service Pack (SP) 1 added further security enhancements and is therefore recommended platform for all SMS site systems.

Security Configuration Wizard

Introduced in Windows Server 2003 SP1, the Security Configuration Wizard helps you create a security policy that you can apply to any server on your network. The Security Configuration Wizard recognizes SMS server roles, services, ports, and applications, but might not recognize all of the configurations required by SMS. The following section details which configurations are not automatically configured by the Security Configuration Wizard and the additional configurations required to keep SMS functioning properly.

Note

For more information about the SMS roles and features recognized by the Security Configuration Wizard, view the configuration database while running the wizard.

Enable Remote WMI in the Security Configuration Wizard for remote site database servers

The Security Configuration Wizard is unable to recognize the SMS Provider. If you run the wizard on the server that has the SMS Provider installed, you must enable the Remote WMI service on the Select Administration and Other Options page of the Security Configuration Wizard. Unless you enable Remote WMI, the SMS Administrator console on the site server and any other remote consoles will fail to connect to the SMS namespace in WMI.

Enable the SMS Database Monitor ports on remote SMS site database servers

If your SMS site database server is not on the same computer as the SMS site server, the Security Configuration Wizard correctly enables the SMS Database Monitor service (SMS_SQL_Monitor_<ServerName>) but it does not enable the ports used by the SMS Database Monitor service. On the Open Ports and Approve Applications page of the wizard, select Ports used by SMS_SQL_MONITOR_< ServerName >. If the SMS site database server is on the same computer as the SMS site server, enabling ports is not required.

When you run the Security Configuration Wizard on a BITS-enabled distribution point, you must select Remote administration for IIS and related components on the Installed Options page of the wizard. If Remote administration for IIS and related components is not enabled, the wizard blocks the SMS Distribution Manager service from creating virtual directories on the BITS-enabled distribution point.

Deselect the CAP role if it is not on the site server

The Security Configuration Wizard always identifies a site server as having a Client Access Point (CAP), whether or not the site server is actually assigned that role. If the site server on which you are running the wizard is not assigned the CAP, deselect it on the Select Administration and Other Options page.

Re-run the Wizard after changing site system roles

If you run the Security Configuration Wizard on a server and then configure a site role on that server, you should re-run the wizard to ensure the site system roles function properly.

Use Role Separation on Site Systems

It is possible to install all of the site system roles on a single computer, but it is usually not advisable because it creates a single point of failure. However, there are a few exceptions to the concept of role separation.

It is usually preferable to install a dedicated version of SQL Server on the same computer as the site server and use that as the SMS site database server. This configuration allows SMS the greatest control of the SQL configuration and simplifies the security configuration for SQL Server.

By default, a client access point (CAP) is always installed on the site server. It is not possible to remove the last CAP from the site, even if there are no Legacy Clients. If you do not have Legacy Clients, you can leave the CAP role on the site system and follow the recommended best practices for disabling client access to the CAP as described later in this document.

Reduce the attack profile

Isolating each site server role on a different server reduced the chances that an attack against vulnerabilities in one site system can be used against a different site system. Many site system roles require the installation of IIS on the site system. Installing IIS increases the attack surface. If you must combine site system roles to reduce hardware expenditures, combine roles requiring IIS only with other roles requiring IIS.

Improve recoverability

It is common in small sites for all roles to be installed on the site server. This increases the risk that if the site server is unavailable, all SMS functionality is disabled. If possible, configure a management point that is not on the site server to increase availability to the clients. Configure multiple reporting points and distribution points. You cannot create more than one default management point for the site, but you can use a computer with RAID, or other fault tolerant features. Alternately, you can keep a spare management point running, and configure it as the default if the first management point goes offline.

Note

SMS 2003 does not support clustering for any site system roles, including the SMS site database server.

In a central site without Active Directory schema extensions and publishing, always use a separate management point

If the Active Directory schema has not been extended and if SMS does not have permissions to publish to Active Directory, SMS uses the trusted root key to authenticate management points to clients. The trusted root key at the central site server is used to sign the certificate of the management point. If the central site has to be recovered, clients will continue to trust the management points until a new trusted root key is generated at the rebuilt central site server. If a management point has to be recovered, clients will trust the new management point as soon as the management point certificates are signed by the trusted root key.

Problems can arise if clients are reporting to a central site server that also functions as the management point for the site. In this case, recovering the site server means that you must create a new trusted root key and a new certificate for a new management point. Because the client no longer has a trusted management point or trusted root key, you must delete the old trusted root key on the client before it can obtain the new key. To avoid this situation, extend the Active Directory schema and enable publishing for the site. If this is not possible, do not assign the management point role to the central site server if there are clients reporting to the central site. This scenario is most common in a small SMS deployment where there is only one site.

For more information, see Appendix B: Appendix B: SMS Certificate Infrastructure.

Do Not Remove the Admin$ Share on Site Systems

The Admin$ share on site systems is required by SMS and should not be disabled or removed. The SMS site server uses the Admin$ share to connect to and perform service operations on site systems.