web-dev-qa-db-fra.com

Classic ASP Connexion à SQL Server 2014 sans TLS 1.0 à l'aide de Adodb.Connection

Avec TLS 1.0 étant désactivé au nom de la conformité PCI, je ne suis pas en mesure d'obtenir une application de 32 bits classique ASP fonctionnant.

Par MS/Stack Exchange Recommandations, j'ai installé:

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

Cela a obtenu nos applications ASP.NET/SSMS en cours d'exécution. Mais notre application classique ASP, qui utilise un objet ADODB.Connection ne fonctionne pas.

J'ai essayé une chaîne de connexion qui utilise Provider=SQLNCLI11;, mais cela ne semble pas aider non plus. Le fournisseur de mémoire partagé se plaint toujours de rien n'étant sur l'autre extrémité du tuyau. Message d'erreur:

Microsoft SQL Server Native Client 11.0 Erreur '80004005'

Fournisseur de mémoire partagé: aucun processus n'est à l'autre extrémité du tuyau.

J'ai également essayé d'utiliser des tuyaux nommés avec la chaîne de connexion Provider=SQLNCLI11;Server=np:\\.\pipe\MSSQL$SQLEXPRESS\sql\query;Database=northwind;Trusted_Connection=Yes; et reçu ce message d'erreur:

Microsoft SQL Server Native Client 11.0 Erreur '80004005'

Nommé Fournisseur de Tipes: Aucun processus n'est sur l'autre extrémité du tuyau.

Y a-t-il un correctif pour Adodb que je devrais être au courant? Devrais-je envisager d'utiliser des tuyaux nommés d'une autre manière ou similaire à la place? (Bien que je sois un peu déconcerté de la raison pour laquelle la mémoire partagée ne fonctionne pas, quels que soient les paramètres TLS))


Mises à jour des commentaires:

Le serveur Web et le serveur SQL sont sur la même boîte.

C'est une instance nommée sqlexpress. La chaîne de connexion fonctionnant avec TLS 1.0 activé est:

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

J'ai aussi essayé:

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

Ni travailler une fois que TLS 1.0 est désactivé. Je sais que confiance_connexion/intégré_security est redondant, mais qui ne semble pas aider, cela ne semble pas aider non plus.

J'ai activé l'activation, la désactivation et la commande pour les pipes TCP et nommés. Le nom du tuyau utilisé dans la chaîne de connexion ci-dessus est directement à partir de la configuration du serveur pour cette instance. J'ai également essayé de désactiver la mémoire partagée pour vous assurer que les pipes nommées fonctionnent. Je n'ai pas essayé TCP (comme si la mémoire partagée ne fonctionne pas à cause de TLS, pourquoi TCP?) TCP?) La mémoire partagée et les tuyaux nommés fonctionnent tous les deux avec TLS 1.0 activé. Dès que je retourne la clé de registre pour désactiver TLS 1.0 (et redémarrer), les messages d'erreur ci-dessus se produisent. Nous allons probablement simplement mettre cette machine derrière un proxy.

SQL Server Service ne démarre pas après la désactivation de TLS 1.0 et SSL 3.

La question décrite dans ce lien est traitée par CU1 dans ma question posée ci-dessus. L'instance SQL Server commence par TLS 1.0 désactivée (grâce à la mise à jour MS). Les applications .NET fonctionnent parfaitement avec l'instance SQL (après la mise à jour de 4.6). Cette question est spécifique à une application classique ASP (32 bits). Je crois comprendre que le client natif est également corrigé par CU1, d'où ma confusion sur la raison pour laquelle cela ne fonctionne pas.

8
userx

Vous pourriez éventuellement essayer d'utiliser des pilotes hérités 32 bits.

Essayez d'exécuter C:\Windows\SYSWOW64\ODBCAD32.EXE Pour créer un DSN qui se connecte à votre base de données SQL Server à l'aide du pilote SQL SQL 32 bits. Premier testez la connectivité à l'aide de l'interface graphique.

Ensuite, essayez de spécifier votre DSN dans votre chaîne de connexion comme:

DSN=myDsn;Uid=myUsername;Pwd=;

La version 64 bits est située dans: C:\Windows\System32\odbcad32.exe

P.s. Je n'ai pas essayé cela, mais le nom du fournisseur du serveur SQL 32 bits est en réalité "SQL Server". Ce serait bien si tout ce que vous avez dû faire était de remplacer SQLNCLI11 avec SQL Server. Voici mon fichier DSN j'ai créé avec la version 32 bits - Notez le pilote ...

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