Creating a Secure Hierarchy

Security considerations might influence your need for and placement of SMS sites or site systems in the design of your hierarchy. Security considerations can be important when deploying clients. Incorporate security efforts as early as possible in your deployment plan so that your SMS implementation is functional and secure. If you have already deployed SMS, revisit your design decisions and analyze them from a security perspective.

Do Not Allow SMS Sites to Span Forests

Domains are not considered security boundaries in Active Directory. They provide some delegation of administrative duties, but unauthorized administrators in one domain have methods of gaining administrative rights at the root of the forest, and thus gaining rights to the whole forest. The only way to ensure administrative boundaries in Active Directory is to create a separate forest.

While it might be possible to design your SMS site such that it spans the forests, this kind of site design is not supported by SMS 2003. The SMS site server must have administrative access to all site systems. To grant an SMS account from one forest administrative access to a site system in another forest would violate this security boundary. Therefore, you must have at least one SMS site in each forest and design the site so that it does not span forests.

If you require multiple SMS sites in multiple Active Directory forests, each forest must have at least one primary site. A secondary child site cannot attach to a parent in a different forest.

Use the Fewest Sites Possible

Having a large number of sites represents a fairly low risk, but reducing the number of sites reduces the attack surface and should be considered when designing deployments. Reducing the number of sites for security must be weighed carefully against other design considerations, like bandwidth, performance, and client configuration. A single site is the most secure option because there is no need to do the following:

• Transfer data between sites

• Manage sender accounts between sites

• Trust administrators at other sites

Performance enhancements in SMS 2003 allow a single site to support more clients, making it possible to consolidate sites that were divided for performance reasons. If you already have a multi-site SMS implementation, you might be able to support more clients after you switch to the Advanced Client. You might be able to replace smaller sites with protected distribution points and thus reduce the number of sites, if this is consistent with your other design goals.

For more information about designing and deploying SMS 2003, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Planning and Deployment on Microsoft TechNet (https://go.microsoft.com/fwlink/?LinkId=19627).

Install SMS on a Member Server Instead of a Domain Controller

SMS does not require installation on a domain controller. Domain controllers do not have a local Security Accounts Management (SAM) database other than the domain database. Installing SMS on a member server allows you to maintain SMS accounts in the local SAM database, instead of the domain database.

Do Not Interoperate with Sites That Cannot Sign Their Data

SMS 2.0 sites before SP5 cannot sign their intersite communication. Failure to sign intersite communication could allow an attacker to push unauthorized software to child sites and should be considered a significant risk. Plan to upgrade all sites to SMS 2.0 SP5 or SMS 2003 as quickly as possible.

Use the Fewest Management Points Possible

Advanced Clients can be assigned only to sites with management points. Having a management point at every primary site does not constitute a high security risk, but reducing the number of management points does reduce the attack surface. Management points require Internet Information Services (IIS). Some companies have policies about reducing the number of IIS servers in order to reduce the attack surface of their networks. If this is a strong concern for you, it is possible to install the fewest management points possible.

Theoretically, all Advanced Clients could be assigned to one site, although the clients would be physically located within the boundaries of a different site. The assigned site would have the only management point for the entire hierarchy. Advanced Clients who are located at any other site would be considered roaming clients, even if they never leave that site, because they are not in the boundaries of the site containing the management point.

When the Advanced Clients make a request for a management point, because there is no management point at their current location, they will contact their assigned management point at their assigned site to request policy, upload inventory data, request package source location, and upload status messages. The Advanced Client could still retrieve packages from a distribution point on the site in which it is physically located, if the content is available there. It must be understood that this configuration could have serious impact on bandwidth. Balance your other design considerations against the need to reduce the number of IIS servers.

Advanced Clients cannot be assigned to secondary sites. If you have secondary sites, you can configure proxy management points at the secondary sites to better control how SMS Advanced Clients use the available bandwidth. The proxy management point must have access to either the SMS site database at the parent site or a replicated database. Using secondary sites with no proxy management points is the more secure configuration because it reduces the attack surface, but the risk is slight and can be considered acceptable if required for performance reasons.

Do Not Remotely Install or Uninstall Secondary Sites by Using the Create Secondary Site Wizard in the SMS Administrator Console (Advanced Security Only)

When you create a secondary site, you can install the secondary site by:

• Running the installation files from the secondary site server.

• Using the SMS Administrator console at the primary site.

When you use advanced security, most SMS operations are performed using the site server’s computer account. If you use the SMS Administrator console at the primary site to run the Create Secondary Site Wizard, the primary site’s computer account must be a member of the local Administrators group of the secondary site server which is excessive privilege for normal operations. Instead, run the installation files from the secondary site server, so you can use a non-Administrative Site Address account.

Do Not Install Other Services that Use the Local System Account (Advanced Security Only)

Minimize the use of the LocalSystem account on the site servers and site systems by not installing other services that use the LocalSystem account. This ensures that other processes cannot take advantage of the enhanced privileges of the system’s computer account, accessing SMS files and data through those other systems. If you run SQL Server on the same computer as the site server, configure SQL Server to run under a domain user account.

Create a Service Continuity Plan

Security personnel are usually required to design for the confidentiality, integrity and availability of computer systems. In order to keep the SMS hierarchy available, it is important to have a plan to provide service continuity and test it often.

Design a fault tolerant site

There is usually a low risk associated with a site being offline unless there is an urgent need to deploy a critical update. If the SMS site server is offline, it does not necessarily stop all SMS operations.

Table 1    Fault Tolerant Operations

Configure multiple distribution points and reporting points. Plan for a backup management point that can take over if the default management point fails. Clustering of the computer running SQL Server is not supported. To provide greater fault tolerance, you can set up SQL Server database replication and, if the computer running SQL Server goes offline, direct the management point to connect to the replicated tables. This assumes that replication has completed successfully before the computer running SQL Server fails.

Plan for a fault tolerant Active Directory infrastructure by having multiple domain controllers online and more than one global catalog server. Use Active Directory integrated Domain Name System (DNS) to provide fault-tolerant DNS services.

Create a backup and recovery plan

Recovering a failed SMS site is a complex task. For more information, refer to Scenarios and Procedures for Microsoft Systems Management Server 2003: Backup, Recovery and Maintenance on the Microsoft Download site (https://go.microsoft.com/fwlink/?LinkId=31434).

Secure your backup media

The SMS backup task makes copies of the registry, the file structure, and the SMS site database. Attackers who gain access to the backup media could gain valuable information about the network, such as IP addresses, Active Directory site names, and the state of all client computers. Attacks involving backup media are potentially as serious as physical attacks against servers. As with all backups, store SMS backup media in a secure location and institute a controlled procedure to check out and restore the media.