如何疑難排解「無法產生 SSPI 內容」錯誤訊息


注意 Kerberos Configuration Manager 是可協助疑難排解與 Kerberos 有關之 SQL Server 連線問題的診斷工具。 這些問題可能會觸發錯誤,比如「Cannot generate SSPI context」。 此工具現在已可使用並可從下列位置下載:

http://www.microsoft.com/downloads/zh-tw/details.aspx

如需詳細資訊,請參閱下列「Microsoft 知識庫」文章:

新工具: 「用於 SQL Server 的 Microsoft Kerberos Configuration Manager」 已可解決您的 Kerberos/連線問題

用於 SQL Server 的 Kerberos Configuration Manager 可用

 

本節提供關於「Cannot generate SSPI context」錯誤訊息的背景資訊,以及如何疑難排解錯誤。 下列情況成立時,您可能就會收到此錯誤訊息:

  • 您正在連線到 Microsoft SQL Server。

  • 您正在使用整合式安全性。

  • Kerberos 認證用於執行安全委派。

瞭解 Kerberos 術語和服務主體名稱 用戶端電腦上的 SQL Server 驅動程式利用整合式安全性來使用使用者帳戶的 Windows 安全性權杖,以成功連線至執行 SQL Server 的電腦。 用戶端將 Windows 安全性權杖委派給正在執行 SQL Server 的電腦。 當使用者的安全性權杖使用下列其中一項設定委派給其他電腦時,SQL Server 驅動程式將執行此委派:

  • NTLM 透過具名管道 (不使用安全性支援提供者介面 [SSPI])

  • NTLM 透過使用 SSPI 的 TCP/IP 通訊端

  • 使用 SSPI 在 TCP/IP 通訊端進行 Kerberos 驗證

安全性支援提供者介面(SSPI)是 Windows API 的集合,允許透過一般的資料傳輸層進行委派和相互驗證,例如 TCP/IP 通訊端。 因此,SSPI 允許執行 Windows 作業系統的電腦安全地將使用者的安全性權杖委派給其他電腦,方法是透過任何能夠傳輸資料原始位元組的傳輸層進行。

當 SSPI 使用 Kerberos 驗證透過 TCP/IP 進行委派,但無法完成必要的作業以便將使用者的安全性權杖成功地委派給執行 SQL Server 的目標端電腦時會發生「Cannot generate SSPI context」錯誤。

為何安全性支援提供者介面使用 NTLM 或 Kerberos 驗證 Kerberos 驗證使用名為「服務主體名稱」的識別碼(SPN)。 考慮將 SPN 視為伺服器資源中的一些執行個體的網域或樹系唯一識別碼。 您可以擁有 Web 服務、SQL 服務或 SMTP 服務的 SPN。 也可以在只有唯一 SPN 的同台實體電腦上擁有多個 Web 服務執行個體。

SQL Server 的 SPN 是由下列項目所組成:

  • ServiceClass: 此項目會識別服務的一般類別。 此項目必定是 SQL Server 的 MSSQLSvc。

  • 主機: 這是正在執行 SQL Server 電腦的完整格式 DNS 網域名稱。

  • 連接埠: 這是服務正在接聽的連接埠號碼。

例如:執行 SQL Server 電腦的典型 SPN 是:


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

預設執行個體的 SPN 格式和具名執行個體的 SPN 格式是相同的。 連接埠號碼負責將 SPN 繫結至特定的執行個體。

當用戶端的 SQL Server 驅動程式使用整合式安全性連線至 SQL Server,用戶端驅動程式的程式碼會嘗試解析執行 SQL Server 電腦的完整格式 DNS 網域名稱,方法是使用 WinSock 網路 API。 為了執行這項作業,驅動程式的程式碼會呼叫 gethostbyname 及 gethostbyaddr WinSock API。 即使 IP 位址或主機名稱通過執行 SQL Server 的電腦驗證,如果該電腦使用整合式安全性,SQL Server 驅動程式仍然會嘗試解析連線電腦的 DNS 完整格式。

用戶端的 SQL Server 驅動程式解析完執行 SQL Server 電腦的完整格式 DNS 網域名稱之後,相符的 DNS 會用於替這部電腦建立 SPN。 因此,所有透過 WinSock 將 IP 位址或主機名稱解析為完整 DNS 的問題,皆可能會導致 SQL Server 驅動程式在執行 SQL Server 的電腦上建立無效的 SPN。

例如:用戶端 SQL Server 驅動程式建立的無效 SPN 可解析為完全合格的 DNS,如下:

  • 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,並且將找不到 SPN。 如果 SSPI 介面找不到 SPN,Kerberos 驗證便不會執行。 此時,SSPI 層會切換為 NTLM 驗證模式,並使用 NTLM 驗證登入,通常可成功登入。 若 SQL Server 驅動程式形成有效的 SPN,但未將其指派給適當的容器,則會嘗試使用 SPN 並導致失敗。 這將造成「Cannot generate SSPI context」錯誤訊息。 如果 SQL Server 啟動帳戶是本機系統的帳戶,則適當的容器為電腦名稱。 對於其他任何的帳戶,適當容器為 SQL Server 啟動帳戶。 因為驗證將嘗試使用最先找到的 SPN,請確定 SPN 皆已指派給適當的容器。 換句話說,每個 SPN 必須分別指派給一個容器。

讓 Kerberos 驗證成功的關鍵因素是網路上 DNS 功能有效。 可以在用戶端和伺服器上使用 Ping 命令提示公用程式來驗證這項功能。 在用戶端電腦中執行下列命令以取得執行 SQL Server 伺服器的 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 時,用戶端的解析也將成功。

建立 SQL Server 服務主體名稱 這是 Kerberos 驗證和 SQL Server 互動的其中一個重要部分。 使用 SQL Server 時,可以在以下環境之一中執行 SQL Server 服務,即:LocalSystem 帳戶、本機使用者帳戶或網域使用者帳戶。 啟動 SQL Server 服務執行個體後,嘗試呼叫 DsWriteAccountSpn API,在 Active Directory 中註冊自己的 SPN。 如果呼叫不成功,事件檢視器會記錄下列警告: 如需 DsWriteAccountSpn 功能的詳細資訊,請移至下列 Microsoft 網站:

http://msdn2.microsoft.com/library/ms676056.aspx

簡化說明 若在 LocalSystem 帳戶這執行 SQL Server 服務,SPN 將自動登錄,Kerberos 驗證也會與執行 SQL Server 的電腦順利互動。 然而,如果您使用網域帳戶或本機帳戶執行 SQL Server 服務,在大多數情況下嘗試建立 SPN 將會失敗,因為網域帳戶或本機帳戶沒有權限設定各自的 SPN。 若 SPN 建立失敗,這表示執行 SQL Server 的電腦上未設定 SPN。 若嘗試使用網域系統管理員帳戶作為 SQL Server 服務帳戶進行測試,SPN 將成功建立,因為建立 SPN 時所需的網域系統管理員階層的憑證存在。

您可能未使用網域系統管理員帳戶執行 SQL Server 服務 (為了避免安全性風險),執行 SQL Server 的電腦可能無法建立其 SPN。 因此,若連線至執行 SQL Server 的電腦時要使用 Kerberos 驗證,則必須手動為執行 SQL Server 的電腦建立 SPN。 如果您使用網域使用者帳戶或本機使用者帳戶執行 SQL Server,就必須按此方式操作。 您建立的 SPN 必須指派給特定電腦上執行 SQL Server 服務所用的服務帳戶。 將執行 SQL Server 的電腦使用本機系統啟動前無法將 SPN 指派給電腦容器。 SPN 必須存在且必須是唯一的,系統還必須將其指派給適當的容器。 這通常是目前的 SQL Server 服務帳戶,但這是具有本機系統帳戶的電腦帳戶容器。
 

 

本節為您演示確保電腦不會遇到任何 SSPI 問題的步驟。

驗證網域 檢查您登入的網域是否能與執行 SQL Server 所屬的電腦網域通訊。 網域中也必須有適當的名稱解析。

  1. 您必須確定供 SQL Server 服務啟動帳戶所用的網域帳戶和密碼能成功登入 Windows。 例如,有下列其中一種情況時可能發生 SSPI 錯誤:

    • 網域帳戶遭到鎖定。

    • 帳戶的密碼已變更。 不過,密碼變更後您從未重新啟動 SQL Server 服務。

  2. 若您的登入網域和執行 SQL Server 電腦的網域不同,請檢查網域間的信任關係。

  3. 請檢查伺服器所屬的網域和您用來連線的網域是否位於同樣的樹系中。 SSPI 在此前提下才能運作。

  4. 啟動 SQL Server 時,請在「Active Directory 使用者及電腦」中使用 「帳戶受信任可以委派」 選項。


    注意:只有在目標 SQL 伺服器的憑證委派給遠端 SQL 伺服器時才需使用「帳戶受信任可以委派」權限,例如在雙躍點情況中使用 Windows 驗證的分散式查詢(連結的伺服器查詢)。

  5. 使用 Windows 2000 資源套件中的管理帳戶服務主要名稱 (SetSPN.exe)」公用程式。 Windows 2000 網域系統管理員帳戶或 Windows 2003 網域系統管理員帳戶可使用該公用程式,控制指派給服務及帳戶的 SPN。 SQL Server 必須有一個 SPN 並且只有一個 SPN。 SPN 必須指派給適當的容器,大多數的情況是使用現有的 SQL Server 服務帳戶,若 SQL Server 是以本機系統帳戶啟動,則指派給電腦帳戶。 如果您啟動時使用 LocalSystem 帳戶登入 SQL Server,則 SPN 會自動設定。 但若使用網域帳戶啟動 SQL Server,或者變更啟動 SQL Server 的帳戶,則必須執行 SetSPN.exe 來移除逾時的 SPN,並新增有效的 SPN。 如需詳細資訊,請參閱《SQL Server 2000 線上叢書》的「安全性帳戶委派」 主題。 要執行這項操作,請造訪下列 Microsoft 網站:

    http://msdn2.microsoft.com/library/aa905162(SQL.80).aspx 如需有關 Windows 2000 Resource Kits 的詳細資訊,請前往下列 Microsoft 網站:

    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true

  6. 請確認名稱解析正確地執行。 名稱解析方法可能包括 DNS、WINS、主機檔案和 Lmhosts 檔案。 如需有關名稱解析的問題與疑難排解的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:

    169790 如何疑難排解基本的 TCP/IP 問題
     

  7. 如需有關如何疑難排解 Active Directory 的協助工具及防火牆的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:

    291382 Windows 2000 DNS 和 Windows Server 2003 DNS 的常見問題
     

    224196 將 Active Directory 複寫流量與客戶端 RPC 流量限制至特定連接埠

將 SQL Server 服務設定為動態建立用於 SQL Server 執行個體的 SPN 要設定 SQL Server 服務來動態建立 SPN,則必須變更 Active Directory 目錄服務中的帳戶存取控制設定。 您必須授予 SQL Server 服務帳戶「讀取 servicePrincipalName」權限和「寫入 servicePrincipalName」的權限。

警告:若使用「Active Directory 服務介面 (ADSI) 」編輯器嵌入式管理單元、LDP 公用程式或任何其他 LDAP 第 3 版用戶端,並且錯誤地修改 Active Directory 物件的屬性,將會導致嚴重的問題。 這些問題可能導致您必須重新安裝 Microsoft Windows Server 2003、Microsoft Windows 2000 Server、Microsoft Exchange Server 2003、Microsoft Exchange 2000 Server,或者 Windows 和 Exchange 兩項皆須重新安裝。 我們無法保證能夠解決錯誤地修改 Active Directory 物件屬性所造成的問題。 請自行承擔修改這些屬性的風險。

注意:要授予 SQL Server 啟動帳戶適當的權限和使用者權力,您必須以網域系統管理員身份登入,或請求網域系統管理員執行此動作。

若要設定 SQL Server 服務,以動態方式建立 SPN,請依照下列步驟執行:

  1. 按一下「開始」,再按一下「執行」,輸入 Adsiedit.msc,然後按一下「確定」

  2. 在 ADSI 編輯器嵌入式管理單元中,展開 Domain [DomainName]、展開 [DC= RootDomainName]、展開 [CN=Users]、用滑鼠右鍵按一下 [CN= AccountName],再按一下「屬性」

    注意事項

    • DomainName 是網域名稱的預留位置。

    • RootDomainName 是根網域名稱的預留位置。

    • AccountName 是您指定啟動 SQL Server 服務帳戶的預留位置。

    • 若您指定本機系統帳戶來啟動 SQL Server 服務,AccountName 是用於登入 Microsoft Windows 帳戶的預留位置。

    • 若您指定網域使用者帳戶來啟動 SQL Server 服務,AccountName 是網域使用者帳戶的預留位置。

  3. 「CN= AccountName 屬性」對話方塊中按一下 「安全性」索引標籤。

  4. 「安全性」索引標籤上按一下「進階」

  5. 「進階安全性設定」對話方塊中,請確定「SELF」是列在「權限項目」下。

    若未列出「SELF」,請按一下「新增」,然後再新增「SELF」

  6. 「權限項目」 按一下「SELF」,然後按一下「編輯」

  7. 「權限項目」對話方塊中按一下「屬性」索引標籤。

  8. 「屬性」索引標籤中按一下的「套用在」清單中的「僅此物件」,確定已選取下列位於「權限」 下的核取方塊權限:

    • 讀取 servicePrincipalName

    • 寫入 servicePrincipalName

  9. 按三次「確定」,然後離開 ADSI 編輯器嵌入式管理單元。

如需處理程序的說明,請連絡 Active Directory 產品支援服務,並提及此「Microsoft 知識庫」文件。


重要:建議您在下列情況成立時,不要為 SQL 服務帳戶授予 WriteServicePrincipalName 權限 :

  • 有多個網域控制站。

  • SQL Server 為叢集。

在此情況下,可能會因為 Active Directory 複寫延遲而刪除 SQL Server 的 SPN。 這可能會導致 SQL Server 執行個體發生連線問題。

假設您有下列項目:

  • 帶兩個節點的名為 Sqlcluster 的 SQL 虛擬執行個體: 節點 A 和節點 B。

  • 節點 A 由網域控制站 A 驗證,節點 B 由網域控制站 B 驗證。



可能出現下列情形:

  1. Sqlcluster 執行個體在節點 A 上啟用,並在啟動時於網域控制站 A 註冊 SQL SPN。

  2. 節點 A 正常關閉時,Sqlcluster 執行個體無法移轉至節點 B。

  3. 在節點 A 關閉過程中,Sqlcluster 執行個體會在網域控制器 A 中解除註冊其 SPN。

  4. 已從網域控制站 A 移除 SPN,但尚未複寫至網域控制站 B。

  5. 在節點 B 上啟動後,Sqlcluster 執行個體會嘗試註冊網域控制站 B 的 SQL SPN。由於 SPN 仍存在,節點 B 不會註冊 SPN。

  6. 過一段時間後,網域控制站 A 會將刪除的 SPN(步驟 3)複寫至網域控制站 B,作為 Active Directory 複寫的一部分。 最終結果是網域的 SQL 執行個體不存在有效的 SPN,所以您會看到 Sqlcluster 執行個體的連線問題。


注意:此問題已在 SQL Server 2012 中修正。

驗證伺服器環境 確認安裝 SQL Server 電腦的部分基本設定值:

  1. 除非已將 Service Pack 3 (或更新版本) 套用至 Windows 2000,否則執行 Windows 叢集的 Windows 2000 電腦不支援 Kerberos 驗證。 因此,在 SQL Server 叢集執行個體上使用 SSPI 驗證的任何嘗試可能會失敗。 如需詳細資訊,請按一下下面的文章編號,檢視「Microsoft 知識庫」中的文章:

    235529 Windows 2000 伺服器叢集支援的 Kerberos 驗證
     

  2. 請確認該伺服器正在執行 Windows 2000 Service Pack 1 (SP1)。 如需 Windows 2000 伺服器叢集支援的 Kerberos 驗證的詳細資訊,請按一下下面的文件編號檢視「Microsoft 知識庫」中的文件:

    267588 連線至 SQL Server 2000 時顯示「Cannot generate SSPI context」錯誤訊息
     

  3. 在叢集上,如果您變更用於啟動 SQL Server、SQL Server Agent 或全文檢索搜尋的帳戶內容,例如使用新的密碼,請依照下列「Microsoft 知識庫」文件中提供的步驟操作:

    239885 如何為執行 SQL Server 之叢集電腦變更服務帳戶
     

  4. 請驗證用來啟動 SQL Server 的帳戶是否有適當的權限。 若您使用的帳號並非「本機管理員」群組的成員,請參閱《SQL Server 線上叢書》的「設定 Windows 服務帳戶」主題,以取得此帳戶必須具備的詳細權限清單:

    http://msdn2.microsoft.com/library/aa176564(SQL.80).aspx

驗證用戶端環境 在用戶端驗證下列項目:

  1. 請確定 NTLM 安全性支援提供者已正確安裝並於用戶端啟用。 如需詳細資訊,請按一下下面的文章編號,檢視「Microsoft 知識庫」中的文章:

    269541若遺失 Windows NT LM 安全性支援提供者登錄機碼,則會在連線至 SQL Server 時引發此錯誤訊息: 無法產生 SSPI 內容的錯誤訊息
     

  2. 判斷您是否正在使用快取的憑證。 若您使用快取的憑證登入用戶端,當您可連線至網域控制站時,請登出該電腦並再次登入,以避免快取的憑證遭誤用。 如需如何判斷是否正在使用快取憑證的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:

    242536使用網域快取憑證登入時未警告使用者
     

  3. 確認用戶端和伺服器上的日期正確。 如果日期相距太遠,您的憑證可能會被視為無效。

  4. SSPI 使用名為 Security.dll 的檔案。 若其他任何應用程式安裝的檔案使用此名稱,系統可能會使用其他檔案而非原始的 SSPI 檔案。 如需詳細資訊,請按一下下面的文章編號,檢視「Microsoft 知識庫」中的文章:

    253577 錯誤: 80004005 - MS ODBC SQL Server 驅動程式無法初始化 SSPI 套件
     

  5. 如果用戶端的作業系統是 Microsoft Windows 98,則必須在用戶端安裝 Client for Microsoft Networks 元件。

    如需詳細資訊,請按一下下面的文章編號,檢視「Microsoft 知識庫」中的文章:

    267550 BUG: 當您透過 TCP/IP 連線至 SQL Server 時顯示「判斷提示失敗」
     

驗證用戶端網路公用程式 Microsoft Data Access Components (MDAC) 隨附用戶端網路公用程式(CNU) ,用於設定執行 SQL Server 電腦的連線能力。 您可以使用 MDAC Cliconfg.exe CNU 公用程式來設定連線能力:

  1. 「一般」索引標籤中,通訊協定的定義方法依 MDAC 版本而異。 您可以使用舊版 MDAC 選取「預設」通訊協定。 若使用最新版的 MDAC,當連線至時 SQL Server 時,您可以啟用清單頂端的一或多個通訊協定。 因為 SSPI 僅適用於 TCP/IP,您可以使用不同的通訊協定,例如具名管道以避免錯誤。

  2. 檢查 CNU 中的「別名」索引標籤,驗證您嘗試連線的伺服器是否已經定義別名。 若已定義伺服器別名,請檢查這部電腦連線至 SQL Server 的設定方式。 您可透過刪除別名伺服器查看行為是否變更進行驗證。

  3. 若 CNU 上未定義別名伺服器,請加入您要連線的伺服器別名。 當您執行此工作時,同時也明確定義了通訊協定,並且可視需要定義 IP 位址和連接埠。

手動設定 SQL Server 的服務主體名稱 如需有關如何手動設定 SQL Server 服務主要名稱的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:

319723 如何在 SQL Server 中使用 Kerberos 驗證
  安全性支援提供者介面 (SSPI) 是 Microsoft Windows NT 安全性的介面,用於 Kerberos 驗證,並支援 NTLM 安全性支援提供者的驗證配置。 當您登入 Windows 網域時,將在作業系統層級執行驗證。 Kerberos 驗證僅適用已啟用 Kerberos 驗證並使用 Active Directory 之以 Windows 2000 為基礎的電腦。

SSPI 只適用於透過 Windows 驗證的 TCP/IP 連線。 Windows 驗證也稱為可信任的連線或整合式安全性。 SSPI 不會用於具名管道或多重通訊協定的連線。 因此,您可以設定 TCP/IP 以外的通訊協定供用戶端連線,以避免這個問題。

當 SQL Server 用戶端嘗試使用整合式安全性,透過 TCP/IP 通訊端連線至執行 SQL Server 的遠端電腦時,SQL Server 用戶端的網路程式庫將使用 SSPI API 來執行安全性委派。 SQL Server 網路用戶端(Dbnetlib.dll)會呼叫 AcquireCredentialsHandle 函數,並傳遞 pszPackage 參數的「交涉」值。 這樣一來便告知了基礎安全性提供者來執行交涉委派。 在此情況下,交涉代表嘗試在 Windows 電腦上執行 Kerberos 或 NTLM 驗證。 換句話說,若執行 SQL Server 的目的電腦有關聯且正確設定的 SPN,Windows 將使用 Kerberos 委派。 否則,Windows 會使用 NTLM 委派。

注意:驗證您未使用名為「SYSTEM」的帳戶啟動任何 SQL Server 服務(MSSQLServer、SQLServerAgent、MSSearch)。 關鍵字 SYSTEM 可能會與金鑰發行中心 (KDC) 造成衝突。
 

 

若您無法從此文件的疑難排解步驟瞭解問題的原因,請收集下列資訊並開啟 Microsoft 客戶支援(CSS)案件:

如需「Microsoft 客戶支援服務」的完整電話號碼清單以及支援費用的相關資訊,請造訪下列 Microsoft 網站。

http://support.microsoft.com/zh-tw/contactus/?ws=support

  1. 從 SQL Server 產生 sqldiag 報表。 如需詳細資訊,請參閱《SQL Server 線上叢書》的<sqldiag 公用程式>主題:

  2. 擷取用戶端螢幕的錯誤畫面。

  3. 在無法連線至 SQL Server 的節點上開啟命令提示字元,然後輸入下列命令:

    net start > started.txt 這個命令會在執行命令的目錄中產生名為 Started.txt 的檔案。

  4. 在用戶端電腦的下列登錄機碼下方儲存登錄機碼值:

    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO

  5. 在叢集環境中尋找下列每個叢集節點的登錄機碼值:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel

  6. 在叢集環境中查看每個叢集伺服器節點上是否存在下列登錄機碼:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp

  7. 如果您是透過用戶端通用命名慣例 (UNC) 的名稱 (或叢集上的 SQL 網路名稱) 連線至 SQL Server,請擷取結果。

  8. 如果您是透過用戶端偵測電腦名稱 (或叢集上的 SQL 網路名稱),請擷取結果。

  9. 儲存用來啟動每個 SQL Server 服務(MSSQLServer、SQLServerAgent、MSSearch)的使用者帳戶名稱。

  10. 支援專業人員必定知道 SQL Server 是否設定為混合式驗證或只有 Windows 驗證。

  11. 使用 SQL Server 驗證查看您是否能從同一個用戶端連線至執行 SQL Server 的電腦。

  12. 使用具名管道通訊協定查看是否可以連線。

參考 如需 Kerberos 驗證和 SSPI 安全性運作方式的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:

266080解答 Kerberos 驗證的常見問題
 

231789Windows 2000 的本機登入程序
 

304161SSPI 相互驗證表示在用戶端而非在伺服器端
 

232179 Windows 2000 的 Kerberos 管理
 

230476描述 Windows 2000 的 Kerberos 常見錯誤
 

262177如何啟用 Kerberos 事件記錄
 

277658若網域名稱與註冊 SQL Server SPN 所用的 NetBIOS 名稱不同,Setspn 就會失敗

244474如何在 Windows Server 2003、Windows XP 和 Windows 2000 中強制 Kerberos 使用 TCP 而非 UDP
  要查看 Microsoft SQL Server 2000 安全性的白皮書,請造訪下列 Microsoft 網站:

http://technet.microsoft.com/cc984178.aspx

Need more help?

Expand your skills
Explore Training
Get new features first
Join Microsoft Insiders

Was this information helpful?

Thank you for your feedback!

Thank you for your feedback! It sounds like it might be helpful to connect you to one of our Office support agents.

×