web-dev-qa-db-ja.com

SQL Server 2012のリンクサーバーでKerberos認証が機能しない

Windows Server 2012でSQL Server 2012を実行している2つのSQL Serverを使用してDEV/TEST環境をセットアップしています。WindowsServer 2008でSQL Server 2005から移行していますが、これはすでに正常に稼働しています。

SQL Server 2012では、Kerberos認証が機能していません。

各サーバーには独自のActive Directoryアカウントがあり、Active Directoryユーザーとコンピューターを通じて「サービスプリンシパル名の書き込み」および「サービスプリンシパル名の読み取り」権限が付与されています。 SQL Server 2005サーバーに接続して実行する場合:

SELECT net_transport, auth_scheme 
FROM sys.dm_exec_connections 
WHERE session_id = @@SPID;

そうですか:

net_transport    auth_scheme
TCP              KERBEROS 

新しいSQL Server 2012インスタンスに対して同じクエリを実行すると、次のようになります。

net_transport    auth_scheme
TCP              NTLM 

SetSPN -Q MSSQLSvc/*を使用してアクティブドメインにサービスプリンシパル名をクエリすると、2005と2012の両方のサーバーがサーバーの名前を除いてまったく同じように表示されます。

例えば:

MSSQLSvc/SERVERa2005.domain.inet
MSSQLSvc/SERVERa2005domain.inet:1433
MSSQLSvc/SERVERb2005.domain.inet
MSSQLSvc/SERVERb2005domain.inet:1433
MSSQLSvc/SERVERa2012.domain.inet
MSSQLSvc/SERVERa2012domain.inet:1433
MSSQLSvc/SERVERb2012.domain.inet
MSSQLSvc/SERVERb2012domain.inet:1433

SQL Server 2012に対してKerberos認証を有効にするには、他に何が必要ですか? Books Onlineには、SPNを設定する必要があることを除いて、他に何も言うことがないようです。明らかに、そうです。両方の2012マシンのSQL Serverエラーログは次のように述べています。

2012-12-10 14:55:47.630 The SQL Server Network Interface library 
                            successfully registered the Service Principal Name (SPN)
                            [ MSSQLSvc/SERVERa2012.domain.inet ] for the SQL Server
                            service. 

2012-12-10 14:55:47.630 The SQL Server Network Interface library 
                            successfully registered the Service Principal Name (SPN) 
                            [ MSSQLSvc/SERVERa2012.domain.inet:1433 ] for the SQL 
                            Server service. 

2012-12-10 14:55:47.590 SQL Server is attempting to register a Service 
                            Principal Name (SPN) for the SQL Server service. 
                            Kerberos authentication will not be possible until a 
                            SPN is registered for the SQL Server service. This is an
                            informational message. No user action is required.
8
Max Vernon

Active Directoryを扱うのはいつもとても楽しいです。ここで最も重要なことは、ネットワーク全体に伝播するのに時間がかかる可能性のある分散データを扱っていることを認識することです。

問題のSQLサーバーは、アップグレード手順の一部として名前が変更されました。 SQL Server 2005を実行している既存のマシン(SQL01)を、SQL Server 2012を実行している新しいマシン(SQL03)に置き換えました。SQL03は、ドメインで最初にセットアップしたときの新しいマシンの名前でした。 SQL01には、2005を実行している複数のSQL Serverで使用した単一のドメインアカウントに関連付けられた既存のSPNがありました。特定のドメインアカウントで単一のマシンのみを実行することがベストプラクティスであるため、新しいアカウントを作成し、SQL03を実行するように構成しましたアカウント名。元のSQL01をサービスから外し、SQL03の名前をSQL01に変更すると、SPNの競合が発生しました。

SetSPN.exeユーティリティを使用して(古いドメインアカウントの)競合するSPNを削除しましたが、それでも機能しませんでした。この時点で、私はそれ以上何もせずに他の項目に移りました。私が30分ほど後に戻ってきたとき、KERBEROS認証が機能していました。 SPNの変更がドメインコントローラー間で伝達されるのを待つだけで済みました。

私はSetSPN -L DOMAIN\Accountを使用してその出力をSetSPN -Q MSSQLSvc/Machine.domain.inet:1433と比較し、重複するSPNを見つけてから、SetSPN -D MSSQLSvc/Machine.domain.inet:1433 DOMAIN\Accountを使用して古いSPNを削除しました。

8
Max Vernon

Kerberosエラーのトラブルシューティングに関するその他の資料は、次のリンクにあります。

2
Peter Vandivier