Sql-server – Classic ASP Connection to SQL Server 2014 without TLS 1.0 using ADODB.Connection

connectivitysql serversql server 2014

With TLS 1.0 being disabled in the name of PCI compliance, I'm unable to get a 32-bit Classic ASP application working.

Per MS / Stack Exchange recommendations, I've installed:

  1. SQL Server 2014 SP1 CU1
  2. .NET Framework 4.6

This has gotten our ASP.NET applications / SSMS running. But our Classic ASP application, which uses an ADODB.Connection object is not working.

I've tried a connection string which uses Provider=SQLNCLI11;, but that doesn't seem to help either. The Shared Memory provider is still complaining about nothing being on the other end of the pipe. Error message:

Microsoft SQL Server Native Client 11.0 error '80004005'

Shared Memory Provider: No process is on the other end of the pipe.

I also tried using Named Pipes with the connection string Provider=SQLNCLI11;Server=np:\\.\pipe\MSSQL$SQLEXPRESS\sql\query;Database=northwind;Trusted_Connection=Yes; and received this error message:

Microsoft SQL Server Native Client 11.0 error '80004005'

Named Pipes Provider: No process is on the other end of the pipe.

Is there a patch for ADODB that I should be aware of?
Should I consider using Named Pipes in some other way or the like instead? (although I'm a little baffled as to why shared memory doesn't work, regardless of the TLS settings)

Updates from comments:

The web server and the SQL Server are on the same box.

It's a SQLExpress named instance. The connection string working with TLS 1.0 enabled is:

"Driver={SQL Server}; Server=.\SQLExpress; Database=northwind; Trusted_Connection=Yes; Integrated_Security=True;"

I've also tried:

"Provider=SQLNCLI11; Server=.\SQLExpress; Database=northwind; Trusted_Connection=Yes;"

Neither work once TLS 1.0 is disabled. I know Trusted_Connection / Integrated_Security is redundant, but messing around with these doesn't seem to help either.

I've toggled enabling, disabling, and order for both TCP and named pipes. The name of the pipe used in the connection string above is directly from the Server Configuration for that instance. I've also tried disabling Shared Memory to make sure named pipes is working. I haven't tried TCP (as if Shared Memory doesn't work because of TLS, why would TCP?) Shared Memory and Named Pipes both work with TLS 1.0 enabled. As soon as I flip the registry key to disable TLS 1.0 (and reboot), the above error messages occur. We're likely just going to put this machine behind a proxy.

SQL server service won’t start after disabling TLS 1.0 and SSL 3.0

The issue described in that link is addressed by CU1 in my posed question above. The SQL Server instance DOES start with TLS 1.0 disabled (thanks to the MS update). .NET based applications work just fine with the SQL instance (after update to 4.6). This question is specific to a Classic ASP (32-bit) application. My understanding is that the native client is also patched by CU1, hence my confusion as to why this isn't working.

Best Answer

You might possibly be trying to use 32 bit legacy drivers.

Try running C:\Windows\SysWOW64\odbcad32.exe to create a DSN that connects to your SQL Server database using the 32 bit SQL Server driver. First test the connectivity using the GUI.

Then try specifying your DSN in your connection string like so:

DSN=myDsn;Uid=myUsername;Pwd=;

The 64-bit version is located in: C:\Windows\System32\odbcad32.exe

P.S. I've not tried this but the provider name for the 32-bit SQL Server is actually "SQL Server". It'd be nice if all you had to do was replace SQLNCLI11 with SQL Server. Here's my file DSN I created with the 32 bit version--notice the driver...

[ODBC]
DRIVER=SQL Server
UID=sa
WSID=P13-0000
APP=Microsoft® Windows® Operating System
SERVER=mcdba1
Related Question