SQL Server 名前付きインスタンスに対してサービスプリンシパル名を設定する

SQLExpress などの名前付きインスタンスの場合、サービス名(MSSQLSvc)+FQDN では特定できない。ということで Registering a Service Principal Name を参照したところ、"MSSQLSvc/FQDN:port" という名称になる。

例えば ad01\SqlExpressMachine1 ユーザでMachine1上におけるSQLExpressサービスを稼働させている場合、手でSPNを登録するのであれば以下のようなコマンドとなる。

  • setspn -A MSSQLSvc/machine1.ad01.example.com ad01\SQLExpressMachine1

実験している当初、ユーザアカウントではなくコンピュータアカウントを最後の引数として渡したために、SQL Express にSSMSからWindows統合認証で接続しようとした際に "SSPI コンテキストを生成できません" というエラーメッセージが発生するようになってしまった。とはいえこれにより "SSPI コンテキストを生成できません" エラー メッセージのトラブルシューティング方法 (KB 811889) ドキュメントにたどりついて少し先に進んだ。

このドキュメントによると、手でSPNを登録するのではなく、サービスを稼働させるためのユーザアカウントに対して "servicePrincipalName の書き込み" 権限を付与することによりSPNが自動で登録されるようになる。この際ドキュメント中「[SELF] が一覧に表示されていない場合は、[追加] をクリックし、SELF を追加します。」とある部分について、すでに[SELF]が複数存在していたのだが、既存の項目に対する変更が反映されなかったため、新規で追加する必要があった。(Windows 2008)

servicePrincipalName に対する読み書き権限付与の作業の様子を動画にしたものを以下に置いた。

SPNが登録されることの確認は、SQLExpress サービス起動後 setspn -L ad01\SQLExpressMachine1 コマンドによって確認することができる。ちなみに LocalSystem アカウントでサービスを稼働させている場合は特に何もしなくても自動で登録されるので、"setspn -L マシン名" コマンドによりSPN登録状況を確認できる。

 

ということで一歩進んだと思われるのだが、証明書ディレクトリマッピング から委譲に至らない状況はまだ解決していない。ダブルホップ問題の解決というのは、Kerberos用語で言えば「forwardable チケットの発行」のはず、ということで以下のドキュメントを読んでいる途中。

状況調査にあたっては Windows Server 2003 Resource Kit Tools をインストールして、klist.exe や kerbtray.exe でチケットの様子を見たり、Microsoft Network Monitor 3.1 で通信状況を見たりしている。ドキュメントを読む限りでは Active Directory ユーザとコンピュータ で、IISを実行しているコンピュータアカウントに対し委譲の許可にチェック入れるだけのように思えるのだが。

(追記)上記リンクのうち Kerberos Protocol Transition and Constrained Delegation (TechNet)  が今まで見た中でもっとも詳細でわかりやすいドキュメントだった。ただし、プログラム中で Impersonate() を呼ぶ場合の話であり、証明書のディレクトリマッピング + Web.config 中で impersonate="true" と記述した際の挙動については確証の持てるドキュメントは最後まで得られなかった。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。