Use public key infrastructure (PKI) certificates for client communications with site systems that run IIS:

• As a site property, configure Site system settings for HTTPS only.
  
  
• Install clients with the /UsePKICert CCMSetup property
  
  
• Use a certificate revocation list (CRL) and make sure that clients and communicating servers can always access it.
  
  

These certificates are required for mobile device clients and for client computer connections on the Internet, and, with the exception of distribution points, are recommended for all client connections on the intranet.

For more information about the PKI certificate requirements and how they are used to help protect Configuration Manager, see PKI Certificate Requirements for Configuration Manager.

Automatically approve client computers from trusted domains and manually check and approve other computers

Approval identifies a computer that you trust to be managed by Configuration Manager when you cannot use PKI authentication.

You can configure approval for the hierarchy as manual, automatic for computers in trusted domains, or automatic for all computers. The most secure approval method is to automatically approve clients that are members of trusted domains, and then manually check and approve all other computers. Automatically approving all clients is not recommended unless you have other access controls to prevent untrustworthy computers from accessing your network.

For more information about how to manually approve computers, see Managing Clients from the Devices Node.

Do not rely on blocking to prevent clients from accessing the Configuration Manager hierarchy

Blocked clients are rejected by the Configuration Manager infrastructure so that they cannot communicate with site systems to download policy, upload inventory data, or send state or status messages. However, do not rely on blocking to protect the Configuration Manager hierarchy from untrusted computers when site systems accept HTTP client connections. In this scenario, a blocked client could re-join the site with a new self-signed certificate and hardware ID. Blocking is designed to be used to block lost or compromised boot media when you deploy an operating system to clients and when all site systems accept HTTPS client connections. If you use a public key infrastructure (PKI) and it supports a certificate revocation list (CRL), always consider certificate revocation to be the primary line of defense against potentially compromised certificates. Blocking clients in Configuration Manager offers a second line of defense to protect your hierarchy.

For more information, see Determine Whether to Block Clients in Configuration Manager.

Use the most secure client installation methods that are practical for your environment:

• For domain computers, Group Policy client installation and software update-based client installation methods are more secure than client push installation.
  
  
• Imaging and manual installation can be very secure if you apply access controls and change controls.
  
  

Of all the client installation methods, client push installation is the least secure because of the many dependencies it has, which includes local administrative permissions, the Admin$ share, and many firewall exceptions. These dependencies increase your attack surface.

For more information about the different client installation methods, see Determine the Client Installation Method to Use for Windows Computers in Configuration Manager.

In addition, wherever possible, select a client installation method that requires the least security permissions in Configuration Manager, and restrict the administrative users that are assigned security roles that include permissions that can be used for purposes other than client deployment. For example, automatic client upgrade requires the Full Administrator security role, which grants an administrative user all security permissions.

For more information about the dependencies and security permissions required for each client installation method, see “Installation Method Dependencies” in the Prerequisites for Computer Clients section in the Prerequisites for Windows Client Deployment in Configuration Manager topic.

If you must use client push installation, take additional steps to secure the Client Push Installation Account

Although this account must be a member of the local Administrators group on each computer that will install the Configuration Manager client software, never add the Client Push Installation Account to the Domain Admins group. Instead, create a global group and add that global group to the local Administrators group on your client computers. You can also create a Group Policy object to add a Restricted Group setting to add the Client Push Installation Account to the local Administrators group.

For additional security, create multiple Client Push Installation Accounts, each with administrative access to a limited number of computers so that if one account is compromised, only the client computers to which that account has access are compromised.

Remove certificates prior to imaging client computer

If you plan to deploy clients by using imaging technology, always remove certificates such as PKI certificates that include client authentication and self-signed certificates prior to capturing the image. If you do not remove these certificates, clients might impersonate each other and you would not be able to verify the data for each client.

For more information about using Sysprep to prepare a computer for imaging, see your Windows deployment documentation..

Ensure that the Configuration Manager computer clients get an authorized copy of these certificates:

• The Configuration Manager trusted root key
  
  
• The site server signing certificate
  
  

• Trusted root key:
  
  If you have not extended the Active Directory schema for Configuration Manager, and clients do not use PKI certificates when they communicate with management points, clients rely on the Configuration Manager trusted root key to authenticate valid management points. In this scenario, clients have no way to verify that the management point is a trusted management point for the hierarchy unless they use the trusted root key. Without the trusted root key, a skilled attacker could direct clients to a rogue management point.
  
  When clients cannot download the Configuration Manager trusted root key from the Global Catalog or by using PKI certificates, pre-provision the clients with the trusted root key to make sure that they cannot be directed to a rogue management point. For more information, see the Planning for the Trusted Root Key section in the Planning for Security in Configuration Manager topic.
  
  
• Site server signing certificate:
  
  Clients use the site server signing certificate to verify that the site server signed the client policy that they download from a management point. This certificate is self-signed by the site server and published to Active Directory Domain Services.
  
  When clients cannot download the site server signing certificate from the Global Catalog, by default they download it from the management point. When the management point is exposed to an untrusted network (such as the Internet), manually install the site server signing certificate on clients to make sure that they cannot run client policies that have been tampered with from a compromised management point.
  
  To manually install the site server signing certificate, use the CCMSetup client.msi property SMSSIGNCERT. For more information, see About Client Installation Properties in Configuration Manager.
  
  

Do not use automatic site assignment if the client will download the trusted root key from the first management point it contacts

This security best practice is linked to the preceding entry. To avoid the risk of a new client downloading the trusted root key from a rogue management point, use automatic site assignment in the following scenarios only:

• The client can access Configuration Manager site information that is published to Active Directory Domain Services.
  
  
• You pre-provision the client with the trusted root key.
  
  
• You use PKI certificates from an enterprise certification authority to establish trust between the client and the management point.
  
  

For more information about the trusted root key, see the Planning for the Trusted Root Key section in the Planning for Security in Configuration Manager topic.

Install client computers with the CCMSetup Client.msi option SMSDIRECTORYLOOKUP=NoWINS

The most secure service location method for clients to find sites and management points is to use Active Directory Domain Services. If this is not possible, for example, because you cannot extend the Active Directory schema for Configuration Manager, or because clients are in an untrusted forest or a workgroup, you can use DNS publishing as an alternative service location method. If both these methods fail, clients can fall back to using WINS when the management point is not configured for HTTPS client connections.

Because publishing to WINS is less secure than the other publishing methods, configure client computers to not fall back to using WINS by specifying SMSDIRECTORYLOOKUP=NoWINS. If you must use WINS for service location, use SMSDIRECTORYLOOKUP=WINSSECURE (the default setting), which uses the Configuration Manager trusted root key to validate the self-signed certificate of the management point.

Note

When the client is configured for SMSDIRECTORYLOOKUP=WINSSECURE and finds a management point from WINS, the client checks its copy of the Configuration Manager trusted root key that is in WMI. If the signature on the management point certificate matches the client’s copy of the trusted root key, the certificate is validated, and the client communicates with the management point that it found by using WINS. If the signature on the management point certificate does not match the client’s copy of the trusted root key, the certificate is not valid and the client will not communicate with the management point that it found by using WINS.

Make sure that maintenance windows are large enough to deploy critical software updates

You can configure maintenance windows for device collections to restrict the times that Configuration Manager can install software on these devices. If you configure the maintenance window to be too small, the client might not be able to install critical software updates, which leaves the client vulnerable to the attack that is mitigated by the software update.

For Windows embedded devices that have write filters, take additional security precautions to reduce the attack surface if Configuration Manager disables the write filters to persist software installations and changes

When write filters are enabled on Windows Embedded devices, any software installations or changes are made to the overlay only and do not persist after the device restarts. If you use Configuration Manager to temporarily disable the write filters to persist software installations and changes, during this period, the embedded device is vulnerable to changes to all volumes, which includes shared folders.

Although Configuration Manager locks the computer during this period so that only local administrators can log on, whenever possible, take additional security precautions to help protect the computer. For example, enable additional restrictions on the firewall and disconnect the device from the network.

If you use maintenance windows to persist changes, plan these windows carefully to minimize the time that write filters might be disabled but long enough to allow software installations and restarts to complete.

If you use software update-based client installation and install a later version of the client on the site, update the software update that is published on the software update point so that clients receive the latest version

If you install a later version of the client on the site, for example, you upgrade the site, the software update for client deployment that is published to the software update point is not automatically updated. You must republish the Configuration Manager client to the software update point and click Yes to update the version number.

For more information, see the procedure “To publish the Configuration Manager client to the software update point“ in the How to Install Configuration Manager Clients by Using Software Update-Based Installation section in the How to Install Clients on Windows-Based Computers in Configuration Manager topic.

Configure the Computer Agent client device setting Suspend BitLocker PIN entry on restart to be Always only for computers that you trust and that have restricted physical access

When you set this client setting to Always, Configuration Manager can complete the installation of software to help to ensure that critical software updates are installed and that services are resumed. However, if an attacker intercepts the restart process, she could take control of the computer. Use this setting only when you trust the computer and when physical access to the computer is restricted. As an example, this setting might be appropriate for servers in a data center.

Do not configure the Computer Agent client device setting PowerShell execution policy to be Bypass.

This client setting allows the Configuration Manager client to run unsigned PowerShell scripts, which could allow malware to run on client computers. If you must select this option, use a custom client setting and assign it to only the client computers that must run unsigned PowerShell scripts.

For mobile devices that you enroll with Configuration Manager and will support on the Internet: Install the enrollment proxy point in a perimeter network and the enrollment point in the intranet

This role separation helps to protect the enrollment point from attack. If the enrollment point is compromised, an attacker could obtain certificates for authentication and steal the credentials of users who enroll their mobile devices.

For mobile devices: Configure the password settings to help protect mobile devices from unauthorized access

For mobile devices that are enrolled by Configuration Manager: Use a mobile device configuration item to configure the password complexity to be the PIN and at least the default length for the minimum password length.

For mobile devices that do not have the Configuration Manager client installed but that are managed by the Exchange Server connector: Configure the Password Settings for the Exchange Server connector such that the password complexity is the PIN and specify at least the default length for the minimum password length.

For mobile devices: Help prevent tampering of inventory information and status information by allowing applications to run only when they are signed by companies that you trust and do not allow unsigned files to be installed

For more mobile devices that are enrolled by Configuration Manager: Use a mobile device configuration item to configure the security setting Unsigned applications as Prohibited and configure Unsigned file installations to be a trusted source.

For mobile devices that do not have the Configuration Manager client installed but that are managed by the Exchange Server connector: Configure the Application Settings for the Exchange Server connector such that Unsigned file installation and Unsigned applications are configured as Prohibited.

For mobile devices: Help prevent elevation of privilege attacks by locking the mobile device when it is not used

For more mobile devices that are enrolled by Configuration Manager: Use a mobile device configuration item to configure the password setting Idle time in minutes before mobile device is locked.

For mobile devices that do not have the Configuration Manager client installed but that are managed by the Exchange Server connector: Configure the Password Settings for the Exchange Server connector to configure Idle time in minutes before mobile device is locked.

For mobile devices: Help prevent elevation of privileges by restricting the users who can enroll their mobile devices.

Use a custom client setting rather than default client settings to allow only authorized users to enroll their mobile devices.

For mobile devices: Do not deploy applications to users who have mobile devices enrolled by Configuration Manager or Windows Intune in the following scenarios:

• When the mobile device is used by more than one person.
  
  
• When the device is enrolled by an administrator on behalf of a user.
  
  
• When the device is transferred to another person without retiring and then re-enrolling the device.
  
  

A user device affinity relationship is created during enrollment, which maps the user who performs enrollment to the mobile device. If another user uses the mobile device, they will be able to run the applications that you deploy to the original user, which might result in an elevation of privileges. Similarly, if an administrator enrolls the mobile device for a user, applications deployed to the user will not be installed on the mobile device and instead, applications that are deployed to the administrator might be installed.

Unlike user device affinity for Windows computers, you cannot manually define the user device affinity information for mobile devices that are enrolled by Windows Intune.

If you transfer ownership of a mobile device that is enrolled by Windows Intune, retire the mobile device from Windows Intune to remove the user device affinity, and then ask the current user to enroll the device again.

For mobile devices: Make sure that users enroll their own mobile devices for Windows Intune.

Because a user device affinity relationship is created during enrollment, which maps the user who performs enrollment to the mobile device, if an administrator enrolls the mobile device for a user, applications deployed to the user will not be installed on the mobile device and instead, applications that are deployed to the administrator might be installed.

For the Exchange Server connector: Make sure that the connection between the Configuration Manager site server and the Exchange Server computer is protected

Use IPsec if the Exchange Server is on-premise; hosted Exchange automatically secures the connection by using SSL.

For the Exchange Server connector: Use the principle of least privileges for the connector

For a list of the minimum cmdlets that the Exchange Server connector requires, see How to Manage Mobile Devices by Using the Exchange Server Connector in Configuration Manager.

For Mac computers in Configuration Manager SP1: Independently from Configuration Manager, monitor and track the validity period of the certificate that enrolled to users

To ensure business continuity, monitor and track the validity period of the certificates that you use for Mac computers. Configuration Manager SP1 does not support automatic renewal of this certificate or warn you that the certificate is about to expire. A typical validity period is 1 year.

For information about how to renew the certificate, see the Renewing the Mac Client Certificate sections in the How to Install Clients on Mac Computers in Configuration Manager topic.