Microsoft System Center Configuration Manager is an incredibly powerful tool. It provides IT administrators and operators with visibility of desktop and server system configurations and the ability to change configurations, install software and security patches, execute any code on clients with elevated privileges and even replace or upgrade the operating system on hundreds of thousands of devices, all from a single management console.
Any system that has such power and reach in your environment needs to be protected from unauthorized or malicious use and, as far as possible, operator error and accidents. Configuration Manager uses certificate-based signing of client policy, mutual certificate-based authentication of communication between clients and servers, and SHA-256 hashing for integrity-checking of content that has been downloaded before it is executed. These are all built in defenses against ‘man-in-the-middle’ type attacks, but securing the Configuration Manager infrastructure – especially the Site Server, which should be considered the ‘crown jewels’ – is also necessary to reduce the risk of unauthorized or malicious use from the core.
This blog identifies 8 best practices to make your Configuration Manager infrastructure secure and also reduce the scope and severity of accidents and operator error.
1: Restrict access to the Configuration Manager Database
Configuration Manager is the only thing that should be writing to the Configuration Manager Database. Any process or user that is able to write directly to the Configuration Manager database can modify existing objects in Configuration Manager (e.g. change a Program Command Line to execute a different process or modify Collection Membership Rules to target different devices).
Any user or process, including in-house or third-party add-ons, that need to make changes to Configuration Manager should always do so through the SMS Provider (the Configuration Manager Console uses the SMS Provider) with its inherent security and auditing features.
Read access to the database can be given more freely – no doubt you will be using reporting tools or third-party add-ons that use inventory information and such from Configuration Manager, but under normal operational conditions, write access should be limited to the Configuration Manager components.
2: Restrict admin rights on the Site Server
This is the most basic security best practice for all systems, but Configuration Manager Site Systems, especially the Site Server, must be stringently managed to prevent unauthorized changes, accidents and limit the damage should any malware manage to execute while a user is logged on.
Restrict membership of the local Administrators group on the Site Server to only essential system administrators. Avoid logging on to site system servers with admin accounts unless absolutely necessary. Consider carefully any external tools that are granted local admin rights on the Site Server.
3: Keep the Site Server clean
Avoid installing other applications on the Site Server. As well as affecting performance, it increases the attack surface on the server. Applications that interface with Configuration Manager should be installed on a separate server wherever possible and only be given absolute necessary permissions on the Site Server.
With an increasing amount of malware being propagated through websites, you may want to consider restricting internet access on your Configuration Manager servers (in conjunction with restricted admin rights), to prevent installation of unauthorized software directly from the Internet. (How often have you been tempted to quickly download a free tool to troubleshoot an issue on a server?). You don’t want nasties like Flash or Java creeping onto your site server.
4: Separate the Site Server from IIS-based site systems
For the most part, Configuration Manager clients interact with Configuration Manager through various IIS-based Site Systems such as Management Points, Distribution Points and Software Update Points. As IIS increases the attack surface on a server, you should keep all the IIS Site Systems off the site server – use separate servers for these. For small organizations you may want to install several IIS-based site roles onto the same server (although for redundancy you should always have at least two, even in the smallest environments).
5: Use HTTPS for communication with Site Systems
Configuration Manager enables some Site Systems to use HTTPS, encrypting the data during transit between the site system and the client, thereby mitigating ‘man-in-the-middle’ attacks. This is essential for managing Internet-based clients, but can also be implemented on intranet-based Site Systems.
However, specifically for content distribution on your corporate network, in most scenarios using HTTP on your DP is actually more secure. When a client obtains content from a DP using HTTP, the connection to the DP and access to the content is authenticated. When using HTTPS, the content is encrypted but not authenticated. (See Security Best Practices for Content Distribution).
If the content itself does not contain sensitive information, encryption is not so important. Authentication is more important as it prevents unauthorized access to software on your Distribution Points. Remember that Configuration Manager will always validate any content that has been downloaded using an SHA-256 hash, so if the content is tampered with in any way, whether at the source, during transit or on the client, it will not be executed and the client is protected.
6: Use remote Configuration Manager Consoles rather than RDP onto the Site Server
Don’t use a Remote Desktop connection to the Site Server for day-to-day administration through the console. An interactive user session on the server opens up more risk than you need to deal with. Instead, install the Configuration Manager console on administrator and operator workstations. Alternatively, install the Configuration Manager console onto a separate terminal server that has good network access to the Site Server. This will reduce the number of interactive logon sessions on the server, thereby limiting the opportunity for malware execution.
7: Use Role-Based Administration
With the best intent in the world, well-meaning operators will make mistakes. Role-Based Administration in Configuration Manager helps top-level administrators delegate tasks to lower-level admins and operators with confidence that if they do mess up, the effects are limited. For example, most help desk operators will probably be involved in deploying just Applications and Packages – you may want to prevent them having access to deploy OS Deployment Task Sequences. You probably also want to make sure they can’t deploy stuff to servers. Use Scopes to group securable objects (Packages, Applications, Task Sequences etc.) and use Roles to define which Scopes and Collections users assigned to a role can work with.
8: Ensure any add-ons you use also follow these best practices
Configuration Manager alone is a very useful and powerful tool. It comes with its own Software Development Kit (SDK) that enables you and others to automate and extend the functionality even further. There are loads of useful tools and add-ons out there that will make your life as an admin or operator easier. Before you use any of these tools, make sure they are not compromising the security of your Configuration Manager core. For example:
- Does the tool require write access to the Configuration Manager database? If so, what permissions specifically are required? Exactly what is it doing in there?
- Does the tool require local admin rights on the Configuration Manager Site Server? If so, what exactly is it doing that needs such elevated permissions? Do processes or services that require admin rights expose the server to other vulnerabilities (such as Java)?
- If the tool accesses or distributes Configuration Manager content, how is that access authenticated? Does it support HTTPS for transferring content to Internet-based clients?
- Does the tool adhere to Role-Based Administration, or are operators able to perform tasks with the tool that you have prevented through Role-Based Administration and go un-audited?
Configuration Manager security is a huge topic and there are lots of scenarios in Configuration Manager that will require particular attention. I’ve covered some key steps to keep the core protected. A great place to learn more is Security best practices and privacy information for System Center Configuration Manager.
