Enabling TLS v1.2 support in SCCM

Hi All,

I have recently been working with a customer who had a requirement to disable TLS v1.0 and TLS v1.1 due to the two protocols going End Of Life and now being considered an insecure protocol for communication between servers. This therefore mandates the requirement to use TLS v1.2 in their SCCM environment.

To be clear on our objectives before beginning, TLS is a security protocol for network communication between server that is utilised by SQL. This particular customer has their SCCM SQL database hosted on a remote server to the SCCM Primary site server so it is necessary for TLS to be utilised for communication. If the SQL database was hosted on the same server as the SCCM Primary Site Server then this process would not be necessary as there would be no SQL traffic traversing the network, and therefore TLS would not be required.

Note: The following testing was performed with SCCM 1802, Server 2016 and SQL 2016.

Confirm existing state

Firstly, I just want to demonstrate that the existing SCCM Primary site is communicating with the SQL server without any issues.

To verify this I can check the smsexec.log file on the Primary Site server and confirm there are no errors or warnings present.

Untitled

Disabling TLS v1.0 and TLS v1.1

Now we have confirmed that the existing environment has no pre-existing issues, the first stage in our process will be to disable TLS 1.0 & 1.1 on our Primary Site Server and the SQL server. This will ensure that all communication will be forced to TLS 1.2.

To perform this we will RDP to each of our servers and open the registry editor to the following location:

‘HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols’

Untitled

We can see here that there are existing keys for SSL 2.0 and SSL 3.0 but not for TLS 1.0 or TLS 1.1 so we need to create them shown below. In each of the new folders there should be a new DWORD key created named ‘Enabled’ and the value set to 0 (i.e. Disabling the protocol).

Note: I will not screenshot every registry setting for both servers and this will be repetitive, but trust me I have created all of them on both servers!

Untitled-2

I then restarted the SMS_EXECUTIVE service on the SCCM Primary Site server

Untitled-3.png

And checking again in the smsexec.log file shows that the Primary Site server is now no longer able to communicate with the SQL server

Untitled-4.png

This then verifies that TLS 1.0 and 1.1 are now disabled and that SCCM is not currently able to use TLS 1.2 to communicate with the SQL server. So lets go about fixing that…

 

Enabling TLS 1.2 support

The SCCM Primary Site does not communicate directly with the SQL server. It uses a locally installed SQL Native Client to perform this communication which is actually installed as a part of the SCCM Primary Site installation process when the SQL server is remotely hosted.

We can see in our log file above that the ‘SQL Server Native Client 11.0’ is the driver being called by SCCM and when checking the installed programs list on the Primary Site server we can see that there is a program named ‘Microsoft SQL Server 2012 Native Client’ and the version is 11.0.2100.60. This is the driver that SCCM is using to communicate with the SQL server despite our SQL server actually running SQL 2016.

Upon checking the following Microsoft article it is apparent that the currently installed version of the Native Client does not support TLS 1.2, and therefore we will need to upgrade the client.

https://support.microsoft.com/en-au/help/3135244/tls-1-2-support-for-microsoft-sql-server

Firstly we will Uninstall the existing SQL Native Client by simply using the Windows uninstall process.

Untitled-5

We then need to install the latest version of the SQL Native Client. This can be downloaded from the following location. The file required is ‘sqlncli.msi’

https://www.microsoft.com/en-us/download/details.aspx?id=52676

I simply installed this MSI using all of the default options so I won’t screenshot each individual step, but we can see that once the installation is complete it still registers in Programs and Features as ‘Microsoft SQL Server 2012 Native Client’, but crucially now the version has been increased to 11.3.6518.0 which is above the minimum version required for TLS 1.2 support.

Untitled-6

Again, another restart of the SMS_EXECUTIVE service will force SCCM to start using the new version of the client.

Untitled-3

And we can see in the smsexec.log file that the Primary Site is now able to successfully communicate with the SQL server.

Untitled-7

And launching the console, it successfully connects to the SCCM site

Untitled-8

At this stage I am happy to say that we have successfully upgraded our SCCM site to be fully TLS 1.2 compliant.

Obviously this process has been performed on the Primary Site server only. If we had either a Central Administration Site or any Secondary Sites in the hierarchy this process would need to be repeated for these sites too

Please feel free to leave me a comment below

Thank you for reading

Author: Andrew Stalker

I am an IT consultant currently working in Sydney, Australia. I specialise in Microsoft infrastructure technologies, specifically System Centre and Azure Cloud computing including EMS & Office 365.

One thought on “Enabling TLS v1.2 support in SCCM”

  1. Hi!

    First of all, thanks by creating this post to help everyone to solution their problems.

    In my case, I have an Installation of SCCM 1910, SQL Server 2019 in another server and both of them on Windows Server 2019.

    When I try to install a new server to be a site server in passive mode, in monitoring/status shows SQL Server sysadmin rights failed (already checked).
    FailOverMgr.log shows CheckAdminOnSQL has failed and all I have in google is what you did.
    May I have to say that this environment is working in HTTP, not HTTPS. They want SCCM to manage servers outside of their domain only for script deploy purposes…

    I don’t know what else to do. Do you have any ideA?

    Thanks in advance!!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s