對於每個 SQL 實例，我的 SPN 條目應該是什麼樣的？
我發現關於如何準確格式化 SPN（服務主體名稱）以獲得正確的 Kerberos 連接以及每個 SQL 實例需要多少個相互矛盾的資訊。
此 2017 MS 文件包含以下內容：
從 SQL Server 2008 開始，為了支持 TCP/IP、命名管道和共享記憶體上的 Kerberos 身份驗證，更改了 SPN 格式。命名實例和預設實例支持的 SPN 格式如下。
- 命名實例：
MSSQLSvc/FQDN:[port|instancename]- 預設實例：
MSSQLSvc/FQDN:port|MSSQLSvc/FQDN新的 SPN 格式不需要埠號。這意味著多埠伺服器或不使用埠號的協議可以使用 Kerberos 身份驗證。
我認為最後一段的意思是我只需要一個條目，以下之一：
- 命名實例：
MSSQLSvc/sqlbox1.mydomain.org/instance2- 預設實例：
MSSQLSvc/sqlbox1.mydomain.org這似乎與這個較舊的 (2011) MS 文件相矛盾，不僅與埠號有關，還與使用什麼名稱有關：
要創建 SPN，您可以使用 SQL Server 的 NetBIOS 名稱或完全限定域名 (FQDN)。但是，您必須為 NetBIOS 名稱和 FQDN 創建一個 SPN。
當我查看環境中已經存在的 SPN 時，我看到了各種各樣的組合，有些伺服器最多有 4 個條目：
MSSQLSvc/sqlbox1MSSQLSvc/sqlbox1:1433MSSQLSvc/sqlbox1.mydomain.orgMSSQLSvc/sqlbox1.mydomain.org:1433甚至MS 自己的 Kerberos 配置管理器似乎也想生成最後兩個版本（帶有適當的混淆）：
同樣，對於現有的命名實例，我看到了一個奇怪的組合，其中一些幾乎可以肯定是無效的：
MSSQLSvc/sqlbox1:1522MSSQLSvc/sqlbox1:instance2MSSQLSvc/sqlbox1.mydomain.org:1522MSSQLSvc/sqlbox1.mydomain.org:instance2MSSQLSvc/sqlbox1.mydomain.org/instance2MSSQLSvc/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 名稱，我會推薦 FQDN，因為如果您遇到隨機 DNS 伺服器問題，它們不會那麼容易出現問題。
從我關於此事的部落格文章中提取，格式應如下所示：
可以在此處找到 MS 的源參考。
現在讓您的網路管理員日（例如，允許自註冊 SPN 的 OU 配置）
您的網路管理員可以在包含所有 SQL Server 服務帳戶的域上創建一個 OU，這些服務帳戶可以配置為服務帳戶可以為自己和自己單獨創建 SPN。該方法主要遵循Ryan Reis 的部落格，但有一些細微的調整，因此不會執行過度授權。
此過程描述了在域中創建 OU，以允許其中的帳戶自行註冊自己的 SPN：
- 作為在域上具有提升權限的帳戶，打開ADSI Edit（命令提示符下的 adsiedit）
- 右鍵點擊 ADSI 編輯 ->連接到…
- 連接到預設命名上下文
- 導航到/創建包含您希望授予 SPN 權限的服務帳戶的 OU 容器
- 右鍵點擊OU ->屬性
- 點擊安全選項卡
- 點擊高級按鈕
- 突出顯示SELF並點擊*Edit…或者如果SELF特殊使用者未顯示在組或使用者名列表中，請點擊Add…*並輸入SELF作為對象名稱
- 點擊屬性選項卡
- 從應用到旁邊的下拉列表中選擇後代使用者對象： 注意：這是對 Ryan 部落格文章中概述的步驟的輕微調整，原因可以在此ServerFault/StackExchange文章中更好地概述。
- 選中以下旁邊
的允許框：
- 讀取 servicePrincipalName
- 寫 servicePrincipalName
- 點擊確定（在權限輸入視窗上）
- 點擊確定（在高級安全設置視窗中）
- 點擊確定（在 OU 屬性視窗上）
- 將執行 SQL Server 服務的服務帳戶添加到 OU
- （可選）重新啟動在所述帳戶下執行的SQL Server 服務
- 享受美食
完成上述步驟後，相關的 OU 容器現在已配置，以便添加到其中的任何帳戶都能夠為自己和自己單獨註冊和刪除 SPN。這正是正確數量的權限，因為這些帳戶將無法踐踏其他帳戶註冊的 SPN。
在步驟 16 中重新啟動 SQL Server 的目的是確保按預期註冊 SPN。SQL 將嘗試在關閉時刪除任何已註冊的 SPN，並在啟動時添加它們，因此只有在目前不存在用於所述 SQL Server 服務的 SPN 時才真正需要重新啟動。
關於此方法的最後一點說明是，如果您在傳統的故障轉移群集實例 (FCI) 配置中執行 SQL Server，則不建議將此實例的服務帳戶添加到此 OU，根據KB 2443457。
我真的需要發布我的 Kerberos 系列的第 2 部分……
