Run Setup only from a trusted source and secure the communication channel between the Setup media and the site server.

To help prevent tampering of the source files, run Setup from a trusted source. If you store the files on the network, secure the network location.

If you do run Setup from a network location, to help prevent an attacker from tampering with the files as they are transmitted over the network, use IPsec or SMB signing between the source location of the Setup files and the site server.

In addition, if you use the Setup Downloader to download the files that are required by Setup, make sure that you also secure the location where these files are stored and secure the communication channel for this location when you run Setup.

Extend the Active Directory schema for System Center 2012 Configuration Manager and publish sites to Active Directory Domain Services.

Schema extensions are not required to run Microsoft System Center 2012 Configuration Manager, but they do create a more secure environment because Configuration Manager clients and site servers can retrieve information from a trusted source.

If clients are in an untrusted domain, deploy the following site system roles in the clients’ domain:

• Management point
  
  
• Distribution point
  
  
• Application Catalog website point
  
  

Note
A trusted domain for Configuration Manager requires Kerberos authentication so if clients are in another forest that does not have a two-way forest trust with the site server’s forest, these clients are considered to be in untrusted domain. An external trust is not sufficient for this purpose.

Use IPsec to secure communications between site system servers and sites.

Although Configuration Manager does secure communication between the site server and the computer that runs SQL Server, Configuration Manager does not secure communication between site system roles and SQL Server. Only some site systems (the enrollment point and the Application Catalog web service point) can be configured for HTTPS for intrasite communication.

If you do not use additional controls to secure these server-to-server channels, attackers can use various spoofing and man-in-the-middle attacks against site systems. Use SMB signing when you cannot use IPsec.

Note
It is particularly important to secure the communication channel between the site server and the package source server. This communication uses SMB. If you cannot use IPsec to secure this communication, use SMB signing to ensure that the files are not tampered with before clients download and run them.

Do not change the security groups that Configuration Manager creates and manages for site system communication:

• SMS_SiteSystemToSiteServerConnection_MP_<SiteCode>
  
  
• SMS_SiteSystemToSiteServerConnection_SMSProv_<SiteCode>
  
  
• SMS_SiteSystemToSiteServerConnection_Stat_<SiteCode>
  
  

Configuration Manager automatically creates and manages these security groups. This includes removing computer accounts when a site system role is removed.

To ensure service continuity and least privileges, do not manually edit these groups.

If clients cannot query the Global Catalog server for Configuration Manager information, manage the trusted root key provisioning process.

If clients cannot query the Global Catalog for Configuration Manager information, they must rely on the trusted root key to authenticate valid management points. The trusted root key is stored in the client registry and can be set by using Group Policy or manual configuration.

If the client does not have a copy of the trusted root key before it contacts a management point for the first time, it trusts the first management point it communicates with. To reduce the risk of an attacker misdirecting clients to an unauthorized management point, you can pre-provision the clients with the trusted root key. For more information, see Planning for the Trusted Root Key.

Use non-default port numbers.

When you use non-default port numbers, this can provide additional security because it makes it harder for attackers to explore the environment in preparation for an attack. If you decide to use non-default ports, plan for them before you install Configuration Manager and use them consistently across all sites in the hierarchy. Client request ports and Wake on LAN are examples where you can use non-default port numbers.

Use role separation on site systems.

Although you can install all the site system roles on a single computer, this practice is rarely used on production networks because it creates a single point of failure.

Reduce the attack profile.

When you isolate each site system role on a different server, this reduces the chance that an attack against vulnerabilities on 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 and this increases the attack surface. If you must combine site system roles to reduce hardware expenditure, combine IIS site system roles only with other site system roles that require IIS.

Important
The fallback status point role is an exception: Because this site system role accepts unauthenticated data from clients, the fallback status point role should never be assigned to any other Configuration Manager site system role.

Follow security best practices for Windows Server and run the Security Configuration Wizard on all site systems.

The Security Configuration Wizard (SCW) helps you to create a security policy that you can apply to any server on your network. After you install the System Center 2012 Configuration Manager template, SCW recognizes Configuration Manager site system roles, services, ports, and applications. It then permits the communication that is required for Configuration Manager, and blocks communication that is not required.

The Security Configuration Wizard is included with the toolkit for System Center 2012 Configuration Manager, which you can download from the Microsoft Download Center: System Center 2012 – Configuration Manager Component Add-ons and Extensions.

Configure static IP addresses for site systems.

Static IP addresses are easier to protect from name resolution attacks.

Static IP addresses also make the configuration of IPsec easier, which is a security best practice for securing communication between site systems in Configuration Manager.

Do not install other applications on site system servers.

When you install other applications on site system servers, you increase the attack surface for Configuration Manager and risk incompatibility issues.

Require signing and enable encryption as a site option.

Enable the signing and encryption options for the site. Ensure that all clients can support the SHA-256 hash algorithm and then enable the option Require SHA-256.

Restrict and monitor Configuration Manager administrative users and use role-based administration to grant these users the minimum permissions that they require.

Grant administrative access to Configuration Manager only to users that you trust and then grant them minimum permissions by using the built-in security roles or by customizing the security roles. Administrative users who can create, modify, and deploy applications, task sequence, software updates, configuration items and configuration baselines, can potentially control devices in the Configuration Manager hierarchy.

Periodically audit administrative user assignments and their authorization level to verify required changes.

For more information about configuring role-based administration, see Configure Role-Based Administration.

Secure Configuration Manager backups and secure the communication channel when you backup and restore.

When you back up Configuration Manager, this information includes certificates and other sensitive data that could be used by an attacker for impersonation.

Use SMB signing or IPsec when you transfer this data over the network, and secure the backup location.

Whenever you export or import objects from the Configuration Manager console to a network location, secure the location and secure the network channel.

Restrict who can access the network folder.

Use SMB signing or IPsec between the network location and the site server, and between the computer that runs the Configuration Manager console and site server to prevent an attacker from tampering with the exported data. Use IPsec to encrypt the data on the network to prevent information disclosure.

If a site system fails to uninstall or stops functioning and cannot be restored, manually remove the Configuration Manager certificates for this server from other Configuration Manager servers.

To remove the PeerTrust that was originally established with the site system and site system roles, manually remove the Configuration Manager certificates for the failed server in the Trusted People certificate store on other site system servers. This is particularly important if you repurpose the server without reformatting it.

For more information about these certificates, see the section Cryptographic Controls for Server Communication in Technical Reference for Cryptographic Controls Used in Configuration Manager.

Do not configure Internet-based site systems to bridge the perimeter network and the intranet.

Do not configure site system servers to be multi-homed so that they connected to the perimeter network and the intranet. Although this configuration allows Internet-based site systems to accept client connections from the Internet and the intranet, it eliminates a security boundary between the perimeter network and the intranet.

If the site system server is on an untrusted network (such as a perimeter network), configure the site server to initiate connections to the site system.

By default, site systems initiate connections to the site server to transfer data, which can be a security risk when the connection initiation is from an untrusted network to the trusted network. When site systems accept connections from the Internet or reside in an untrusted forest, configure the site system option Require the site server to initiate connections to this site system so that after the installation of the site system and any site system roles, all connections are initiated from the trusted network.

If you use a web proxy server for Internet-based client management, use SSL bridging to SSL, by using termination with authentication.

When you configure SSL termination at the proxy web server, packets from the Internet are subject to inspection before they are forwarded to the internal network. The proxy web server authenticates the connection from the client, terminates it, and then opens a new authenticated connection to the Internet-based site systems.

When Configuration Manager client computers use a proxy web server to connect to Internet-based site systems, the client identity (client GUID) is securely contained within the packet payload so that the management point does not consider the proxy web server to be the client. If your proxy web server cannot support the requirements for SSL bridging, SSL tunneling is also supported. This is a less secure option because the SSL packets from the Internet are forwarded to the site systems without termination, so they cannot be inspected for malicious content.

If your proxy web server cannot support the requirements for SSL bridging, you can use SSL tunneling. However, this is a less secure option because the SSL packets from the Internet are forwarded to the site systems without termination, so they cannot be inspected for malicious content.

Warning
Mobile devices that are enrolled by Configuration Manager cannot use SSL bridging and must use SSL tunneling only.

If you configure the site to wake up computers to install software:

• Use AMT power commands rather than traditional wake-up packets
  
  
• If you use traditional wake-up packets, use unicast rather than subnet-directed broadcasts
  
  
• If you must use subnet-directed broadcasts, configure routers to allow IP-directed broadcasts only from the site server and only on a non-default port number
  
  

For more information about the different wake on LAN technologies, see Planning for Client Communication in Configuration Manager.

If you use email notification, configure authenticated access to the SMTP mail server.

Whenever possible, use a mail server that supports authenticated access and use the computer account of the site server for authentication. If you must specify a user account for authentication, use an account that has the least privileges.

Note
In Configuration Manager SP1, email notifications are no longer restricted to Endpoint Protection.