Implementing TLS 1.2 enforcement with SCOM

Quicklinks: 

Download Script 

Download Management Pack

This is a requirement that I see is picking up steam with customers.  Customers are getting told by their security teams that they need to support their application and database servers using TLS 1.2 only, and no previous protocols enabled for SCHANNEL communications.

The good news: is that SCOM 2012R2 (with UR14+), SCOM 2016 (with UR4+), and SCOM 1801 all support working in an environment that is configured to use TLS 1.2 ONLY.

The bad news: is that the configuration is a little complicated, there are software prerequisites, and the manual steps can be error prone.

This article will demonstrate the steps involved, and will include a script I wrote the help automate the configuration, remove the risk of errors, and ensure nothing is missed.  I also will demonstrate a management pack which will help confirm the settings are correct, and help identify risks before you implement.

The Microsoft documentation for TLS 1.2 and SCOM is available here:

https://docs.microsoft.com/en-us/system-center/scom/plan-security-tls12-config?view=sc-om-2016

https://support.microsoft.com/en-us/help/4051111/tls-1-2-protocol-support-deployment-guide-for-system-center-2016

The protocols, and their release dates:

As you can see, even TLS 1.2 is 10 years old!!!

Windows Server versions, and their support for TLS:

Starting with Windows Server 2012 and later, these Operating Systems negotiated TLS 1.2 out of the box.

WS2008R2 requires a registry change to enable TLS 1.2

WS2008 SP2 requires an update and then a registry change to enable TLS 1.2

WS2003 offers no support for TLS 1.2

What are the risks of enabling TLS 1.2?

There are always risks because you must understand where endpoints communicate, and any dependencies they might have on older TLS protocols.  Microsoft has some guidance around what should be included in any test plan:  https://cloudblogs.microsoft.com/microsoftsecure/2017/06/20/tls-1-2-support-at-microsoft/

Lets dive into the script and MP, and then we can discuss the finer details later!

First, the automation script:

https://gallery.technet.microsoft.com/Script-to-automate-TLS-12-091f8fbd

This script will:

• Ensure the environment is supported for TLS 1.2
• Determine the local SCOM roles installed.
• Ensure the SCOM Roles are patched with the correct UR level to continue
• Ensure a supported version of .NET framework is installed
• Ensure that SQL is a supported version for TLS 1.2
• Ensure the software prereqs are installed (SQL Client and ODBC driver update)
• Install software prereqs if they are missing
• Configure the registry for SCHANNEL protocols, .NET hardening, and ACS ODBC driver where required.
• Prompt to reboot the server to make the changes active.

The script just needs to be copied to a directory one each server, along with the software prerequisite files.

The software prereqs are:

• SQL Client 11 (sqlncli.msi)
• ODBC Driver 13 (msodbcsql.msi)

Download these files, and just drop them in the same directory as the script.  If they are not installed, the script will install them.

You must log on to each server as a Local Administrator, and if running on a Management Server or Web Console server, you must have rights to connect to and query the master database for the SQL instance that hosts your OperationsManager and DW databases.

Here is an example of a run:

Next up – the management pack:

https://gallery.technet.microsoft.com/SCOM-Agent-Management-b96680d5

I had added some new discoveries on both management servers and SCOM agents – to help with TLS understanding and preparation:

• CertLoaded - will tell you is the SCOM server is configured to load a certificate into the Healthservice.  This is important because SCOM certificate authentication and Encryption uses TLS.  I will cover this deeper below.
• TLS 1.2 Registry Enforced – checks ALL the Protocols in the SCHANNEL registry, and ensures that all are disabled except TLS 1.2, which must be explicitly enabled regardless of the OS default configuration.
• TLS 1.2 SQL Client 11 Installed – checks to see if the SQL Client 11 software prerequisite for TLS 1.2 support is installed.  This is required for Management Servers and Web Console server roles.
• TLS 1.2 ODBC 13 Installed - checks to see if the ODBC 13 Driver software prerequisite for TLS 1.2 support is installed.  This is required for Management Servers and Web Console server roles.

Additionally, for agents – there is a new property – CertLoaded, for the same reason above.  This will be necessary to know if ANY agents are directly using a certificate to communicate with a Gateway or Management server.  If they are – you must ensure that they support TLS 1.2, and that they have been configured to enable TLS 1.2 protocol, or they will immediately stop communicating with SCOM.  You could easily make a dynamic group of all agents running Windows Server 2003, 2008, or 2008R2 for instance, as all of these will require manual intervention if they depend on a certificate.

So the big question for the “Magic-8-Ball”:  “What will happen if I enforce TLS 1.2 ONLY protocol communication on my SCOM environment?”

This really leaves us with more questions – than answers.  In order to fully predict this, you need to understand what all the communication endpoints are in SCOM, and what their hard-coded dependencies are.  The core functionality of SCOM supports TLS 1.2 enforced environments when the software prerequisites and configuration items have been met.

Question: If I enforce TLS 1.2 only communication, will that cut off all my agents that have not been configured to support TLS 1.2?

Answer:  Most likely not.  The default method for SCOM Agents to authenticate to a SCOM server is using Kerberos.  Kerberos does not have a native dependency on TLS.  Once an agent authenticates with the SCOM server using Kerberos, then still using Kerberos, the data channel is encrypted using Kerberos AES or RC4 cypher.  This means event agents that do not support TLS 1.2, such as Windows Server 2003, will still authenticate and communicate just fine to SCOM servers which are hardened to only support TLS 1.2 for TLS communications.

The GREAT BIG exception to this is agents using Certificates.  If an agent uses certificates to communicate to a SCOM server (typical only for workgroups or when a gateway is not used) then the agent WILL depend on TLS, and must support TLS 1.2 or communications will be cut off. 

If you are interested in further reading – there is a deep dive on authentication and encryption for SCOM posted here:  https://www.stefanroth.net/2016/03/02/scom-how-data-is-encrypted/

Ok, that covers agents – what about other dependencies?  There could easily be third party integrations with SCOM that have hard coded dependencies on an older version of TLS (primarily TLS 1.0).  Here is a list of some known issues and areas to check, or include in your test plan:

• Product connectors
• 3rd party management packs
• Synthetic transactions that require older TLS to the endpoint
• Custom Web/REST API’s

Once you test, and make the switch, the good news is that you can always switch back and enable TLS 1.0 quickly if needed, its just a registry change and reboot away.  You can also determine a dedicated server to enable the older protocol if needed for specific connections, management packs, or synthetic transactions.  So you can quickly respond to any issues found with different options.

Review:

• TLS 1.2 enforcement is becoming a hot button issue in many customers to secure their environments and reduce risk.
• SCOM supports TLS 1.2 enforcement, with some required configuration and software prerequisites.
• I have included a script and management pack to help with the automation, configuration, and understanding of this change.
• Risks exist, testing is required, however they should be easily mitigated or reversed with little trouble.

As always - I welcome your comments or suggestions.