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の変更がドメインコントローラー間で伝達されるのを待つだけで済みました。
私はSetSPN -L DOMAIN\Account
を使用してその出力をSetSPN -Q MSSQLSvc/Machine.domain.inet:1433
と比較し、重複するSPNを見つけてから、SetSPN -D MSSQLSvc/Machine.domain.inet:1433 DOMAIN\Account
を使用して古いSPNを削除しました。
Kerberosエラーのトラブルシューティングに関するその他の資料は、次のリンクにあります。