Maximizing Security in Configuration Manager

  • Article

This post details my experience and lessons learned with hardening a System Center Configuration Manager system.  I'll review the risks and then describe the various technical components of a ConfigMgr system: Windows Server host, Internet Information Service (IIS), SQL Server and ConfigMgr itself.  Make sure to review the current product documentation on Security for Configuration Manager 2007 before continuing.

First let's look at some of the risks inherent to ConfigMgr.

  • Scope of management: What types of systems are to be managed?  Is it just workstations?  IT administrators, accounting, HR, mobile users?  Is the system managing servers as well?  Domain controllers, Exchange, SharePoint, SQL?
  • Data collection: There is an enormous wealth of data that can be collected from ConfigMgr clients with hardware and software inventory, much of which could be very useful to a malicious user planning an attack.  However also consider that software inventory provides the ability to obtain any file by name from the client and pull that back centrally. 
  • Software distribution: Most folks think of software distribution in terms of installing software on the managed clients.  But an administrator could package external utilities such as the SysInternals Suite or custom scripts, or use it to execute command lines built-in to Windows, all under the context of the Local System.
  • OS deployment: You have to be very careful about the scope of management and the scope of deployment with OSD.  For example, I would expect that Windows 7 probably screams when running on server hardware. 
  • Vulnerability reports: There is extremely valuable information to an attacker in the default reports.  Update and configuration compliance can be used to find vulnerable systems on the network.
  • Network consumption: ConfigMgr could be misused for a massive denial of service by flooding the network with data and consuming all bandwidth between sites by simultaneously updating all distribution points or pushing multiple large packages to all clients.

Windows Server Host General Security Considerations

  • Make sure the latest service pack is applied (as supported by the SQL and ConfigMgr product teams!), and that the security and critical updates are current. 
  • Use the Security Compliance Manager (SCM) Solution Accelerator to leverage a standard security baseline, such as the Specialized Security - Limited Functionality (SSLF), and then create delta policies to relax settings as necessary (see more on this below).
  • Use the Security Configuration Wizard (SCW) local utility to create a local configuration policy, to include lockdown of services, file permissions, firewall rules, and registry configurations.  The ConfigMgr Toolkit includes a SCW template to provide ConfigMgr role-specific settings into the wizard. On Server 2008 and later you will need to use the updated SCW template.

Windows Server: User Rights Assignment

These were determined through analysis of the system during installation as well as review of the product documentation.  The SQL Server documentation in particular has excellent details on the specific security rights and permissions that are required for service accounts.

  • Adjust memory quotas for a process (SQL 2008)
  • Bypass traverse checking (SQL 2008)
  • Impersonate a client after authentication (IIS 7)
  • Log on as a batch job (IIS 7)
  • Log on as a service (SQL 2008)
  • Replace a process level token (SQL 2008)

The following two rights are not typically required with ConfigMgr on Server 2008 R2.  Debug programs is not required for installation or runtime, but you can’t upgrade or uninstall any ConfigMgr components unless the logged on user has this right.  The Server 2003 SSLF Member Server baseline removed this right from the local Administrators, but that is no longer the case with the Server 2008 R2 SSLF member server baseline.  IIS 7 changes the way in which it allows anonymous access so the right, Deny access to this computer from the network, is no longer necessary either.

Windows Server: System Services

The SSLF baseline does not enforce any system service restrictions, so I developed additions to the delta policy based upon analysis of the system, output of the Security Configuration Wizard, and information from the Threats and Countermeasures documentation for Windows Server.  The ConfigMgr SCW template can help with the services configuration for product-added services that are required.  Careful analysis is required of the various components in the specific customer environment to determine whether individual services are required or not.  Disabling default system services may reduce the attack footprint of the server, but is not recommended due to the likelihood of system instability and establishment of an unsupported state.

Service configuration can also be used to block additional components that may be inadvertently added. For example, the policy can include explicit settings to disable services like Active Directory Domain Services, Client for NFS, FTP Server, Remote Desktop License Server, or Windows SharePoint Services so that even if a system administrator attempts to add the component in the future, it cannot run due to policy.

Windows Server: Security Options

There are a few additional settings that may need to be included with the ConfigMgr delta policy. 

  • MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames
    ConfigMgr 2007 requires that NTFS 8.3 name creation is enabled due to an issue with Windows Installer and the ConfigMgr Administrator Console.  The Server 2003 SSLF member server baseline enables this setting which disables short file name creation, but this is no longer the case with newer baselines.
  • MSS: (AutoShareWks) Enable Administrative Shares
  • MSS: (AutoShareServer) Enable Administrative Shares
    ConfigMgr clients must have the Windows administrative shares, such as admin$, enabled in order to be properly managed.  While these two settings are not included with the SSLF baseline, other security guidance may recommend the use of these settings.
  • System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
    FIPS is one of the most commonly deviated settings because it will quickly break many products that do not use FIPS-compliant algorithms.  I have yet to find any aspect of a ConfigMgr system that is significantly affected by enabling FIPS, with one (optional) exception: SQL Server 2008 Reporting Services (see below).

Windows Server: Windows Firewall

Windows Server 2008 R2 SSLF Member Server baseline requires the use of the Windows Firewall and blocks all incoming connections.  While there are good in-box rules to allow common functions such as file sharing and remote administration, custom rules will need to be defined to allow ConfigMgr clients and other site systems to access the site server.  This is best configured via the delta group policy for ConfigMgr so that the connection rules are centralized and enforced.  The ConfigMgr documentation has a very thorough data flow diagram for all necessary network connections: Ports Used by Configuration Manager.

SQL Server

With SQL for ConfigMgr the only requirement is the Database Engine and nothing else.  Unless of course you’re using a Reporting Services Point in which case you’ll also need to add Reporting Services.  Ideally you just install the database and then components such as the Tools and Docs can be installed on a workstation for remote administrative use.  I typically add the Tools and Docs along with the Database Engine simply for convenience.  As with Windows, make sure SQL is patched (as supported by ConfigMgr!) and apply the latest cumulative update.  The Best Practices Analyzer is useful to review your configuration settings against known SQL best practices. 

I always disable the SQL Browser service as part of the SQL hardening, which can make it difficult to connect to the database from a remote system, such as a child site server or proxy management point.  By installing the SQL Native Client on the remote system and configuring a SQL connection alias, this will provide a pathway to the SQL database engine on the ConfigMgr site server.  This maintains the SQL hardening so that it is not discoverable on the network but provides the same functionality for the remote endpoint.

The use of service accounts is a SQL best practice instead of local system or other built-in service accounts.  A domain service account is required for ConfigMgr in order to provide Kerberos authentication.  So then you have to ensure that the service principle names (SPNs) are set correctly for both the NetBIOS and Fully Qualified Domain Name of the server with the correct TCP port.  Alternatively, you can assign the Write Public Information permission to Self on the SQL service account.

Note that it is not supported to change the SQL listening port for SQL Server instances hosting Configuration Manager site databases.  Use of a named instance is recommended for a variety of reasons, namely a non-standard configuration and the associated non-standard port.  The following Microsoft Support article should be used to set a static port for named instances: How to configure an instance of SQL Server to listen on a specific TCP port or dynamic port. This is needed for static configuration of Windows Firewall rules and SQL Native Client connection aliases.

Since the delta policy has to deviate several user rights assignments for SQL to function, a large environment with multiple sites will need multiple SQL service accounts for each site.  Instead of requiring a modification to the security policy when a new SQL service account is needed, I recommend the use of a local security group on each server.  The domain SQL service accounts are added to the local group, and the local group is specified by name in the delta policy for each of the necessary user rights assignments.

Finally, there is a security configuration inside the SQL Server Configuration Manager on the network configuration for the instance where you can add a certificate (the same one used by IIS if desired) and then force encryption for connections to the server.  See Encrypting Connections to SQL Server for details on configuring this.  This configuration option can also prevent the SQL Server Browser service from making the instance known to client computers, which is good to specify even if the SQL Browser service is disabled.  As ConfigMgr typically uses a dedicated SQL server there is no need for any system on the network to be able to discover the instance without previous knowledge of its existence.

There are two modifications that need to be made to for this configuration to function with ConfigMgr.  First, the domain SQL service account needs rights to the private key. Previously with Windows Server 2003 you needed to use the winhttpcertcfg utility.  With Windows Server 2008 R2 it's as simple as opening the Certificates console for the Local Computer, right-clicking the certificate, selecting All Tasks and selecting the Manage Private Keys option.  By default SYSTEM and Administrators have Full Control, so the domain SQL service account should be added with Read permission.

The second modification is in the SQL Server Management Studio.  In the Security node, open the properties of the NT AUTHORITY\SYSTEM context, select User Mapping, select the master database and add the db_owner role.  This may be overly generous, but does allow remote client connections, for example from a child site server, to automatically raise the encryption level during the connection negotiation. 

SQL Server 2008 Reporting Services

For SSRS to function with FIPS-compliant algorithms, ASP.NET must be configured to use 3DES:

  1. Edit <Drive>:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportManager\Web.config.
  2. Navigate to the <system.web> section and add the following:
    <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>
  3. Save and close Web.config.

(These steps are from Xiao Min Tan.)

Internet Information Services

First review the Best Practices for Securing Site Systems for general guidance but also specific to IIS.  The primary guidance is to use role separation so that IIS is only installed for site systems that require it.

IIS 7 on Server 2008 or IIS 7.5 on Server 2008 R2 requires a custom script run after installation to move the Inetpub directory.  After the installation of IIS it’s easy enough to run a configuration script to create the custom website and port for use by ConfigMgr, which must be named SMSWEB.

Remove the default content so that when accessing the base server URL it does not return the default, sample “Welcome to IIS” content.  This default content is not needed; it can be safely deleted without impacting ConfigMgr or WSUS.  The websites can also be configured to disable default content so that another administrator can’t drop an index.htm file into a directory that will be the first page to load.  While SSL is the default for Native Mode sites, if possible, SSL should be enabled and enforced for reporting in Mixed Mode sites.

Some will argue whether these sorts of customizations are necessary and can be considered a security feature.  Every customer security team with which I’ve worked prefers non-standard configurations.  While "security by obscurity" is not going to stop a determined attacker from accessing the system, multiple layers of these configurations can deter some attackers and slow down others.

Configuration Manager

Leverage the custom website and custom port defined during the IIS configuration.  During configuration of the ConfigMgr site, there’s a checkbox in the Site settings that allows the data to be encrypted between the client and management point.  It’s a very simple thing, which does add some overhead because both the client and the server are now encrypting the data, but it definitely adds a significant additional layer of security.  See How to Encrypt Client to Management Point Data in Mixed Mode for details.

Block console access to TechNet, similar to the Internet Communication Management settings in group policy.  Add a DWORD value named DisableHomePage in the registry key HKLM\Software\Microsoft\ConfigMgr\AdminUI.  (See How to Prevent the Home Page from Downloading the TechCenter Page on Microsoft.com).

Use Native Mode security when possible, but when using Mixed Mode security ensure it is Active Directory-integrated for centralized trust.

Use the advertisement option to Download...and run locally.  While you have to ensure you properly configure and manage the client cache, the client will checksum the content after it is downloaded and compare against the hash of the original package source, not just what’s on the distribution point.  This helps protect against a man-in-the-middle attack by ensuring the content is valid prior to execution.

I recommend the use of what I call an installation service account.  This is just a normal user account in Active Directory with no additional rights at first.  You can assign the specific rights that are necessary in the environment, such as administrative rights to the site server, sysadmin rights to SQL, etc.  Then all of the product installation and configuration is done under the context of this service account.  When all is done the rights are taken away and the account is either deleted or disabled for potential future use.  The idea is that this is a well-scoped security context during installation.  If you use the administrative account of a member of the implementation team, they may have other permissions elsewhere that may affect the outcome of the installation.  If you have control over the scope of the installation then you know exactly what it can and cannot do.

The Network Access and Domain Join accounts are typical service accounts that are often required.  The Network Access service account is a very low rights user in Active Directory, used purely for authentication to the server when other methods of authentication are not available (such as in Windows PE during OS deployment).  The Domain Join account will need additional permissions in Active Directory to allow computers to be automatically joined to the domain during OS deployment, but those permissions can be carefully scoped to a specific OU.

I recommend avoiding Client Push Installation.  This is one area where the concept of security versus functionality really comes out.  From a functional standpoint, client push is great: right-click, install client.  From a security standpoint, however, it requires storing administrative credentials, of either a named administrative user or a generic service account with administrative rights.  I don’t think either of these options is worth the functional gain, especially when there are many other methods by which the client can be installed.

Finally, Active Directory security groups should be used for various roles that are required to access the system: Administrators, Operators, Reporting Users, Auditors.  This is just an example of a few; a large environment will probably have many more roles, especially of the operational type: this group installs software, this group installs updates, etc.  With ConfigMgr 2012 these can be easily assigned to specific roles in the console, whereas with ConfigMgr 2007 you have to assign the specific rights for each class to the security group.

The Auditors group can be added to the SMS Admins local group on the site server, but no additional rights in the ConfigMgr 2007 console.  This will allow an auditor to open the console, see all of the nodes and the security of each, but no other content in the console.  It’s a great way to give the auditing team or security team access to view the rights in the ConfigMgr console without granting rights to see anything else.

Other Security Considerations

  • IPsec between site servers to ensure that intersite communication is secure and/or encrypted
  • Additional WSUS lockdown to enforce SSL and requiring mutual authentication
  • Additional SSRS lockdown
  • WDS/PXE security
  • DCM for component configuration compliance

In planning for a secure ConfigMgr implementation make sure to look at each component individually.  The product teams for Windows, IIS, SQL, WSUS, etc., have provided some great documentation on how to secure that component.  They must be kept in the context of the integrated ConfigMgr system, however, as they all must work together for a secure and functional system.

There are a lot of best practices and security standards from both Microsoft and other parties.  Standard baselines should be used whenever possible as they have already undergone some level of testing so will help accelerate your work.

Even in environments that don’t have rigorous corporate, government or regulatory requirements for security, these configurations can be implemented to raise the security level of the ConfigMgr system and its components.  There are risks with every ConfigMgr implementation and these are practical methods that can be used in any environment to help secure the system.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation.