Use role separation on site systems    It is possible to install all of the site system roles on a single computer, but this practice 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 site database server. This configuration allows Configuration Manager 2007 the greatest control of the database configuration and simplifies the security configuration for SQL Server.

Reduce the attack profile     Isolating each site server role on a different server reduces the chance 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 Internet Information Services (IIS) on the site system. For more information, see Prerequisites for Installing Configuration Manager. 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.

Important
The exception to the suggestion to combine site system roles requiring IIS is the fallback status point. The fallback status point role should never be assigned to any other Configuration Manager 2007 site system role because it accepts unauthenticated data from clients, even in native mode.

Run the Security Configuration Wizard on all site systems    The Security Configuration Wizard (SCW) helps you create a security policy that you can apply to any server on your network. After installing the Configuration Manager 2007 template, SCW recognizes Configuration Manager 2007 server roles, services, ports, and applications and permits necessary traffic while blocking communications determined to be unnecessary. The Configuration Manager 2007 template for SCW is scheduled to ship in the Configuration Manager 2007 Toolkit (http://go.microsoft.com/fwlink/?LinkId=93071).

Use NTFS for all site systems     While some site systems allow the use of FAT32 partitions, you should always use NTFS to allow file level access control.

Do not remove the admin$ share on site systems    The Admin$ share on site systems is required by Configuration Manager 2007 and should not be disabled or removed. The Configuration Manager 2007 site server uses the Admin$ share to connect to and perform service operations on site systems.

Closely monitor Internet-based site settings on site systems    The Configuration Manager 2007 console does not prevent you from configuring a site role to support Internet-based clients, even though it is not supported as an Internet-based site role. For example, after a branch distribution point is created, you could configure the site system properties for that role to use an Internet FQDN and to allow Internet connections, even though branch distribution points are not allowed to support Internet-based clients. Periodically monitor the Internet configurations of your site systems.

Configure static IP addresses for site systems    Static IP addresses aid in configuring IPsec between site systems, which is a recommended best practice. Static IP addresses are easier to protect from name resolution attacks.

Use FQDN server names    Even though FQDN server names are required only in certain scenarios, such as when supporting Internet-based client management or using IPv6, you should configure FQDN server names for all site systems because the FQDN configuration uses DNS instead of WINS for name resolution, and DNS can be more securely managed than WINS. For more information, see Determine If You Will Use FQDN Server Names.

Do not install other services that use the Local System account    Minimize the use of the Local System account on the site servers and site systems by not installing other services that use the Local System account. This ensures that other processes cannot take advantage of the enhanced privileges of the system’s computer account, accessing Configuration Manager 2007 files and data through those other systems. Configure SQL Server to run under a domain user account instead of Local System.

Note

IIS requires Local System, but you cannot avoid installing IIS on site systems because many site system roles require it. To reduce the risk of an attacker compromising IIS and then using Local System to compromise Configuration Manager 2007 servers, do not run non-Configuration Manager 2007 Web applications and use role separation for site system roles requiring IIS, as described later in this section.

Install Configuration Manager 2007 on a member server instead of a domain controller    The Configuration Manager 2007 site server and site systems do 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 Configuration Manager 2007 on a member server allows you to maintain Configuration Manager 2007 accounts in the local SAM database instead of in the domain database. It also lowers the attack surface on your domain controllers.

Install secondary sites at the secondary site server instead of using push installation     It is theoretically possible for an attacker to hijack the secondary site installation package and tamper with the files prior to installation, although timing this attack would be difficult. An attack can be mitigated by using IPsec to mutually authenticate the primary and secondary site server before transferring the files. Also, if you use push installation, 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.

Configuration Manager 2007 uses SQL Server as the back-end database. If the database is compromised, attackers could bypass the Configuration Manager 2007 console and access SQL Server directly to launch attacks through Configuration Manager 2007. Attacks against the SQL Server must be considered very high risk and mitigated appropriately.

Use a dedicated SQL Server for each site    Although multiple sites can share a single computer running SQL Server to store data, this is not a recommended configuration. If one Configuration Manager 2007 site database is compromised on one SQL Server, the attacker has easier access to another Configuration Manager 2007 site database on the same SQL Server. Sharing a SQL Server between sites can make it more difficult to recover your site, which could delay Configuration Manager 2007 from functioning at a critical time. If a site was sharing a SQL Server with another site and it failed, you must ensure that the recovery process of the failed site does not affect the other healthy sites. The recovery process becomes more complicated in this situation because you must isolate the recovery procedures to only the failed site.

Do not use the Configuration Manager site database server to run other SQL Server applications     Increasing access to the Configuration Manager 2007 site database server increases the risk to your Configuration Manager 2007 data. Also, if the Configuration Manager 2007 site database is compromised, other applications on the same SQL Server computer are at risk.

Configure SQL Server to use Windows authentication      Configuration Manager 2007 will always access the site database using a Windows account and Windows authentication, but it is still possible to configure SQL Server to use SQL Server mixed mode. SQL Server mixed mode allows for configuring additional SQL logins to access the database, which is not required and increases the attack surface.

Install Configuration Manager and SQL Server on the same computer     Installing SQL Server and Configuration Manager 2007 on the same computer might seem to violate the idea of role separation to increase availability, but it is not a significant security concern. If either the Configuration Manager 2007 site database or the site server go offline, the other server is virtually useless. Installing Configuration Manager 2007 and SQL Server on the same computer simplifies SQL Server configuration and thus reduces the risk of making security-related mistakes.

Follow security best practices for SQL Server    Follow the best practices for SQL Server 2005 http://go.microsoft.com/fwlink/?LinkId=95071, with the following additional considerations:

• The site server computer account must be a member of the Administrators group on the computer running SQL Server. If you follow the recommendation "Provision admin principals explicitly," the account used to run Setup on the site server must be a member of the SQL Users group.
  
  
• If you install SQL Server using a domain user account, you must ensure that a Service Principal Name (SPN) is populated to Active Directory Domain Services or Kerberos authentication will fail and Configuration Manager 2007 Setup will fail. For more information, see How to Configure an SPN for SQL Server Site Database Servers.
  
  

Several server roles require IIS. Securing IIS properly allows Configuration Manager 2007 to function while reducing risk. Where practical, minimize the use of servers requiring IIS. For example, consolidate management points into the smallest number possible. Use only a single server locator point for your environment.

Disable IIS functions that you do not require     Install only the minimum IIS features for the server role you are supporting. For more information, see Prerequisites for Installing Configuration Manager.

Do not put the site server on a computer with IIS    Role separation helps reduce the attack profile and improve recoverability. Also, the site server’s computer account usually has administrative privileges on all site system roles (and possibly on Configuration Manager 2007 clients, if using Client Push Installation). IIS and Configuration Manager 2007 both run by using the Local System account, so an attacker who can compromise IIS running on the site server could gain Local System access to all Configuration Manager 2007 functions.

Use dedicated IIS servers for Configuration Manager   While it is possible to host multiple Web-based applications on the IIS servers used by Configuration Manager 2007, this can significantly increase your attack surface. A poorly configured application could allow an attacker to gain control of the co-located site systems, which could allow an attacker to gain control of the entire site. If you must run other Web-based applications on Configuration Manager 2007 site systems, you should always create a custom Web site for Configuration Manager 2007 site systems. For more information, see How to Configure Custom Web Sites for Configuration Manager Sites.

In a single site hierarchy that requires trusted root key authentication, always use a separate management point    If the Active Directory schema has not been extended and if Configuration Manager 2007 does not have permissions to publish to Active Directory Domain Services, Configuration Manager 2007 clients use the trusted root key to authenticate management points before communicating. 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. Also, 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. However, if clients are reporting to a central site server that also functions as the management point for the site, and that computer is recovered, clients will not trust that management point until you delete the current trusted root key on the clients and reprovision them with the new trusted root 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. For more information about the trusted root key, see About the Trusted Root Key.

If this site system role is configured in a perimeter network, configure the site server to retrieve the data from the site system    By default, site systems push their data back to the site server. A site system can be configured to require the site server to pull the data instead, which allows great control of the ports and permissions required for the data transfer. The setting Allow only site server initiated data transfers from this site system applies to the entire site system and all site system roles configured on it.

Use the fewest management points possible    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 IIS. To reduce the attack surface of their networks, some companies have policies about reducing the number of IIS servers. If this is a strong concern for you, it is possible to install the fewest management points possible by assigning all clients to a single site and treating them as roaming clients at their resident site.

Do not co-locate any other site system roles with the fallback status point    The fallback status point is designed to accept unauthenticated communication from any computer. Co-locating the fallback status point with any other site role greatly increases the risk to that site role.

Do not install the fallback status point on a domain controller    

In native mode, deploy the fallback status point prior to deploying clients    A native mode site without a fallback status point could cause a situation where you are unaware that high numbers of clients are unmanaged because of PKI-related certificate issues. For example, if there is a problem with a native mode client certificate, the native mode management point will refuse all communication with the client, and the client will be unmanaged. However, if the client is assigned to a fallback status point, it will successfully report its native mode communication failure with the fallback status point because the fallback status point does not use PKI certificates. Fallback status points are beneficial in both native and mixed modes, but high numbers of mixed mode clients are less likely to be unmanaged because they do not have a dependency on PKI certificates that are managed externally to Configuration Manager.

Avoid using the fallback status point in the perimeter network     By design, the fallback status point accepts data from any client. Placing the fallback status point in the perimeter network could aid in troubleshooting Internet-based clients, but you must balance the troubleshooting benefits with the risk of having a site system accepting unauthenticated data in a publicly accessible network. If you must place the fallback status point in the perimeter network or any untrusted network, configure the site server to pull data from the site system instead of allowing the fallback status point to connect to the site server and initiate data transfers. To configure the site server to pull data, set Allow only site server initiated data transfers from this site system on the properties of the site system.

Do not put a server locator point in the perimeter network    If you need to have client computers in the perimeter network locate Configuration Manager 2007 resources, manually configure those clients with the name of their server locator point.

For information about securing the Configuration Manager 2007 console computers, see Configuration Manager Console Security Best Practices and Privacy Information

For information about securing distribution points and branch distribution points, see Software Distribution Security Best Practices and Privacy Information.

For information about securing the PXE service point and state migration point, which are used for operating system deployment, see Operating System Deployment Security Best Practices and Privacy Information.

For information about securing reporting points, see Reporting Security Best Practices.

Other Resources