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.

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の変更がドメインコントローラー間で伝達されるのを待つだけで済みました。

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

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

• Kerberosエラーのトラブルシューティング（ホワイトペーパー）^{代替リンク、ウェイバックマシン}
• Windows認証エラーのデバッグ