web-dev-qa-db-ja.com

各SQLインスタンスのSPNエントリはどのように見えるべきですか？

適切なKerberos接続を取得するためにSPN（サービスプリンシパル名）を正確にフォーマットする方法と、SQLインスタンスごとに必要な数について、矛盾する情報を見つけています。

この2017年のMSドキュメント には以下が含まれます。

SQL Server 2008以降、TCP/IP、名前付きパイプ、および共有メモリでのKerberos認証をサポートするために、SPN形式が変更されました。名前付きインスタンスとデフォルトインスタンスでサポートされるSPN形式は次のとおりです。

  • 名前付きインスタンス：MSSQLSvc/FQDN:[port|instancename]
  • デフォルトのインスタンス：MSSQLSvc/FQDN:port|MSSQLSvc/FQDN

新しいSPN形式では、ポート番号は必要ありません。つまり、マルチポートサーバーまたはポート番号を使用しないプロトコルは、Kerberos認証を使用できます。

この最後の段落は、次のいずれか1つのエントリのみが必要であることを意味します。

  • 名前付きインスタンス：MSSQLSvc/sqlbox1.mydomain.org/instance2
  • デフォルトのインスタンス：MSSQLSvc/sqlbox1.mydomain.org

これは矛盾しているようです この古い（2011）MSドキュメント 、ポート番号だけでなく、使用する名前についても：

SPNを作成するには、SQLサーバーのNetBIOS名または完全修飾ドメイン名（FQDN）を使用できます。ただし、NetBIOS名とFQDNの両方のSPNを作成する必要があります。

私の環境にすでに存在するSPNを見ると、さまざまな組み合わせがあり、一部のサーバーには最大4つのエントリがあります。

  • MSSQLSvc/sqlbox1
  • MSSQLSvc/sqlbox1:1433
  • MSSQLSvc/sqlbox1.mydomain.org
  • MSSQLSvc/sqlbox1.mydomain.org:1433

でも MS独自のKerberos構成マネージャー は、最後の2つのバージョンを（適切な難読化を使用して）生成したいようです。

enter image description here

同様に、既存の名前付きインスタンスの場合、奇妙な組み合わせが見られます。それらの一部はほぼ確実に無効です。

  • MSSQLSvc/sqlbox1:1522
  • MSSQLSvc/sqlbox1:instance2
  • MSSQLSvc/sqlbox1.mydomain.org:1522
  • MSSQLSvc/sqlbox1.mydomain.org:instance2
  • MSSQLSvc/sqlbox1.mydomain.org/instance2
  • MSSQLSvc/sqlbox1.mydomain.org:1522:instance2

だから、もし私の環境でTCPを使用するだけなら、デフォルトと名前付きインスタンスの両方で、私のDSNは実際にはどのように見えるでしょうか？

ポートを含めるかどうかを指定しますか？または、ポートのあるものとないものを含めますか？

FQDNのみを使用しますか、それともNetbios名のみのエントリが必要ですか？それとも、名前付きパイプを使用している場合のみ（そうではありません）？

（コンテキストでは、SQL 2005から2014を実行し、一部はクラスター化され、その他はスタンドアロンです。接続はTCPのみであり、名前付きパイプは構成マネージャーで無効になっています。これらを手動で修正/作成するのではなく、 SQLサービスアカウントがサーバーの起動時にそれらを作成できるようにします。）

sql-serverkerberosspn
8
BradC

インスタンスへの接続にTCP/IPのみを使用している場合は、-need指定されたポートのみを使用します。インスタンス名は、名前付きパイププロトコルを介してSQLインスタンスに接続するときに使用されます。悲しいことに、MSの記事では、どのプロトコルにどのフォーマットが必要であるかを明記していませんが、（私の環境での多くのテスト）と次の MS記事のセンテンス から派生しています。

名前付きパイプと共有メモリ接続の場合、名前付きインスタンスにはMSSQLSvc/FQDN：instancenameという形式のSPNが使用され、MSSQLSvc/FQDNはデフォルトのインスタンスに使用されます。

FQDNとNETBIOS名については、ランダムなDNSサーバーの問題に直面した場合に問題が発生しにくいため、FQDNをお勧めします。

私の ブログ投稿 から引き上げると、問題については、フォーマットは次のようになります。

 enter image description here 

MSからのソースリファレンスは、 here にあります。

ネットワーク管理者の日を作成します（例：自己登録SPNを許可するOU構成）

ネットワーク管理者は、ドメインにOUを作成できます。このOUには、サービスアカウントが自分自身と自分自身のSPNを作成できるように構成できる、すべてのSQL Serverサービスアカウントが含まれます。この方法は、主に Ryan Reisのブログ に従っていますが、過剰な発言が行われないように若干の調整が行われています。

このプロセスでは、ドメイン内のアカウントが自分のSPNを自己登録できるようにするドメイン上のOUの作成について説明します。

  1. ドメインで上位の権限を持つアカウントとして、 ADSI Edit を開きます（コマンドプロンプトからのadsiedit）
  2. ADSI Editを右クリック-> Connect to ...
  3. 接続デフォルトの名前付けコンテキスト
  4. OUコンテナーに移動/作成 SPN権限を付与するサービスアカウントを保持
  5. 右クリック OUで-> プロパティ
  6. Securityタブをクリックします
  7. Advancedボタンをクリックします
  8. [〜＃〜] self [〜＃〜]を強調表示してEdit ...をクリックするか、または[〜＃〜] self [〜＃〜]特別なユーザーがグループ名またはユーザー名のリストに表示されない場合は、追加...をクリックして[〜＃〜 ] self [〜＃〜]オブジェクト名
  9. プロパティタブをクリックします
  10. [適用先]の横にあるドロップダウンリストから子孫ユーザーオブジェクトを選択します。注：これは、 ServerFault/StackExchange で概説されている理由により、Ryanのブログ投稿で概説されている手順を少し調整したものです。役職。
  11. 次の横にあるAllowボックスをオンにします：
    • servicePrincipalNameを読み取る
    • servicePrincipalNameを書き込む
  12. OKをクリックします（権限入力ウィンドウ）
  13. OKをクリックします（[高度なセキュリティ設定]ウィンドウ）
  14. Okをクリックします（OUプロパティウィンドウ）
  15. SQL Serverサービスを実行しているサービスアカウントをOUに追加する
  16. （オプション）再起動SQL Server Services上記のアカウントで実行
  17. お楽しみください

上記の手順を実行した後、問題のOUコンテナーは、コンテナーに追加されたアカウントがそれ自体およびそれ自体のSPNを登録および削除できるように構成されます。これらのアカウントは他のアカウントによって登録されたSPNを踏みにじることができないため、これはまさに適切な権限の量です。

手順16でSQL Serverを再起動する目的は、SPNが期待どおりに登録されていることを確認することです。 SQLは、シャットダウン時に登録済みのSPNを削除し、スタートアップ時に追加しようとします。そのため、再起動が必要になるのは、そのSQL Serverサービスに現在SPNが存在しない場合だけです。

このアプローチに関する最後のメモは、SQL Serverを従来のフェールオーバークラスターインスタンス（FCI）構成で実行している場合、このインスタンスのサービスアカウントをこのOUに追加することはお勧めできません（ KB 2443457 を参照）。

私は本当にKerberosシリーズのパート2を投稿する必要があります...

5
John Eisbrener

SQL ServerサービスがSPNを作成すると、インスタンスごとに2つ作成されます。これが使用する形式です。

デフォルトのインスタンス：

MSSQLSvc/servername.domain.com
MSSQLSvc/servername.domain.com:1433

名前付きインスタンス：

MSSQLSvc/servername.domain.com:54321
MSSQLSvc/servername.domain.com:instancename

名前付きインスタンスの場合、SPNを手動で作成する場合は、デフォルトの動的ポートではなく静的ポートが必要です。

1
Bob Klimes