Menu Close

Implementing TLS 1.2 enforcement with SCOM


image

 

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:

SSL 2.0 Nov 1994
SSL 3.0 Nov 1995
TLS 1.0 Jan 1999
TLS 1.1 Apr 2006
TLS 1.2 Aug 2008

 

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

 

Windows Server versions, and their support for TLS 1.2:

Windows Server 2003 No support for TLS 1.2
Windows Server 2008 SP2 Disabled by default – enable with Hotfix update and registry change
Windows Server 2008R2 SP1 Disabled by default – enable with registry change
Windows Server 2012 Enabled by default
Windows Server 2012R2 Enabled by default
Windows Server 2016 Enabled by default

 

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 enforcing the use of TLS 1.2 protocol?

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.
  • It can be run on Management Server, Gateway, Reporting, Web Console, ACS Collectors, SQL database servers, anywhere you want TLS 1.2 enforced.

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

The software prereqs are:

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:

image

 

 

 

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:

 

image

  • 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.

 

Troubleshooting:

One of the things that will help you in troubleshooting any issues – is Secure Channel verbose logging.  Look at the key: HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\  for a key property called EventLogging

This is a REG_DWORD Value from 1 to 7.  7 being the most verbose.  This setting will let you see in the System Event log for SCHANNEL events, to help understand if there is a communication mismatch, or if the client or server endpoints are still attempting an older TLS protocol:

image

Decimal

Description

0

Do not log

1

Log Error messages

2

Log Warnings

3

Log Error and Warning messages

4

Log Informational and Success events

5

Log Error, Informational and Success events

6

Log Warnings, Informational and Success events

7

Log Everything (Warnings, Errors, Informational and Success events

 

I’d recommend setting it to 3 to see errors and warnings, or 7 to see everything.  Remember to set this back to 1 when done resolving any issues.

 

 

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.

11 Comments

  1. Stephen

    Will these steps also force the Web Availability testing to use tls 1.2. Seems when running tests currently in a Server 2012 running 1807 we are sending out tls 1.0 requests.

  2. Jon

    Hey Kevin,

    Looks like the script is failing to detect SQL 2017+. I made a quick modification to the sections at lines 365 and 466 to account for newer version of SQL. Note the “-ge” as opposed to “-eq” below.

    Interestingly the script as originally posted runs fine on a dedicated SQL 2017 server. I did not see failures until this was run from the management server connecting back to SQL. You may also consider an update to section starting at line 338 to also run the SQL checks on dedicated SQL servers that do not also have the SCOM management server role installed. Other users will want to note they should use caution when executing this script on the SQL server. Your SQL version might not actually support TLS 1.2.

    IF ($SQLMajorVersion -ge 13)
    {
    Write-Host `n”PASSED: Operations DB Server: This is SQL 2016 or higher. All versions of SQL 2016 and higher support TLS 1.2 so no update is required on server ($OpsSQLServer)” -ForegroundColor Green
    LogWrite “PASSED: Operations DB Server: This is SQL 2016 or higher. All versions of SQL 2016 and higher support TLS 1.2 so no update is required on server ($OpsSQLServer)”
    }

    Thanks for the fantastic SCOM resources in general.

    • Kevin Holman

      Good stuff! I have not circled back and updated this, at the time of publishing it was SCOM 2016/1801 only…. which did not support SQL 2017.

  3. James

    As usual, great article! Has anyone here come across any way to monitor TLS changes in the registry with SCOM? Our patching team has failed to make sure that TLS settings remain the same on servers they are working on in the environment, which is causing TLS mismatches between the app servers and databases when the settings get changed. Thanks!

  4. Howard Brown

    The script appears to have an issue with detecting the web console installation on SCOM 2019. The registry key it looks for seems to be askew for the web console. It should look for the key HKLM\Microsoft\System Center Operations Manager\12\Setup\WebConsole. It fails to install the ODBC driver and the SQL Native Client when it does not find the role – although I’m not sure if this matters on a web console.

    • Howard Brown

      I think I’ll add to this in that I believe the issue lies in that neither the script nor the MP detect a standalone web server for the web console. This probably exists in all versions of SCOM that this script/MP applies to. Since it does not install the ODBC driver or Native Client on a web console when it does not detect it, but does indeed configure TLS 1.2 Enforcement, it might cause issue.

      • Kevin Holman

        Howard – you are 100% correct. There was a bug and the script is now fixed to handle this. The standalone web console does not install the same registry entries. I normally don’t test standalone web consoles because I generally do not recommend them. We seem to have too many authentication issues with standalone web console servers, so I always install them on two management servers then load balance them if needed. The MP is different. It was not designed to detect stand alone Web Console servers. It targets SCOM Management servers and the roles on them, only. Changing that would be a significant re-write, and stand alone web console servers are rare….. so I doubt I will update the mP for that.

        • Howard Brown

          As long as it works on standalones – although I’m surprised to hear that. Setting up a standalone web console is a relatively easy thing, including SSO. The only thing I’ve found is that you need to disable kernel-mode authentication in 2016/2019 to get SSO to work, which I assume is due to the goofy loopback needed in IIS. It works, so I’ve never dug deeper.

Leave a Reply

Your email address will not be published. Required fields are marked *