Conexión ASP clásica a SQL Server 2014 sin TLS 1.0 utilizando ADODB. Conexión

Con TLS 1.0 deshabilitado en nombre del cumplimiento de PCI, no puedo hacer que funcione una aplicación ASP clásica de 32 bits.

Según las recomendaciones de MS / Stack Exchange, he instalado:

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

Esto ha hecho que se ejecuten nuestras aplicaciones ASP.NET / SSMS. Pero nuestra aplicación ASP clásica, que usa un ADODB.Connectionobjeto no funciona.

He intentado una cadena de conexión que usa Provider=SQLNCLI11;, pero eso tampoco parece ayudar. El proveedor de memoria compartida todavía se queja de que no hay nada en el otro extremo de la tubería. Mensaje de error:

Error de Microsoft SQL Server Native Client 11.0 '80004005'

Proveedor de memoria compartida: no hay proceso en el otro extremo de la tubería.

También intenté usar Canalizaciones con nombre con la cadena de conexión Provider=SQLNCLI11;Server=np:\\.\pipe\MSSQL$SQLEXPRESS\sql\query;Database=northwind;Trusted_Connection=Yes;y recibí este mensaje de error:

Error de Microsoft SQL Server Native Client 11.0 '80004005'

Proveedor de tuberías con nombre: no hay proceso en el otro extremo de la tubería.

¿Hay algún parche para ADODB que debería tener en cuenta? ¿Debería considerar el uso de Canalizaciones con nombre de alguna otra manera o similar? (aunque estoy un poco desconcertado de por qué la memoria compartida no funciona, independientemente de la configuración de TLS)

Actualizaciones de comentarios:

El servidor web y el servidor SQL están en el mismo cuadro.

Es una instancia con nombre SQLExpress. La cadena de conexión que funciona con TLS 1.0 habilitado es:

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

También he intentado:

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

Ninguno de los dos funciona una vez que TLS 1.0 está deshabilitado. Sé que Trusted_Connection / Integrated_Security es redundante, pero jugar con esto tampoco parece ayudar.

He activado, habilitado, deshabilitado y ordenado tanto TCP como canalizaciones con nombre. El nombre de la tubería utilizada en la cadena de conexión anterior es directamente de la Configuración del servidor para esa instancia. También he intentado deshabilitar la memoria compartida para asegurarme de que las canalizaciones con nombre funcionen. No he probado TCP (como si la memoria compartida no funcionara debido a TLS, ¿por qué TCP?) La memoria compartida y las canalizaciones con nombre funcionan con TLS 1.0 habilitado. Tan pronto como volteo la clave de registro para deshabilitar TLS 1.0 (y reiniciar), aparecen los mensajes de error anteriores. Probablemente solo vamos a poner esta máquina detrás de un proxy.

El servicio del servidor SQL no se iniciará después de deshabilitar TLS 1.0 y SSL 3.0

CU1 aborda el problema descrito en ese enlace en mi pregunta anterior. La instancia de SQL Server comienza con TLS 1.0 deshabilitado (gracias a la actualización de MS). Las aplicaciones basadas en .NET funcionan bien con la instancia de SQL (después de la actualización a 4.6). Esta pregunta es específica de una aplicación ASP clásica (32 bits). Entiendo que CU1 también parchea al cliente nativo, de ahí mi confusión sobre por qué esto no está funcionando.

Es posible que esté intentando utilizar controladores heredados de 32 bits.

Intente ejecutar C: \ Windows \ SysWOW64 \ odbcad32.exe para crear un DSN que se conecte a su base de datos de SQL Server utilizando el controlador de SQL Server de 32 bits. Primero pruebe la conectividad usando la GUI.

Luego intente especificar su DSN en su cadena de conexión de la siguiente manera:

DSN=myDsn;Uid=myUsername;Pwd=;

La versión de 64 bits se encuentra en: C: \ Windows \ System32 \ odbcad32.exe

PD: No he probado esto, pero el nombre del proveedor para el SQL Server de 32 bits es en realidad "SQL Server". Sería bueno si todo lo que tuviera que hacer fuera reemplazar SQLNCLI11 con SQL Server. Aquí está mi archivo DSN que creé con la versión de 32 bits: observe el controlador ...

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

Necesitará la corrección ADO.NET y SQLNCLI11 para sus controladores para que funcionen con TLS 1.2.

A partir del 29 de enero, Microsoft SQL Server admite TLS 1.2 para SQL Server 2008, SQL Server 2008 R2, SQL Server 2012 y SQL Server 2014 y los principales controladores de clientes como Server Native Client, Microsoft ODBC Driver para SQL Server, Microsoft JDBC Driver para SQL Server y ADO.NET (SqlClient).

Puedes leer más sobre el lanzamiento aquí . La lista de compilaciones que admiten TLS 1.2 junto con las ubicaciones de descarga de componentes de cliente y servidor está disponible en KB3135244 .