web-dev-qa-db-ja.com

クラシックASP ADODB.Connectionを使用したTLS 1.0を使用しないSQL Server 2014への接続

PCIコンプライアンスという名目でTLS 1.0が無効になっているため、32ビットのクラシックASPアプリケーションを機能させることができません。

MS/Stack Exchangeの推奨事項に従って、私はインストールしました：

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

これにより、ASP.NETアプリケーション/ SSMSが実行されます。しかし、Classic ASP ADODB.Connectionオブジェクトを使用するアプリケーションは機能しません。

私はProvider=SQLNCLI11;を使用する接続文字列を試しましたが、それも役に立たないようです。共有メモリプロバイダは、パイプの反対側に何もないことに不満を抱いています。エラーメッセージ：

Microsoft SQL Server Native Client 11.0エラー「80004005」

共有メモリプロバイダー：パイプの反対側にプロセスはありません。

接続文字列Provider=SQLNCLI11;Server=np:\\.\pipe\MSSQL$SQLEXPRESS\sql\query;Database=northwind;Trusted_Connection=Yes;で名前付きパイプを使用してみたところ、次のエラーメッセージが表示されました：

Microsoft SQL Server Native Client 11.0エラー「80004005」

名前付きパイププロバイダー：パイプの反対側にプロセスはありません。

注意が必要なADODBのパッチはありますか？名前付きパイプを他の方法などで使用することを検討すべきですか？ （TLS設定に関係なく、共有メモリが機能しない理由については少し困惑していますが）

コメントからの更新：

WebサーバーとSQL Serverは同じボックスにあります。

これはSQLExpress名前付きインスタンスです。 TLS 1.0を有効にして動作する接続文字列は次のとおりです。

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

私も試しました：

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

TLS 1.0を無効にすると、どちらも機能しません。 Trusted_Connection/Integrated_Securityが冗長であることは知っていますが、これらをいじってみても効果がないようです。

TCPと名前付きパイプの両方の有効化、無効化、および順序を切り替えました。上記の接続文字列で使用されるパイプの名前は、そのインスタンスのサーバー構成から直接取得しています。また、名前付きパイプが機能していることを確認するために共有メモリを無効にしてみました。TCP（TLSが原因で共有メモリが機能しない場合、TCPを使用する理由は？）パイプはどちらもTLS 1.0を有効にして動作します。レジストリキーをフリップしてTLS 1.0を無効にして（および再起動すると）、上記のエラーメッセージが表示されます。このマシンをプロキシの背後に配置するだけです。

TLS 1.0およびSSL 3.0を無効にした後、SQLサーバーサービスは開始されません

そのリンクで説明されている問題は、上記の私の提起された質問でCU1によって対処されています。 SQL Serverインスタンスは、TLS 1.0を無効にして起動します（MS更新のおかげです）。 .NETベースのアプリケーションは、SQLインスタンスで正常に動作します（4.6への更新後）。この質問はクラシックASP（32ビット）アプリケーションに固有です。私の理解では、ネイティブクライアントにもCU1がパッチを適用しているため、なぜこれが機能しないのか混乱しています。

sql-serversql-server-2014connectivity
8
userx

32ビットのレガシードライバーを使用しようとしている可能性があります。

C：\ Windows\SysWOW64\odbcad32.exeを実行して、32ビットSQL Serverドライバーを使用してSQL Serverデータベースに接続するDSNを作成します。最初に、GUIを使用して接続をテストします。

次に、次のように接続文字列でDSNを指定してみます。

DSN=myDsn;Uid=myUsername;Pwd=;

64ビットバージョンは、C：\ Windows\System32\odbcad32.exeにあります。

追伸私はこれを試していませんが、32ビットSQL Serverのプロバイダー名は実際には「SQL Server」です。 SQLNCLI11をSQL Serverに置き換えるだけでよかったのですが。 32ビットバージョンで作成したファイルDSNを以下に示します-ドライバーに注意してください...

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

ドライバーがTLS 1.2で動作するようにするには、ADO.NETおよびSQLNCLI11修正プログラムが必要です。

1月29日の時点で、Microsoft SQL Serverは、SQL Server 2008、SQL Server 2008 R2、SQL Server 2012およびSQL Server 2014のTLS 1.2と、サーバーネイティブクライアント、Microsoft ODBC SQL Server、SQL ServerおよびADO.NET（SqlClient）用のMicrosoft JDBCドライバー。

リリースの詳細については here を参照してください。 TLS 1.2をサポートするビルドと、クライアントおよびサーバーコンポーネントのダウンロード場所のリストは KB3135244 にあります。

0
Amit Banerjee