使用 Windows 驗證連線至 SQL Server 時，發生「無法產生 SSPI 內容」錯誤

發行項
11/20/2024

適用於：SQL Server
原始 KB 編號：811889

注意

開始進行疑難排解之前，建議您先檢查必要條件並逐一瀏覽檢查清單。

當您使用 Windows 驗證從遠端與 SQL Server 執行個體連線時，您會收到下列錯誤訊息：

目標主體名稱不正確。無法產生 SSPI 內容。

常見問題集

什麼是 SSPI？

安全性支援提供者介面 (SSPI) 是一組 Windows API，可讓您透過任何一般資料傳輸層進行委派和相互驗證，例如 TCP/IP 通訊端。一或多個軟體模組提供實際的驗證功能。每個模組都稱為安全性支援提供者 (SSP) ，並實作為動態連結程式庫 (DLL)。

什麼是 Kerberos？

Kerberos v5 通訊協定是業界標準的安全性套件，也是 Windows 作業系統中的三個安全性套件之一。如需詳細資訊，請參閱安全性支援提供者 (SSP) (部分機器翻譯)。

「無法產生 SSPI 內容」錯誤代表什麼意思？

此錯誤表示 SSPI 會嘗試但無法使用 Kerberos 驗證，以透過 TCP/IP 或具名管道將用戶端認證委派給 SQL Server。在大部分情況下，設定錯誤的服務主體名稱 (SPN) 會造成此錯誤。

什麼是 SPN？

服務主體名稱 (SPN) 是服務執行個體的唯一識別碼。 KERberos 驗證會使用 SPN 來建立服務執行個體與服務登入帳戶的關聯。此關聯程序可讓用戶端應用程式要求服務驗證帳戶，即使用戶端沒有帳戶名稱。

例如，對於執行 SQL Server 執行個體的伺服器，其一般的 SPN 如下所示：

MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

預設執行個體的 SPN 格式與具名執行個體的 SPN 相同。憑藉連接埠號碼，即可將 SPN 繫結至特定執行個體。如需登錄 SQL Server 服務 SPN 的詳細資訊，請參閱登錄 Kerberos 連線的服務主體名稱 (部分機器翻譯)。

為什麼 SSPI 使用 NTLM 或 Kerberos 驗證？

Windows 驗證是使用者向 SQL Server 驗證身分的慣用方法。使用 Windows 驗證的用戶端會使用 NTLM 或 Kerberos 進行驗證。

當 SQL Server 用戶端透過 TCP/IP 通訊端，對執行 SQL Server 的遠端伺服器使用整合式安全性時，SQL Server 用戶端網路程式庫會使用 SSPI API 來執行安全性委派。 SQL Server 網路用戶端會呼叫 AcquireCredentialsHandle 函式，並為 pszPackage 參數傳入 "negotiate"。此程序會通知基礎安全性提供者交涉委派。在此內容中，"negotiate" 表示在 Windows 電腦上嘗試進行 Kerberos 或 NTLM 驗證。換句話說，如果執行 SQL Server 的目的地電腦具有相關聯且已正確設定的 SPN，Windows 就會使用 Kerberos 委派。否則，Windows 會使用 NTLM 委派。如果 SQL Server 用戶端在 SQL Server 所在的同一部電腦上進行本機連線，則一律會使用 NTLM。

為什麼在使用 Kerberos 時遇到問題之後，連線不會容錯移轉至 NTLM？

用戶端上 SQL Server 驅動程式的程式碼會在驅動程式使用 Windows 驗證連線到 SQL Server 時，使用 WinSock 網路 API 來解析伺服器的完整 DNS。若要執行這項作業，驅動程式的程式碼會呼叫 gethostbyname 和 gethostbyaddr WinSock API。如果使用整合式安全性，即使將 IP 位址或主機名稱傳遞為伺服器名稱，驅動程式仍會嘗試解析伺服器的完整 DNS。

當用戶端上的 SQL Server 驅動程式解析伺服器的完整 DNS 時，會使用對應的 DNS 來形成伺服器的 SPN。因此，透過 WinSock 將 IP 位址或主機名稱解析為完整 DNS 的問題，可能會導致 SQL Server 驅動程式為伺服器建立無效的 SPN。

例如，用戶端 SQL Server 驅動程式可用來作為完整 DNS 來解析無效的 SPN，如下所示：

MSSQLSvc/SQLSERVER1:1433
MSSQLSvc/123.123.123.123:1433
MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

當 SQL Server 驅動程式形成無效的 SPN 時，驗證仍可運作，因為 SSPI 介面會嘗試在 Active Directory 服務中查閱 SPN。如果 SSPI 介面找不到 SPN，就不會執行 Kerberos 驗證。此時，SSPI 層會切換至 NTLM 驗證模式，登入也會使用 NTLM 驗證，而且通常可以成功。如果 SQL Server 驅動程式形成尚未指派給適當容器的有效 SPN，驅動程式會嘗試該 SPN，但無法加以使用。在此情況下，可能會發生「無法產生 SSPI 內容」錯誤。如果 SQL Server 啟動帳戶是本機系統帳戶，則適當的容器就是電腦名稱。針對任何其他帳戶，適當的容器為 SQL Server 啟動帳戶。驗證會使用其找到的第一個 SPN，因此請確定未將任何 SPN 指派給不正確的容器。換句話說，每個 SPN 只能指派給一個容器。

如何驗證連線的驗證方法？

若要判斷連線的驗證方法，請執行下列查詢：

SELECT net_transport, auth_scheme   
FROM sys.dm_exec_connections   
WHERE session_id = @@SPID;

如需詳細資訊，請參閱如何判斷驗證類型是否為 Kerberos。

如何建立適用于 SQL Server 的 SPN？

當 SQL Server Database Engine 的執行個體啟動時，SQL Server 會嘗試使用 DsWriteAccountSpn API 來自動註冊 SQL Server 服務的 SPN。如果 SQL Server 服務帳戶在 Active Directory 中具有讀取 servicePrincipalName 和寫入 servicePrincipalName 權限，則此呼叫會成功。否則，您需要 Active Directory 系統管理員使用適用于 SQL Server 的 Microsoft Kerberos 管理員或內建的 Setspn 工具，手動註冊正確的 SPN。如需管理 SQL Server SPN 的詳細資訊，請參閱註冊 Kerberos 連線的服務主體名稱。

修正 Kerberos Configuration Manager 的錯誤 (建議)

注意

此程式僅適用于您一直收到這些錯誤訊息而非間歇性收到的情況。

Kerberos 連線失敗的原因有很多種，例如設定錯誤的 SPN、名稱解析問題，或 SQL Server 服務啟動帳戶的權限不足。 Microsoft Kerberos Configuration Manager (KCM) 是有助於檢查錯誤原因的工具。 KCM 也提供修正程序中任何已識別問題的選項。

請遵循下列步驟，使用 KCM 修正錯誤。

在發生連線問題的電腦上，下載並安裝 Kerberos Configuration Manager。
從 %SystemDrive%：\Program Files\Microsoft\Kerberos Configuration Manager 資料夾啟動KerberosConfigMgr.exe。然後，使用有權限連線到您無法連線之 SQL Server 電腦的網域帳戶。
如果您在 SQL Server 電腦上執行 KCM，請選取 [連接]，將適用于您案例的伺服器名稱和其他詳細資料保留空白。選取 [連線] 以執行分析。 KCM 完成擷取必要資訊之後，會自動切換至 [SPN] 索引標籤，預設會顯示 SQL Server、SQL Server Reporting Services、Analysis Services 和 AG 接聽程式的資訊。若要對此錯誤進行疑難排解，請取消核取 SQL Server 以外的所有項目。

使用 [狀態] 資料欄檢閱工具的診斷，並遵循相關步驟來解決問題：

狀態	其他相關資訊	動作
良好	已正確設定已核取的項目。您可以繼續進行輸出中的下一個項目。	不需要任何動作。
遺失必要的 SPN	當 Active Directory 中 SQL Server 啟動帳戶遺失 [必要 SPN] 欄中所識別的 SPN 時，就會報告此狀態。	1.選取 [修正] 以檢閱 [警告] 對話方塊中的資訊。 2.選取 [是] 將遺漏的 SPN 新增至 Active Directory。 3.如果您的網域帳戶具有更新 Active Directory 的必要權限，則必要的 SPN 將會新增至 Active Directory。 4.如果您的網域帳戶沒有更新 Active Directory 的必要權限，請使用 [產生] 或 [全部產生] 來產生指令碼，以協助 Active Directory 系統管理員新增遺漏的 SPN。 5.新增 SPN 之後，再次執行 Kerberos Configuration Manager，以確認 SPN 問題已解決。 6.此外，您可以使用下列命令： - 使用 `SETSPN -Q spnName` 來尋找 SPN 及其目前帳戶。 - 使用 `SETSPN -D` 從不正確的帳戶中移除SPN。
必須啟用 TCP 才能使用 Kerberos 設定	當用戶端電腦上未啟用 TCP 時，就會發生這種情況。	若要啟用 SQL Server 執行個體的 TCP/IP 通訊協定，請遵循下列步驟： 1.在 [SQL Server 組態管理員] 的 [主控台]窗格中，展開 [SQL Server 網路設定]。 2.在控制檯窗格中，選取 [實例名稱>的<通訊協定]。 3.在 [詳細資料] 窗格中，以滑鼠右鍵按一下 [TCP/IP]，然後按一下 [啟用]。 4.在 [主控台] 窗格中，選取 [SQL Server 服務]。 5.在詳細數據窗格中，以滑鼠右鍵按兩下 [SQL Server][<實例名稱>]，然後選取 [重新啟動 ] 以停止並重新啟動 SQL Server 服務。如需詳細資訊，請參閱啟用或停用伺服器網路通訊協定。
動態連接埠	此訊息會針對使用動態連接埠 (預設組態) 的具名執行個體顯示。在需要使用 Kerberos 連線到 SQL Server 的環境中，您應該將具名執行個體設定為靜態連接埠，並在註冊 SPN 時使用該連接埠。	若要將 SQL Server 執行個體設定為使用靜態連接埠，請遵循下列步驟： 1.在 SQL Server 組態管理員中，展開控制檯窗格中的 [SQL Server 網络組態]，展開 [實例名稱>的<通訊協定]，然後按兩下 [TCP/IP]。 2.在 [TCP/IP 屬性] 對話框中，檢閱 [通訊協定] 索引卷標上的 [全部接聽] 設定。 3.如果 [全部接聽] 設定設為 [是]，請切換至 [IP 位址] 索引標籤，然後捲動到 Windows 底部以尋找 [IPAll] 設定。刪除 TCP 動態連接埠中包含的目前值，並在 [TCP 連接埠] 欄位中設定所需的值。選取 [確定]，然後重新啟動 SQL Server 執行個體，讓設定生效。 4.如果 [全部接聽] 設定設為 [否]，請切換至 [IP 位址] 索引標籤，並檢查 IP1、IP2 中出現的每個 IP 位址。針對已啟用的 IP 位址，移除 [TCP 動態連接埠] 欄位中包含的目前值，並在 [TCP 連接埠] 欄位中設定所需的值。選取 [確定]，然後重新啟動 SQL Server 執行個體，讓設定生效。如需詳細資訊，請參閱設定伺服器接聽特定 TCP 連接埠。
重複的 SPN	當相同的 SPN 在 Active Directory 中的不同帳戶下註冊時，您可能會遇到這種情況。	1.選取 [修正] 按鈕，檢視 [警告] 對話方塊中的資訊，如果您可以將遺漏的 SPN 新增至 Active Directory，請選取 [是]。 2.如果您的網域帳戶具有更新 Active Directory 的必要權限，則會刪除不正確的 SPN。 3.如果您的網域帳戶沒有更新 Active Directory 的必要權限，請使用 [產生] 或 [全部產生] 按鈕來產生必要的指令碼，您可以將該指令碼交給 Active Directory 系統管理員以移除重複的 SPN。移除 SPN 之後，請重新執行 KCM 以確認 SPN 問題已解決。

注意

如果啟動 KCM 的網域帳戶沒有在 Active Directory 中操作 SPN 的許可權，您可以使用 SPN 腳本數據行底下的對應 [產生] 或 [產生全部] 按鈕來產生必要的命令，並與您的 Active Directory 系統管理員合作，以修正 KCM 所識別的問題。

修正 KCM 中識別的所有問題之後，請重新執行工具。請確定未回報任何其他問題，然後重試連線。如果工具仍回報問題，請重複先前的程序。

修正沒有 Kerberos Configuration Manager 的錯誤

如果您無法使用 KCM，請遵循下列步驟：

步驟 1：使用 ping 命令檢查名稱解析

讓 Kerberos 驗證成功的關鍵因素是網路上有效的 DNS 功能。您可以使用 Ping 命令提示字元公用程式，在用戶端和伺服器上驗證這項功能。在用戶端電腦上，執行下列命令以取得執行中之伺服器的 IP 位址，SQL Server (其中的電腦名稱為 SQLServer1) ：

ping sqlserver1

若要查看 Ping 公用程式是否解析 SQLServer1 的完整 DNS，請執行下列命令：

ping -a <IPAddress>

例如：

C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128

Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms 
C:\>ping -a 123.123.123.123

Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

C:\>

當命令 ping -a <IPAddress> 解析為執行 SQL Server 之電腦的正確完整 DNS 時，用戶端解析也會成功。

如需詳細診斷，請使用 Test-NetConnection 或 Test-Connection Cmdlet，根據電腦上安裝的 PowerShell 版本來測試 TCP 連線能力。如需有關 PowerShell Cmdlet 的詳細資訊，請參閱 Cmdlet 概觀。

注意

名稱解析方法可能包括 DNS、WINS、Hosts 檔案和 Lmhosts 檔案。如需名稱解析問題和疑難排解的詳細資訊，請檢閱下列連結：

檢查目的地 SQL Server 的任何別名是否存在於 SQL Server Configuration Manager 和 SQL Server 用戶端網路公用程式中。如果這類別名存在，請檢查伺服器名稱、網路通訊協定、連接埠號碼等，確定其已正確設定。 SQL Server 別名可能會導致產生非預期的 SPN。如果找不到 SPN 或 SSPI 失敗，如果它不小心符合另一部伺服器的 SPN，這會導致 NTLM 認證。

步驟 2：驗證網域之間的通訊

確認您登入的網域可以與執行 SQL Server 的伺服器網域通訊。網域中也必須有正確的名稱解析。

請確定您可以使用與 SQL Server 服務啟動帳戶相同的網域帳戶和密碼來登入 Windows。例如，在下列其中一種情況下，可能會發生 SSPI 錯誤：
- 網域帳戶已鎖定。
- 在帳戶的密碼變更之後，您未重新啟動 SQL Server 服務。
如果您的登入網域與執行 SQL Server 的伺服器網域不同，請檢查網域之間的信任關係。
檢查伺服器所屬的網域，以及您用來連線的網域帳戶是否位於相同的樹系中。 SSPI 需要此步驟才能運作。

步驟 3：使用 SQLCHECK 和 Setspn 工具來驗證 SQL Server SPN

如果您可以在本機登入 SQL Server 計算機並具有系統管理員存取權，請使用 SQLCHECK。 SQLCheck 會以一個檔案提供進行疑難排解所需的大部分資訊。如需如何使用工具及其所收集資訊的詳細資訊，請參閱該工具的首頁。您也可以參閱建議的必要條件和檢查清單頁面。產生輸出檔案之後，請在輸出檔案的 [SQL Server 資訊] 區段下，檢閱 SQL Server 執行個體的 SPN 組態。

範例輸出：

Suggested SPN                                               Exists  Status              

----------------------------------------------------------  ------  ------------------- 

MSSQLSvc/testsqlsvr.corp.com:2000                           True    Okay                

MSSQLSvc/testsqlsvr.corp.com                                True    Okay                

MSSQLSvc/testsqlsvr:2000                                    False   SPN does not exist. 

MSSQLSvc/testsqlsvr                                         False   SPN does not exist.

使用上述輸出來判斷後續步驟 (請參閱下列範例)，並使用 Setspn 工具以採取必要的補救動作來修正 SPN 問題。

案例	建議的動作
SPN 不存在	為您的 SQL Server 服務帳戶新增必要的 SPN。
重複的 SPN	刪除在不正確帳戶下為 SQL 服務登錄的 SPN。
不正確帳戶下的 SPN	將在不正確的帳戶下為 SQL 服務登錄的 SPN 刪除，然後在正確的服務帳戶下登錄 SPN。
註冊不正確的SPN	刪除不正確的SPN並註冊正確的SPN。

注意

您可以檢閱 SQLCHECK 工具輸出檔的 SQL Server 資訊 區段，以尋找 SQL Server 實例的服務帳戶。
Setspn 是較新版 Windows 中的內建工具，可協助您讀取、新增、修改或刪除 Active Directory 中的 SPN。您可以使用此工具，確認已根據登錄 Kerberos 連線的服務主體名稱來設定 SQL Server SPN。如需詳細資訊，請參閱 Setspn 工具和如何使用的範例。
如需 SQL Server 自動登錄 SPN 以及需要手動登錄 SPN 案例的詳細資訊，請參閱登錄 Kerberos 連線的服務主體名稱。

步驟 4：檢查連結的伺服器上 SQL Server 啟動帳戶的帳戶權限

如果您使用 [模擬] 作為鏈接伺服器 [安全性] 頁面上的驗證選項，則必須使用 SQL Server 將連入認證傳遞至遠端 SQL Server。定義連結伺服器的 SQL Server 啟動帳戶，應該會在 Active Directory 中獲指派 [帳戶受信任可以委派] 權限。如需詳細資訊，請參閱讓電腦及使用者帳戶受信賴，以進行委派。

注意

只有當您針對連結伺服器查詢的相關問題進行疑難排解時，才需要此步驟。

另請參閱

針對 SQL Server 中的連線問題進行疑難排解
針對持續發生的驗證問題進行疑難排解 (英文)
SSPI 用戶端工具 (英文)
啟用 Kerberos 事件記錄 (部分機器翻譯)
如何在 Windows 中強制 Kerberos 使用 TCP，而不是 UDP (部分機器翻譯)

共用方式為