最初の問題:サーバーをビルドするのに必要だった SQL Server 2008 R2への最新のパッチ (2016年3月3日リリース)を適用したため、10.50.6542に接続できなくなりました。このパッチは、TLS 1.2をサポートするためのものです。
(サーバーで直接クライアントツールを使用して接続しようとすると)発生するエラーは
"A connection was succesfully established with the server, but then an error occurred during the pre-login handshake"
サーバーはWindows Server 2012 R2であり、NET Framework 4.6.1を実行しています(一部の投稿は、この問題を引き起こしている古いバージョンの.NET Frameworkを指していますが、これは私のケースではありません)。
これが修正されるかどうかを確認するために、次のパッケージを実行してみました...
...これらのどれも必要ではなく、何も助けになりませんでした...
誰かこれを経験しましたか?アイデアや提案はありますか?
ありがとう!
24時間後の1つの更新SQL Serverエラーログを調べて、開始、5回の失敗したログイン試行、および停止のみを含むエントリを探しました。その期間内のすべてのメッセージ(合計107エントリ)から、エラーのようなものを含む唯一のメッセージは
The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.
ただし、このメッセージは...パッチを適用する前でもサーバーの起動時に報告されているので、それが赤いニシンであると100%確信しています。ログイン試行の失敗の結果として、SQL Serverエラーログにログは挿入されません。
別の更新
ここの人々から得た提案に基づいて、サーバーに最新バージョンのSSMS(17.3)をダウンロードしてインストールしました。今回接続を試みたところ、別のエラーが発生したため、先に進んでいるように見えますが、まだありません。
つまり、古いバージョンのSSMSが.net 3.5をターゲットにしていることは事実であり、新しいバージョンの.netフレームワークがある場合でもクライアント接続が機能しないのはなぜでしょうか?ほとんどのクライアントコンポーネントが更新されている場合でも、パイプの反対側にあります。
調査した(そして破棄した)いくつかの事柄
Microsoft SQL ServerのTLS 1.2サポート で提案されているように、「Microsoft ODBC Driver for SQL Server "」をインストールしようとしましたが、それでも違いはありませんでした。インストール後、エラーメッセージは同じです
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2( 同じ記事 で提案されているとおり)にレジストリキーを追加しようとしました。同じエラー…
最後に!太陽の下ですべてを試して3日後、私は自分の問題の根本的な原因を見つけました。
あはは!このパッチがなぜこの特定のサーバーではなく他のサーバーにうまく配備されているのかを理解しようとしているグループと集まった瞬間でした。
私たちは、(特に整頓されたメモ帳に一覧表示されているものの中で)何か別のことが、このSQL Server 2008 R2が証明書とSQL Server構成マネージャーのいくつかの設定を介して転送中の暗号化(別名SSL暗号化)用に構成されていることに気付きました:
[Instance_Name]のプロトコル、次に[プロパティ](証明書タブ)で、暗号化された通信の目的で作成した証明書を選択しました。
同じウィンドウ([フラグ]タブ)で、データベースエンジンのForceEncryptionオプションを[はい]に設定します
それで私たちは考え始めました...問題が証明書自体である場合はどうなりますか?次に、暗号化構成を削除し(SQL Serverビルド10.50.6542のパッチはまだ適用されています)、接続が機能し始め、パッチとSSL構成の組み合わせが問題であることが確認されました。
さらに調査し、排除のプロセスを経て、使用していた証明書に問題を絞り込みました。 証明書は(自己署名証明書を作成するために)makecertを使用して作成され、-aパラメータを使用していませんでした。このパラメーターは、使用するハッシュアルゴリズムをmakecertに指示します。指定しない場合、makecertはTLS 1.2と互換性のないデフォルトのMD5署名ハッシュアルゴリズムを使用します。
TLS 1.2 RFC でも明示的に確認できます…
MD5
MD5 [MD5] is a hashing function that converts an arbitrarily long
data stream into a hash of fixed size (16 bytes). Due to
significant progress in cryptanalysis, at the time of publication
of this document, MD5 no longer can be considered a 'secure'
hashing function.
したがって、この問題を解決するための解決策は、-a SHA256パラメータをmakecertに追加することです(makecertのバージョン6.3.9600.17298ではなく、古いバージョン5.1313790.0を使用していることを確認してください。 )。
難問全体を把握するのに3日かかったので、これらすべてを書いています。いつか誰かがこれから恩恵を受けることを願っています。 MicrosoftのみがBIG BOLD文字に含めていた場合、パッチが説明されている記事ではMD5はサポートされなくなりました。
@ Mr.Brownstoneと@sepupicに感謝します。
TLS 1.2は、.NET 4.6まではデフォルトのセキュリティプロトコルにならず、.NET 4.5まではサポートされていなかったため、4.5未満の.NETランタイムをターゲットとするクライアントを使用している場合は、デフォルトではTLS 1.2を使用して通信します。
特定のシナリオでは、クライアントはたまたまSQL Server Management Studioです。 2014年までのバージョンのManagement Studioは、ターゲットランタイムとして.NET 3.5 SP1を使用していました。残念ながら、TLS 1.2をそのまま使用して接続することはできません。
問題を解決するには、Management Studioのインストールを最新バージョンにアップグレードしてください。これは.NET 4.6.1を対象としており、デフォルトのセキュリティプロトコルとしてTLS 1.2を使用します。
SSMSの最新バージョンに更新できない場合の2番目の解決策は、Windows Serverが.NET 3.5で指定されたプロトコルを無視し、代わりにTLS 1.2を使用するように強制するレジストリ変更を行うことです。私はこれに反対することをお勧めします(SSMSを更新できない場合は、おそらくレジストリ設定の変更が許可されていない可能性があります)が、完全性のために情報を含めました。
.NET 3.5がTLS 1.2を使用するように強制する方法と、どのレジストリキーを変更する必要があるかについての詳細は、以下にあります。
Windows Server 2012の.NET Framework 3.5に含まれるTLSシステムのデフォルトバージョンのサポート