'Does Microsoft OLE DB Provider for SQL Server support TLS 1.2
Our client recently upgraded from TLS 1.0 to TLS 1.2 and after this our software cannot connect with SQL server. It uses OLE DB provider for connecting to SQL server. Below is the error which is returned from SQL server-
[DBNETLIB][ConnectionOpen SECDoClientHandshake()]SSL Security error SQL State: 08001 SQL Error Number: 18
Could not find any useful information related to whether Microsoft OLE DB Provider for SQL Server support TLS 1.2 or not.
One of the links I found seems to suggest that it is not supported. https://forums.iis.net/t/1233674.aspx?connecing+SQL+server+DB+issue+after+installingTLS1+2+in+SQL+srver+with+classic+asp+application+
Hence, wanted to check on stackoverflow in case anyone has any information on this.
Solution 1:[1]
This may not be a solution for you, since it's a future fix your client may not be able to wait for, but apparently Microsoft is undeprecating the OLEDB Driver, with a new release supporting TLS 1.2 out Q1 2018: https://blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/announcing-the-new-release-of-ole-db-driver-for-sql-server/
The new Microsoft OLE DB Driver for SQL Server, or msoledbsql, will also introduce multi-subnet failover capabilities in this first upcoming release, and keeps up with latest TLS 1.2 standards.
Also, this first upcoming release will be a stand-alone install package that is out-of-band with SQL Server lifecycle. This also means the driver will not be packaged in the SNAC library, nor coupled with any other driver.
Solution 2:[2]
TLS 1.2 Support has been added to sqloledb in Windows. See KB4580390.
This includes support both ODBC and OleDB providers in MDAC:
Adds support for the Transport Layer Security (TLS) 1.1 and 1.2 protocols when connecting to SQL Server using the data providers in Microsoft Data Access Components (MDAC)
You can verify that MDAC has been updated by checking the Windows build number, anything 17763.1554 or later has this fix. MDAC has not been distributed outside of OS patches for many years.
The build is visible in winver or in Powershell with [environment]::OSVersion.Version.Build
Solution 3:[3]
Following changes on my end fixed the issue after TLS1.2 upgrade on Azure cloud -
- change
Provider=SQLOLEDBtoProvider=SQLNCLI11 - update ADODB version to Microsoft ActiveX Data Objects 6.0 Library
Solution 4:[4]
This might not directly answer the question, but it is still related to sql server connection with TLS 1.2 error.
I'm maintaining an old ASP Classic website which broke with following error.
Microsoft OLE DB Provider for SQL Server error '80004005'
[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.
Changing Provider from SQLOLEDB to SQL Server Native Client 11.0 or any higher version which is available fixed the error.
Thus, changing connection string from
constr = "Provider=SQLOLEDB;Data Source=..."
to
constr = "Provider=SQL Server Native Client 11.0;Data Source=...."
might work too
Solution 5:[5]
The use of "Microsoft OLEDB Driver for SQL Server" is what worked for us but I can also confirm Native Driver 11 also tests OK.
Here was our scenario: after we disabled TLS 1.0 and 1.1 and enabled TLS 1.2, Crystal Reports using the "Microsoft OLEDB Provider for SQL Server" would no longer connect. Instead you get a user/pw prompt that fails with even with valid credentials. In our case we were running Crystal Reports from within an ASP.NET v4.5.2 application that has the Crystal 13 Viewer embedded in. Users pick from a list of reports and run them and they run without a prompt with TLS 1.0 enabled.
To fix this, we had to open the report in the designer and convert it report from using the "Microsoft OLEDB Provider for SQL Server" to using the "Microsoft OLEDB Driver for SQL Server".
If you don't see the driver in your list here's the OLEDB Driver for SQL Server: https://docs.microsoft.com/en-us/sql/connect/oledb/download-oledb-driver-for-sql-server?view=sql-server-ver15
Credit to Dan Guzman who mentioned the existence of the "driver" in a somewhat buried comment and an update above.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Dan Guzman |
| Solution 2 | |
| Solution 3 | Tiw |
| Solution 4 | AaA |
| Solution 5 |
