各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 ServerのNetBIOS名または完全修飾ドメイン名（FQDN）を使用できます。ただし、NetBIOS名とFQDNの両方のSPNを作成する必要があります。

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

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

MS自身のKerberos構成マネージャーでさえ、最後の2つのバージョンを（適切に難読化して）生成したいようです：

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

• 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サービスアカウントがそれらを作成できるようにする代わりに、手動で修正/作成します。サーバーの起動。）

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

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

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

問題に関する私のブログの投稿から持ち上げられ、フォーマットは次のようになります。

MSからの参照元はここにあります。

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

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

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

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

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

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

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

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

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

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

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

名前付きインスタンス：

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

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