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.
The SQLOLEDB provider and the SQL Server ODBC driver that ship with Windows are legacy components provided only for backwards compatibility. These have been deprecated since SQL 2005.
According to this blog post by the MSSQL Tiger Team:
SQLOLEDB will not receive support for TLS 1.2. You will need to switch
your driver to one of the supported drivers listed in
https://support.microsoft.com/en-us/kb/3135244
You should be able to install SQL Server Native Client 2012 and use that OLE DB provider with only a connection string change (change Provider=SQLOLEDB to Provider=SQLNCLI11). Of course, once should test to avoid surprises. For example, I recall someone experiencing behavior differences with the SQL Server Native Client provider and ADO classic when server API cursors were used, although the commonly used firehose cursors were fine.
EDIT
The new OLE DB driver, MSOLEDBSQL, has been released. This new driver includes the support for the latest TLS 1.2 standards and is backwards compatible with SQL Server Native Client 11 (SQLNCLI11). See the Microsoft SQLNCLi team blog announcement. Change the connection string to Provider=MSOLEDBSQL after installation.
EDIT #2
Time continues to march on. The SQL Server Native Client OLE DB driver is now deprecated in favor of MSOLEDBSQL. End of support for the final 2012 SNAC version is July 12, 2012.
Furthermore, as David called out in his answer, Microsoft recently added support for TLS 1.2 MDAC components in Windows 10 Build 17763.1554:
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)
No enhancements (e.g. support for post-SQL 2000 data types) were added, though.
In summary, newer SQL Server client drivers provides more control over the specific driver and version without a direct OS patch level dependency. Modern drivers like MSOLEDBSQL and ODBC Driver n for SQL Server are continuously improved to support latest SQL Server features and security standards.
EDIT#3
SQLOLEDB and the SQL Server ODBC driver (part of MDAC, shipped and serviced with Windows) has support for TLS 1.2 with October 20, 2020 build, version 17763.1554. This applies to Windows 10 and Windows Server 2019 or later.
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.
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
Following changes on my end fixed the issue after TLS1.2 upgrade on Azure cloud -
change Provider=SQLOLEDB to Provider=SQLNCLI11
update ADODB version to Microsoft ActiveX Data Objects 6.0 Library
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://learn.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.
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
Related
One of our servers went for a reboot last night after doing OS and SQL Server patching (SQL Server 2016 latest CU). Since then any call to a linked server from the patched server fails with the above error.
Other servers can still connect to the patched server, just outbound doesn't seem to work at all.
We also have an issue with the SQL Server Browser service wont start "stopped unexpectedly", although not sure if its related
Any help greatly appreciated
Microsoft OLEDB Providers - part of the SQL Server Native Client (SNAC) are deprecated:
SQLNCLI10
SQLNCLI11
You need to install Microsoft OLE DB Driver for SQL Server:
MSOLEDBSQL
The switch happened in 2018. You can read about it here:
Announcing the new release of OLE DB Driver for SQL Server
Released: Microsoft OLE DB Driver for SQL Server
Ok people, problem solved.
One of the updates tried to upgrade the OLEDB connectors, ran into a problem and bailed. It had already deleted the DLLs for the drivers though.
Finding the drivers on the Dev server and copying them across solved the issue.
For those bleeding on about SNAC on being on SQL12, that was it's release version. It's been a staple ever since and is installed as standard by SQL16. It's not untill 2022 that it's replaced
I know this is a very generic question, and already answered in some forums but I am having issue. I am having SQL Server 2012 and 2015 (which would be migrated to 2018). The SQL OLEDB connection with SqlClient works well with TLS 1.1 or TLS 1.0. But when we use TLS 1.2, it fails to connect.
I have gone through this and this link, explaining the same, but any more changes I need to make in my application, regarding Provider etc.
Thanks In Advance!!!..
You should Use "SQLNCLI11" driver to connect to the database or you can install new OLEDB provider from here :
https://www.microsoft.com/en-us/download/details.aspx?id=56730
and set provider to "MSOLEDBSQL"
Where can I find the information with which SQL Server versions the standard ODBC driver named "SQL Server" (SQLSRV32.dll) is compatible ?
For sure it works with Microsoft SQL Server 2008 R2 because we are using them successfully.
But what about the following?
Microsoft SQL Server 2012
Microsoft SQL Server 2014
Microsoft SQL Server 2016
Microsoft SQL Server 2017
Unfortunately I could not find that information after hours using my favourite web search engine.
On https://learn.microsoft.com/en-us/sql/connect/odbc/windows/microsoft-odbc-driver-for-sql-server-on-windows
are descriptions of newer drivers which can be downloaded, but we don't have admin privileges to install one of them.
We have to use the standard ODBC driver which is installed on Windows out of the box, because the application should run on customers desktop PCs.
Probably this information also depends on the version of the DLL. As an example let's take the version 10.00.15063.00, but it can vary, for the reason mentioned above.
We do not exactly know which Windows versions the customers use. Can be [Win7, Win8, Win10] / [Home/Pro/Enterprise].
The "SQL Server" ODBC driver that ships with Windows is part of Microsoft/Windows Data Access Components (MDAC/WDAC) and is an operating system component nowadays. The specific driver version number shouldn't be a concern given that the interface is the same. This ODBC driver is legacy and has not been enhanced for many years. It is included with Windows only to support legacy applications and is unaware the new SQL data types and features introduced since the release of SQL 2005. It is not intended to be used for new development but nothing prevents you from using so.
Most Java applications use a JDBC driver for relational database access. You could use a modern JDBC driver and include it with your application. That will allow you to use newer SQL features.
I'm getting this when trying to connect to SQL Server 2008 using Moodle:
4004: Unicode data in a Unicode-only collation or ntext data cannot
be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7
or earlier.
I changed the version to 8.0 in the ini file, but no luck. Any ideas?
From the Moodle doc:
The SQL Server complaining that it doesn't support pure Unicode via
TDS or older versions of ODBC. Microsoft has deprecated DB-Library a
long ago, in favor of ODBC, OLE DB, or SQL Native Client. Many new
features of SQL 2005 aren't accessible via DB-Library so if you need
them, you could have to switch away from tools based on TDS and
DB-Library :(
My config file was messed up. I was not using version 8.0 of TDS. I have explicitly set it to use 8.0. Since I fixed that, everything works fine.
What is the difference between SQL Server Native Client connection and ODBC connection? What are the pros and cons of these two?
Huh? ODBC is officially dead? Someone might want to let Microsoft know that:
Microsoft is Aligning with ODBC for Native Relational Data Access
From the above link:
ODBC is the de-facto industry standard for native relational data access...
and
The commercial release of Microsoft SQL Server, codename 'Denali' will be the last release to support OLE DB.
and finally,
"We encourage you to adopt ODBC in the development of your new and future versions of your application. You don’t need to change your existing applications using OLE DB, as they will continue to be supported on Denali throughout its lifecycle. While this gives you a large window of opportunity for changing your applications before the deprecation goes into effect, you may want to consider migrating those applications to ODBC as a part of your future roadmap. Microsoft is fully committed to making this transition as smooth and easy as possible.""
(emphasis added)
ODBC is useful for times when the underlying database might change but you don't want your code to (assuming the SQL stays the same across technologies). You could connect to an Oracle database one day and switch out to a SQL server database the next. The disadvantage is that you don't get the optimizations that having specific drivers affords you. The SQL Server Native client driver has been proven to be much faster than just using a standard ODBC driver.
What is the difference between SQL Server Native Client connection and ODBC connection?
ODBC is a standardized API.
ODBC drivers are shared libraries that use native protocols (like SQL Server shared memory, or SQL Server TCP/IP) to implement the ODBC interface.
In other words, ODBC is an abstraction that enables code to work against multiple database technologies.
It's similar to Java's JDBC, or Python's DB-API, or GO's database/sql, except ODBC drivers use C functions. Also, they are more frequently installed at a system level.
ODBC has the usual pros and cons of any abstraction.
Pros: Makes code more flexible/portable.
Cons: Adds performance overhead and has fewer features.
It sounds like you know that you will use SQL Server and will always use SQL Server.
In that case, I'd use a native client library if it's available.
SQL Server Native Client is a single dynamic-link library (DLL) containing both the SQL OLE DB provider and SQL ODBC driver for Windows.
SNAC 11 is a single dynamic-link library (DLL) containing both the SQL
OLE DB provider and SQL ODBC driver for Windows. It contains run-time
support for applications using native-code APIs (ODBC, OLE DB and ADO)
to connect to Microsoft SQL Server 2005, 2008, 2008 R2, and SQL Server
2012. A separate SQL ODBC-only driver is available for Linux.
https://blogs.msdn.microsoft.com/sqlreleaseservices/snac-lifecycle-explained/