Quicklinks:
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
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://github.com/thekevinholman/TLS1.2Enforce
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 minimum 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://github.com/thekevinholman/SCOM.Management
I had added some new discoveries on both management servers and SCOM agents – to help with TLS understanding and preparation:
- CertLoaded – will tell you if the SCOM server is configured via the Registry 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 even 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:
|
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.
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.
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.
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.
Update posted – added support for SCOM 2019, SQL 2017+, for the GW, MS, and Web Console checks.
I have the ODBC 18+ driver installed, but the script is looking for 13. It seems to choke on this.
Yep – it needs to be updated for newer versions. The problem is – that “it depends” on what you are doing. For instance, if installing SCOM 2016 – you need these old versions, then apply a UR, then you can use newer MSOLEDB and OBDC drivers. If I make it tuned toward the latest versions, then it wont be useful for the older versions, but EVERYTHING supports SQL native client 11 and ODBC 13…. so I left the script alone for now. Ideally it would ask you, and inspect for all possible versions, but that can be a tad complex.
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!
I have registry monitoring fragments in my fragment library.
Thanks!
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.
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.
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.
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.
So, there’s still a glitch in the matrix. In the script, you define $SCOMRegPath, but in a standalone web console, this is likely to return the path to the agent installation, rather than the path to the web console installation. To locate a standalone web console, you need to look in HKLM:\SOFTWARE\Microsoft\System Center Operations Manager\12\Setup\WebConsole\InstallDirectory. And for a report server you would need to look in HKLM\SOFTWARE\Microsoft\System Center Operations Manager\12\Setup\Reporting\InstallDirectory.
Dang. Right you are. I tested as a truly “stand alone” without thinking about the agent. I’ll fix it soon…..
Hi,
Just to save people a lot of trouble, if using Linux\Unix agents, you will need this
https://gallery.technet.microsoft.com/scriptcenter/Script-to-update-SHA1-8a30c5ef
Spent several days scratching my head how to get them online.
Hi! Kevin,
As stated here:https://docs.microsoft.com/en-us/sql/relational-databases/native-client/sql-server-native-client?view=sql-server-ver15
The native SQL client is deprecated and Microsoft OLE DB Driver for SQL Server should be used instead..
Do you have any experience with this? I have myself tried with Microsoft OLE DB Driver for SQL Server 18.3 and SCOM 2019 and it alsmost works.
Only error seen until now is(bad enough):
OleDb Module encountered a failure 0x80004005 during execution and will post it as output data item. Unspecified error
: [DBNETLIB][ConnectionOpen (SECCreateCredentials()).]SSL Security error.
Workflow name: Microsoft.SystemCenter.SqlBrokerAvailabilityMonitorForPool
Hi Kevin,
We are planning to implement TLS 1.2 in our SCOM environment. To check which version of TLS is currently running on our servers, we logged into our SCOM servers and navigated to the following Registry Key location HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols, there we see under Protocols -> SSL 2.0 -> Client.
Does this mean TLS is not enabled or that TLS is enabled by default. Our Servers are running the Operating system (Windows Server 2012 R2 Standard Edition).
According to this link all the TLS protocols are enabled by default for Windows Server 2012 R2.
https://docs.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl–schannel-ssp-
If TLS is enabled by default but dosent show under Registry, then another question arise is, if we implement TLS 1.2 and if for some reason we have to revert back to current Security protocal how can we do it. Manually create Registry keys and DWORD Values and disable as per the following link.
https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings
Could you please advice.
Thanks,
Sreejeet
Kevin, I must have misread the info on your blog page for this MP(Implementing TLS 1.2 enforcement with SCOM)
I thought you meant that it will identify the TLS status of the SCOM Mgmt Servers and roles as well as on agent servers. That does not however seem to be the case.
“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.”.
Thanks again for the awesome work you do!
TS.
Hello Kevin,
We have GW in same Domain under same Kerberos Boundry;
Do we still need to have TLS 1.2 enforce on those GW servers(with ODBC and SLQ client installations) ?
Please suggest.
Hi Kevin,
Before implementing TLS 1.2 on SCOM 2012 R2, we have to check if the product connectors, 3rd party MPs etc are communicating properly with SCOM, this cannot be tested as there is no test environment with all the components similar to Production environment. In such a situation what shall we do, go ahead and implement TLS 1.2 in Production environmanet. As per your article if there happens any communication failures after implementing TLS 12. on SCOM 2012 R2, it is mentioned “you can always switch back and enable TLS 1.0 quickly if needed, its just a registry change and reboot away.” could you please mentione the steps to take if a communication failure happens. This will be of greate help.
Thank you in advance!
It simply means, change the registry keys back, that you changed when enforcing TLS 1.2 only communications. They are documented inside the script.
Dear Kevin, After implementaing TLS 1.2 we are not able to discover or monitor our HPUX agents . We run a network trace and find out that handshake is failing, SCOM MS initiated the communication on 1.2 but the reply coming back from agent is of TLS 1.0 so we open a case with HP and after analysis we came to know that HPUX agent (scx-1.6.2-342.hpux.11iv3.ia64.sh )we are using is compiled with openssl version 0.9.8 which doesn’t support TLS 1.2 only TLS 1.0.
Is there any HPUX agent which support TLS 1.2, kindly let me know your thoughts on this?
I am not aware of this, but have heard there are some older UNIX agents that don’t support TLS 1.2
Older but i think this is the last one scx-1.6.2-342.hpux.11iv3.ia64.sh which Microsoft provided or there is newer version after this?
Hi Kevin – I have implemented this mgmt pack and have disabled all protocols with the exception of TLS 1.2 (client and server). App TLS is set to use OS, Strong Cryptography is Supported. The only thing not set is SSL Functions.
My end point status says that Less Secure Protocols are still unhealthy. How do I get my endpiont to a Healthy state and what is with the SSL Functions? I see no information on how to set this option. Thank you.
What is this endpoint status coming from? My MP does not monitor that.
Hi Kevin,
You are amazing and we often refer to your post for any SCOM related queries. Mostly i will look for any articles posted by you.
The above post covers clearly how to enable the TLS 1.2 but i need clarity on few points.
1. Loading the Certificate in the Agent using MOMCertImport Tool can be included in the above.
2. How to load certificate into the Management server itself ?
In our setup, we have our AD CS server , So the SCOM mgmt server will have only one machine certificate which has “Client authentication” ability only.
Do we need to create a separate certificate with “Server Authentication” ability and import that cert into the mgmt server using MOMCertImport tool ???
Or
The default SCOM server machine certificate which has only the “Client authentication” ability is good enough for this ?
I am asking this because for SCCM, we need to generate a separate certificate with “Server authentication” ability so that it can authenticate the client workstations.
Thank You !
If you implemented all above your unix/linux agents still accept SSL communication on port 1270.
To enforce TLS for these agents as well you have to edit the agent file /etc/opt/omi/conf/omiserver.conf and make sure these 2 lines are enabled and true.
NoSSLv2=true
NoSSLv3=true
I’m not sure if NoTLSv1 is working as well since that will soon be needed.
Hi Kevin,
The links to both the script and the management pack are not working (or rather they work but do not point to the location of the items) as such I am not able to download either of them, please could you advise if they are still available.
Links updated.
Hi Kevin,
I am looking at changing our SCOM 2019 to TLS1.2, We currently have the Microsoft OLE DB Driver for SQL Server 18.5 installed on the Management Servers.
I am trying to work out if i still require “ODBC 11.0 or ODBC 13.0”, and would appreciated your feedback.
Thanks
If i do require it, can i use ODBC 17.7. We currently are using SQL 2019 CU8
and do not use ACS
i have run your script on a few management servers where i already used GPO to set the tls 1.0 and 1.1 registry settings to ‘disabled.’ native client and odbc drive 13 are installed. everything in scom seems to work fine besides connecting to the MP catalog from inside the console. i get the generic error about ‘web service is unavailable.’ this is in two 2016 environments and two 2019 environments. as soon as i re-enable old tls in the registry, i can connect to the catalog again.
I advise against using the MP catalog, so this sounds like a positive feature to me. 🙂
But seriously, I have SCOM 2016 and 2019 with TLS 1.2 only, and catalog works just fine. Something else is going on.
This is a .NET Framework issue. Add the registry keys to allow this communication.
PowerShell Method:
$NetRegistryPath = “HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727”
New-ItemProperty -Path $NetRegistryPath -Name “SchUseStrongCrypto” -Value “1” -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $NetRegistryPath -Name “SystemDefaultTlsVersions” -Value “1” -PropertyType DWORD -Force | Out-Null
$NetRegistryPath = “HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319”
New-ItemProperty -Path $NetRegistryPath -Name “SchUseStrongCrypto” -Value “1” -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $NetRegistryPath -Name “SystemDefaultTlsVersions” -Value “1” -PropertyType DWORD -Force | Out-Null
$NetRegistryPath = “HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727”
New-ItemProperty -Path $NetRegistryPath -Name “SchUseStrongCrypto” -Value “1” -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $NetRegistryPath -Name “SystemDefaultTlsVersions” -Value “1” -PropertyType DWORD -Force | Out-Null
$NetRegistryPath = “HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319”
New-ItemProperty -Path $NetRegistryPath -Name “SchUseStrongCrypto” -Value “1” -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $NetRegistryPath -Name “SystemDefaultTlsVersions” -Value “1” -PropertyType DWORD -Force | Out-Null
I used this solution today (finally) and the script worked beautifully. The only issue I ran into is that in my PowerShell console (mgmt server) I had to change the working directory to where the script was stored so that the path to sqlncli.msi (“.\sqlncli.msi”) became valid from the script’s perspective as this .msi was stored in the same folder as the script.
You sure took this very confusing and tedious process and made into something simple and painless.
Thank you for posting this!
This is Ninja Stuff Kevin!. You Sir, have outdone yourself!
Hi Kevin, images are broken, just a heads up!
Was looking at the documentation for SCOM 2022 in regards to tls1.2. Says it needs MSOLEDBSQL 18.2 or newer and ODBC 17.3 or newer. No mention of the SQL Client 12 referenced in your script.
Any plans to update the script to account for this difference?
https://docs.microsoft.com/en-us/system-center/scom/plan-security-tls12-config?view=sc-om-2022
I plan on updating it at some point. The problem is that our TLS support for different SCOM versions was very hodgepodge…. so I have been leaving this alone since technically these still work.
Pingback:Can’t open Console + SCOM 26340 & 26380 events | Effective IT
Hello Kevin,
I just have fresh installed SCOM 2019 UR4 enviornment. After enabling TLS 1.2 and rebooting the MS. The data access service is not starting and getting event ID # 26340, 26380.
I followed the latest MSFT link for SCOM 2019 – https://docs.microsoft.com/en-us/system-center/scom/plan-security-tls12-config?view=sc-om-2019
The .net version is 4.7, and SQL we have SQL 2019 CU15 – So I need not to install .net 4.6 or updates for SQL.
TLS 1.0/1.1 was already disabled on Windows 2019.
I installed – MSOLEDBSQL 18.2 and ODBC 18 (as this is latest and docs says ODBC 17.3 or later).
I used the script in the link to updates the operations manager registry key.
Any known issues with SCOM 2019 UR4 and TLS 1.2 ?
where should I look to resolve the issue.
There are known issues with the latest MSOLEDBSQL and ODBC. I asked the PG/support to update that link – as it is causing confusion.
Please use: https://docs.microsoft.com/en-us/system-center/scom/plan-sqlserver-design?view=sc-om-2019
Use ODBC 17.3 to 17.9, and MSOLEDBSQL 18.2 to 18.6.3.
Thanks Kevin.
I have used ODBC 17.9 and MSOLEDBSQL 19.0. It is working fine, but I will uninstall MSOLEDBSQL 19.0 and install 18.6.3
I have also imported SCOM Managememt MP version 10.22.10118.2. However TLS 1.2 is showing as fasle.
All the pre-requistes are completed as per the link : https://docs.microsoft.com/en-us/system-center/scom/plan-security-tls12-config?view=sc-om-2019
SCOM 2019 Ur4, on Windows 2019 with SQL 2019 CU15
.Net – 4.7.3190.0 on all the MG servers
ODBC 17.9 and MSOLEDBSQL 18.6.3
Windows Registry from configured as per the document.
The event logs are clean except few 10340 for OpsMgr DW Writer perfmon counters etc…
Any issues with my setup or with the SCOM Management MP ? Or Do I need to perform some extra configurations ?
Am i missing something? I imported the SCOM managment pack and I don’t see where the TLS information is located