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

適用于:  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」。 此程式會通知基礎安全性提供者交涉委派。 在此內容中,「交涉」表示在以 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。 若要執行這項作業,驅動程式程式碼會呼叫 gethostbynamegethostbyaddr 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

如何建立適用于 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 連線失敗的原因有很多種,例如設定錯誤的 SPN、名稱解析問題,或SQL Server服務啟動帳戶的許可權不足。 Microsoft Kerberos Configuration Manager (KCM) 是有助於檢查錯誤原因的工具。 KCM 也提供修正程式中任何已識別問題的選項。

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

  1. 在發生連線問題的電腦上,下載並安裝Kerberos Configuration Manager

  2. % SystemDrive:\Program Files\Microsoft\Kerberos Configuration Manager 資料夾開始KerberosConfigMgr.exe。 然後,使用有權連線到您無法連線之SQL Server電腦的網域帳戶。

  3. 如果您在SQL Server電腦上執行 KCM,請選取 [ 機],將適用于您案例的伺服器名稱和其他詳細資料保留空白。 選 取 [連線 ] 以執行分析。 KCM 完成擷取必要資訊之後,會自動切換至 [SPN] 索 引標籤,預設會顯示SQL Server、SQL Server Reporting Services、Analysis Services 和 AG 接聽程式的資訊。 若要對此錯誤進行疑難排解,請取消核取SQL Server以外的所有專案。

  4. 使用 [ 狀態 ] 資料行檢閱工具的診斷,並遵循相關步驟來解決問題:

    狀態 其他資訊 動作
    良好 已正確設定已核取的專案。 您可以繼續進行輸出中的下一個專案。 不需要採取任何動作
    遺失必要的 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 問題已解決。
    必須啟用 TCP 才能使用 Kerberos 設定 當用戶端電腦上未啟用 TCP 時,就會發生這種情況。 若要啟用SQL Server實例的 TCP/IP 通訊協定,請遵循下列步驟:
    1.在 [SQL Server 組態管理員] 的 主控台 窗格中,展開 [SQL Server網路組態]
    2.在 主控台 窗格中,選取 的 [通訊 協定 ] <instance name> 。
    3.在 詳細資料 窗格中,以滑鼠右鍵按一下 [TCP/IP],然後選取 [ 啟用]
    4.在 主控台 窗格中,選 取 [SQL Server 服務]
    5.在 詳細資料 窗格中,以滑鼠右鍵按一下SQL Server (<instance name>) ,然後選取 [重新開機] 以停止並重新啟動SQL Server服務。
    如需詳細資訊,請 參閱啟用或停用伺服器網路通訊協定
    動態埠 此訊息會針對使用動態埠 (預設組態) 的具名實例顯示。 在需要使用 Kerberos 連線到SQL Server的環境中,您應該將具名實例設定為靜態埠,並在註冊 SPN 時使用該埠。 若要將SQL Server實例設定為使用靜態埠,請遵循下列步驟:
    1.在 [SQL Server 組態管理員 ] 的主控台 窗格中,依序展開 [SQL Server網路 設定] 和 [通訊協定 <instance name> ],然後按兩下 [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 所識別的問題。

  5. 修正 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-NetConnectionTest-Connection Cmdlet,根據電腦上安裝的 PowerShell 版本來測試 TCP 連線能力。 如需 PowerShell Cmdlet 的詳細資訊,請參閱 Cmdlet 概觀

注意

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

檢查目的地SQL Server的任何別名是否存在於SQL Server 組態管理員和SQL Server用戶端網路公用程式中。 如果這類別名存在,請檢查伺服器名稱、網路通訊協定、埠號碼等,確定其已正確設定。

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

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

  1. 請確定您可以使用與SQL Server服務啟動帳戶相同的網域帳戶和密碼來登入 Windows。 例如,SSPI 錯誤可能會在下列其中一種情況下發生:

    • 網域帳戶已鎖定。
    • 在帳戶的密碼變更之後,您未重新開機SQL Server服務。
  2. 如果您的登入網域與執行SQL Server的伺服器網域不同,請檢查網域之間的信任關係。

  3. 檢查伺服器所屬的網域,以及您用來連線的網域帳戶是否位於相同的樹系中。 SSPI 需要此步驟才能運作。

步驟 3:使用 SQLCheck 和 Setspn 工具驗證SQL Server SPN

如果您可以在本機登入SQL Server電腦並具有系統管理員存取權,請從Microsoft SQL 網路 GitHub 存放庫使用 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。

注意

  • 您可以檢閱 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 中將委 派許可權 指派給帳戶。 如需詳細資訊,請參閱 啟用要信任委派的電腦和使用者帳戶

注意

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

另請參閱