SQL Server で Windows 認証を利用する場合、認証に利用される protocol は Kerberos と NTLM から選択されます。いわゆる Negotiate というやつです。
既定の設定では Kerberos が利用可能な状態なら Kerberos が優先され、Kerberos が利用できない場合に NTLM が利用されます。
現在の接続がどちらの protocol を利用しているか調査するには下記 query を実行します。
SELECT [auth_scheme]
FROM [master].[sys].[dm_exec_connections]
WHERE [session_id] = @@SPID
[auth_scheme] は 'public' server role の member では選択できませんので上記は 'sysadmin' server role の member で実施してください。
意外に NTLM になっていること多いんじゃないでしょうか？
Kerberos が利用できない原因はいろいろ存在しますが、もっとも多いのが SPN (Service Principal Name) が登録されていないという状況です。
Remote から Kerberos を利用して接続を行うためには SPN の登録が必要です。SQL Server では service の起動時に SPN を登録しに行きます。Service account に Network Service account を利用している場合には、この自動登録で SPN が登録されます。しかし、domain account を利用している場合には失敗します。
というのは domain account の場合その domain account 自身の Service-Principal-Name attribute への書き込みが既定で許可されていないからです。
これを解消するためには SQL Server の service acount に指定した domain account の ACL で "Self" に対し "servicePrincipalName" への書き込みを許可します。Windows Server 2008 以降では「Active Directory ユーザーとコンピューター」からでも ACL の設定が可能ですが、"servicePrincipalName" は設定できません。そのため、作業は "ADSI エディター" から行ってください。
- 「ファイル名を指定して実行」から "adsiedit.msc"
- 「ADSI エディター」で SQL Server の service account を探し出し、[プロパティ]
- [セキュリティ] tab で <詳細設定>
- "SELF" (複数存在していてもどちらか一つで OK) を選択し、<編集>
- [適用先] に「このオブジェクトのみ」で「servicePrincipalName の書き込み」を付与
上記設定が完了したら、SQL Server を再起動します。その後、下記 command を実行して SPN を確認します。
>setspn.exe -l Domain\Account
Domain, Account には SQL Server の service acount を入力してください。結果に下記が含まれれば OK です。
MSSQLSvc/DbServerName.FQDN:1433
MSSQLSvc/DbServerName
ここまで書きましたが、account の ACL を変更せずに setspn.exe を使って SPN を直接登録してしまってももちろん構いません。
これが完了したら、もう一度 query を投げて protocol を確認してみましょう。Kerberos になっていない場合には、firewall 等他の原因です。
なお、ここまでは SQL Server が Kerberos 認証を受け入れるための準備作業であり、Kerberos 委任を利用した multi-hop 許可の設定については説明していません。続きは次回。