SQL Server 中的一致性驗證問題

適用于：SQL Server

注意事項

本文中提供的命令僅適用於 Windows 系統。

Microsoft SQL Server 中發生的一致驗證問題通常與嘗試存取 SQL Server 資料庫之使用者或應用程式的驗證和授權有關。 這些問題可能是驗證失敗、拒絕存取錯誤或其他安全性相關問題。

有效解決一致驗證問題的關鍵在於瞭解不同的錯誤類型，以及每個錯誤訊息的意義。 某些錯誤可能會出現在多個驗證問題中。 您可以使用錯誤類型一節中所述 的 疑難解答資訊來解決錯誤。

必要條件

開始進行疑難解答之前，請先完成 必要條件 檢查清單，以備妥下列資訊：

• 安裝 WireShark 和 問題步驟錄製器 (PSR.exe) 工具。 如需詳細資訊，請參閱 收集數據的方法，以針對各種類型的錯誤進行疑難解答。

• 收集服務提供者名稱 (SPN) 以服務帳戶為基礎的資訊。 若要這樣做，請使用 SETSPN -L 命令。

錯誤類型

本節描述錯誤類型和相關信息。

• 目錄服務錯誤：如果 SQL Server 錯誤記錄檔包含下列任一或兩個訊息，則此錯誤與 Active Directory 網域服務 (AD DS) 相關。 如果 SQL Server 電腦上的 Windows 無法連絡域控制器 (DC) ，或如果本地安全機構子系統服務 (LSASS) 遇到問題，也可能會發生此錯誤。

  Error -2146893039 (0x80090311): No authority could be contacted for authentication.
  Error -2146893052 (0x80090304): The Local Security Authority cannot be contacted.
  

• 登入失敗錯誤：當您針對「登入失敗」錯誤進行疑難解答時，SQL Server 錯誤記錄檔會提供錯誤碼 18456 的其他深入解析，包括提供更多有關錯誤內容的特定狀態值。 如需詳細資訊，請參閱 SQL Server 錯誤記錄檔中的 SQL 狀態值。 您可以嘗試根據狀態值的描述來修正問題。

  下表列出一些特定的「登入失敗」錯誤訊息及其可能的原因和解決方案。

  錯誤訊息	其他相關資訊
  「將要求傳送至伺服器時發生傳輸層級錯誤。」	檢查 連結的伺服器帳戶 對應是否正確。 如需詳細資訊， 請參閱 sp_addlinkedsrvlogin。
  「無法產生 SSPI 內容」	明確的SPN帳戶可能 錯誤、遺失或錯置。 檢查 SPN 是否位於錯誤的帳戶上。
  「無法開啟登入所要求的資料庫 <測試> 。 登入失敗。」	資料庫可能脫機，或許可權可能不足。 如需詳細資訊，請參閱 MSSQLSERVER_18456 中的資料庫脫機。 此外，請檢查連接字串中的資料庫名稱是否正確。
  「使用者 <使用者名稱登入失敗。>」	如果 Proxy 帳戶 未正確驗證，就會發生此錯誤。
  「使用者登入失敗：'NT AUTHORITY\ANONYMOUS LOGON'」	如果 SPN遺失、SPN重複，或SPN位於錯誤的帳戶上，可能會發生此錯誤。
  「使用者 <使用者名稱登入失敗。>」 「使用者 '<database\username 登入>失敗」	檢查 連接字串是否包含不正確的伺服器名稱。 此外，請檢查使用者是否屬於用來授與伺服器存取權的本機群組。 如需更多原因，請參閱 NT AUTHORITY\ANONYMOUS LOGON。
  「使用者 'username'< 的登入>失敗。 原因：密碼與提供的登入不相符。」	如果使用不正確的密碼，可能會發生此錯誤。 如需詳細資訊，請參閱 使用者 『<username>』 的登入失敗或使用者 『<domain><username』 的登入>失敗。
  「SQL Server 不存在或拒絕存取。」	命名管道連線 失敗，因為用戶沒有登入 Windows 的許可權。
  「登入來自不受信任的網域，無法與 Windows 驗證搭配使用。」	此錯誤可能與 本機安全性子系統 問題有關。
  「不允許使用者帳戶使用網路登入類型。」	您可能無法 登入網路。

一致驗證問題的類型

本節說明一致驗證問題及其各自解決方案的一般原因。 選取問題類型以查看相關問題、原因和解決方案。

連接字串

本節列出與應用程式用來連線到資料庫的組態設定相關的問題。

• 遺漏明確SPN - 如果SPN 未正確設定或註冊，就會發生此問題。

  解決方案： 若要解決此問題，請參閱 使用 Windows 驗證連線 SQL Server 時發生「無法產生 SSPI 內容」錯誤。

• 明確錯置的 SPN - 是指與特定服務或帳戶不正確關聯的 SPN。

  解決方案： 若要解決此問題，請參閱 明確錯置的SPN。

• 明確SPN重複 - 如果SPN 因為註冊超過一次而重複，就會發生此問題。

  解決方案： 若要解決此問題，請參閱 使用 Windows 驗證連線 SQL Server 時發生「無法產生 SSPI 內容」錯誤。

• 連接字串中的伺服器名稱不正確 - 如果指定的伺服器名稱不正確或找不到，就會發生此問題。

  解決方案： 若要解決此問題，請 參閱MSSQLSERVER_18456。

• 連接字串中的資料庫名稱錯誤 - 如果提供給驗證的資料庫名稱不正確，就會發生此問題。

  解決方案： 檢查名稱拼字是否正確。 如需詳細資訊，請 參閱 MSSQLSERVER_4064。

• 錯誤的明確 SPN 帳戶 - 如果 SPN 與 AD DS 中的錯誤帳戶相關聯，就可能發生此問題。

  解決方案： 若要解決此問題，請參閱 無法產生 SSPI 內容錯誤。

資料庫

本節列出 SQL Server 各個層面特有的問題：

• 資料庫離線 - 是指 SQL Server 資料庫嘗試重新連線到針對 Windows 驗證模式所設定之 SQL Server 實例的案例。

  解決方案： 如需詳細資訊， 請參閱 MSSQLSERVER_18456。

• 資料庫許可權 - 是指啟用或限制對 SQL Server 資料庫的存取。

  解決方案： 如需詳細資訊， 請參閱 MSSQLSERVER_18456。

• SQL Server 中的連結伺服器連線錯誤 - 您遇到驗證程式問題，會影響 SQL Server 內容中的連結伺服器。

  解決方案： 若要解決此問題，請參閱 SQL Server 中的連結伺服器連線錯誤。

• 鏈接伺服器的元數據不一致 - 是指鏈接伺服器的元數據不一致或不符合預期元數據的問題。

  檢視或預存程式會查詢鏈接伺服器中的數據表或檢視，但即使從程式複製的分散式 SELECT 語句沒有收到登入失敗。

  如果已建立檢視，然後重新建立連結的伺服器，或在未重建檢視的情況下修改遠端數據表，就可能會發生此問題。

  解決方案：執行預存程式來重新整理連結伺服器的 sp_refreshview 元數據。

• Proxy 帳戶沒有許可權 - SQL Agent 執行的 SQL Server Integration Service (SSIS) 作業可能需要 SQL Agent 服務帳戶可提供的許可權以外的許可權。

  解決方案： 若要解決此問題，請參閱 從 SQL Server Agent 作業步驟呼叫時，SSIS 套件不會執行。

• 無法登入 SQL Server 資料庫 - 無法登入可能會導致驗證失敗。

  解決方案： 若要解決此問題，請 參閱MSSQLSERVER_18456。

目錄服務

本節列出與目錄服務和伺服器相關的問題。

• 帳戶已停 用 - 如果使用者帳戶已由系統管理員或使用者停用，您可能會遇到這種情況。 在此情況下，您無法使用此帳戶登入，或無法使用此帳戶來啟動服務。 這可能會導致一致的驗證問題，因為它可能會防止您存取資源或執行需要驗證的動作。

  解決方案： 網域系統管理員可以重新啟用帳戶來修正此問題。 當帳戶停用時，通常是因為用戶嘗試以錯誤密碼登入太多次，或是因為應用程式或服務嘗試使用舊密碼。

• 帳戶不在群組中 - 如果使用者嘗試存取受限於特定群組的資源，可能會發生此問題。

  解決方案： 檢查 SQL 登入以列舉允許的群組，並確定用戶屬於其中一個群組。

• 帳戶移轉失敗 - 如果舊的用戶帳戶無法連線到伺服器，但新建立的帳戶可以，帳戶移轉可能不正確。 此問題與 AD DS 相關。

  解決方案： 如需詳細資訊，請 參閱在 SQL Server 實例之間傳輸登入和密碼。

• 域控制器離線 - 是指無法存取域控制器的問題。

  解決方案： 使用 命令 nltest 來強制計算機切換至另一個域控制器。 如需詳細資訊，請參閱 Active Directory 複寫事件標識碼 2087：DNS 查閱失敗導致復寫失敗。

• 防火牆會封鎖域控制器 - 當您管理使用者對資源的存取權時，可能會遇到問題。

  解決方案： 請確定可以從客戶端或伺服器存取域控制器。 若要這樣做，請使用 nltest /SC_QUERY:CONTOSO 命令。

• 登入來自不受信任的網域 - 此問題與網域之間的信任層級有關。 您可能會看到下列錯誤訊息：「登入失敗。 登入來自不受信任的網域，無法與 Windows 驗證搭配使用。 (18452) 」。

  錯誤 18452 表示登入使用 Windows 驗證，但登入是無法辨識的 Windows 主體。 無法辨識的 Windows 主體表示 Windows 無法驗證登入。 這可能是因為 Windows 登入來自不受信任的網域。 網域之間的信任層級可能會導致帳戶驗證失敗，或SPN (SPN) 的服務提供者名稱可見度。

  解決方案： 若要解決此問題，請 參閱 MSSQLSERVER_18452。

• 沒有跨網域群組的 許可權 - 來自 遠端網域的用戶應該屬於 SQL Server 網域中的群組。 如果您嘗試使用網域本機群組從另一個網域連線到 SQL Server 實例，可能會發生問題。

  解決方案： 如果網域缺乏適當的信任，在遠端網域的群組中新增使用者可能會使伺服器無法列舉群組的成員資格。

• 已停用選擇性驗證 - 指的是網域信任的功能，可讓網域系統管理員限制哪些使用者可以存取遠端網域中的資源。 如果未啟用選擇性驗證，信任網域中的所有使用者都可以存取遠端網域。

  解決方案： 若要解決此問題，請啟用選擇性驗證，以確保不允許使用者在遠端網域中進行驗證。

Kerberos 驗證

本節列出與 Kerberos 驗證相關的問題：

• 不正確的 DNS 後綴會附加至 NetBIOS 名稱 - 如果您只使用 NetBIOS 名稱 (例如，SQLPROD01) 而不是 FQDN (FQDN) (的完整功能變數名稱，例如 SQLPROD01.CONTOSO.COM) ，就可能發生此問題。 發生這種情況時，可能會附加錯誤的 DNS 後綴。

  解決方案： 檢查預設後綴的網路設定，以確定它們正確無誤，或使用 FQDN 來避免問題。

• 時鐘誤差太高 - 如果網路上的多個裝置未同步處理，就可能發生此問題。 若要讓 Kerberos 驗證能夠運作，裝置之間的時鐘無法關閉超過五分鐘，或可能發生一致的驗證失敗。

  解決方案： 設定計算機以定期同步處理其時鐘與中央時間服務。

• 將敏感性帳戶委派給其他服務 - 某些帳戶可能會在 AD DS 中標示為 Sensitive 。 在雙躍點案例中，這些帳戶無法委派給另一個服務。 敏感性帳戶對於提供安全性很重要，但可能會影響驗證。

  解決方案： 若要解決此問題，請參閱 使用者 NT AUTHORITY\ANONYMOUS LOGON 的登入失敗。

• 委派給檔案共用 - 是指使用者或應用程式委派其認證以存取檔案共享的情況。 如果沒有適當的條件約束，將認證委派給檔案共用可能會造成安全性風險。

  解決方案： 若要解決這種問題，請確定您使用 限制委派。

• 脫離的 DNS 命名空間 - 是指如果網域成員與 DNS 之間的 DNS 後綴不相符時，可能會發生的一致驗證問題。 如果您使用脫離的命名空間，可能會遇到驗證問題。 如果 AD DS 和 DNS 中的組織階層不相符，如果您在資料庫應用程式連接字串中使用 NETBIOS 名稱，可能會產生錯誤的 SPN。 在此情況下，找不到 SPN，而且會使用 NEW Technology LAN Manager (NTLM) 認證，而不是 Kerberos 認證。

  解決方案： 若要減輕此問題，請使用伺服器的 FQDN，或在連接字串中指定 SPN 名稱。 如需 FQDN 的相關信息，請參閱 電腦命名。

• 重複的SPN - 是指網域內兩個或多個SPN完全相同的情況。 SPN 可用來唯一識別在 Windows 網域中伺服器上執行的服務。 重複的SPN可能會導致驗證問題。

  解決方案： 若要解決此問題，請參閱 使用 Kerberos Configuration Manager 修正錯誤 (建議) 。

• 在SPN上啟用 HTTP 連接埠 - 一般而言，HTTP SPN 不會使用埠號碼 (例如 http/web01.contoso.com ，) 。

  解決方案： 若要解決此問題，您可以在用戶端上使用 原則來啟用此功能。 然後SPN必須是格式， http/web01.contoso.com:88 才能讓 Kerberos 正常運作。 否則，會使用NTLM認證。

  不建議使用NTLM認證，因為它們可能會讓診斷問題變得困難。 此外，這種情況可能會產生過多的系統管理額外負荷。

• 過期的票證 - 指的是 Kerberos 票證。 使用過期的 Kerberos 票證可能會導致驗證問題。

  解決方案： 若要解決此問題，請參閱 過期的票證。

• HOSTS 檔案不正確 - HOSTS 檔案可能會中斷 DNS 查閱，而且可能會產生未預期的 SPN 名稱。 這種情況會導致使用 NTLM 認證。 如果 HOSTS 檔案中有未預期的 IP 位址，產生的 SPN 可能與指向的後端伺服器不符。

  解決方案： 檢閱 HOSTS 檔案，並移除您伺服器的專案。 HOSTS 檔案項目會顯示在 SQLCHECK 報表中。

• 個別服務安全標識碼 (SID) 許可權的問題 - Per-service-SID 是 SQL Server 的安全性功能，可限制本機連線使用 NTLM，而非 Kerberos 作為驗證方法。 服務可以使用NTLM認證對另一部伺服器進行單一躍點，但若未使用限制委派，就無法進一步委派。 如需詳細資訊，請 參閱使用者 NT AUTHORITY\ANONYMOUS LOGON 的登入失敗。

  解決方案： 若要解決此問題，網域系統管理員必須設定限制委派。

• 核心模式驗證 - Web 伺服器通常需要應用程式集區帳戶上的 SPN。 不過，使用內核模式驗證時，會使用計算機的 HOST SPN 進行驗證。 此動作會在核心中進行。 如果伺服器裝載許多使用相同主機標頭 URL、不同應用程式集區帳戶和 Windows 驗證的不同網站，則可能會使用此設定。

  解決方案： 如果已啟用內核模式驗證，請移除 HTTP SPN。

• 限制 Access 或 Excel 的委派權 限 - 聯合引擎技術 (JET) 和 Access Connectivity Engine (ACE) 提供者與任何文件系統類似。 您必須使用限制委派，讓 SQL Server 讀取位於另一部電腦上的檔案。 一般而言，ACE 提供者不應該在鏈接的伺服器中使用，因為明確不支援。 JET 提供者已被取代，只能在32位電腦上使用。

  注意事項

  當支援 32 位安裝的最後一個版本 SQL Server 2014 不再支援時，將不再支援 JET 案例。

• 遺漏 SPN - 如果與 SQL Sever 實例相關的 SPN 不存在，可能會發生此問題。

  解決方案： 如需詳細資訊，請參閱 使用 Kerberos Configuration Manager 修正錯誤 (建議) 。

• 不是受限制的目標 - 如果已針對特定服務帳戶啟用限制委派，如果目標伺服器的SPN不在限制委派的目標清單上，Kerberos 將會失敗。

  解決方案： 若要解決此問題，網域系統管理員必須將目標伺服器的SPN新增至中層服務帳戶的目標SPN。

• NTLM 和限制委派 - 如果目標為檔案共用，則中層服務帳戶的委派類型必須是 Constrained-Any ，而不是 Constrained-Kerberos。 如果委派類型設定為 Constrained-Kerberos，則中層帳戶只能配置給特定服務，但 Constrained-Any 允許服務帳戶委派給任何服務。

  解決方案： 若要解決此問題，請參閱 使用者 NT AUTHORITY\ANONYMOUS LOGON 的登入失敗。

• 服務帳戶在 AD 中無法受信任以進行委 派 - 在雙躍點案例中，必須信任中層服務的服務帳戶，才能在 AD DS 中委派。 如果服務帳戶不受信任而無法委派，則 Kerberos 驗證可能會失敗。

  解決方案： 如果您是系統管理員，請啟用 [信任委派] 選項。

• 某些舊版提供者不支援透過命名管道的 Kerberos - 舊版 OLE DB 提供者 (SQLOLEDB) 和 ODBC 提供者 (與 Windows 配套的 SQL Server) 不支援透過命名管道進行 Kerberos 驗證。 相反地，它們只支援NTLM驗證。

  解決方案： 使用 TCP 連線來允許 Kerberos 驗證。 您也可以使用較新的驅動程式，例如 MSOLEDBSQL 或 ODBC Driver 17。 但不論驅動程式的版本為何，TCP 仍優先於命名管道。

• SPN 與錯誤的帳戶相關聯 - 如果 SPN 與 AD DS 中的錯誤帳戶相關聯，就可能發生此問題。 如需詳細資訊，請參閱 使用 Kerberos Configuration Manager 修正錯誤 (建議) 。

  如果您的 SPN 是在 AD DS 中的錯誤帳戶上設定，您可能會收到錯誤訊息。

  解決方案： 若要解決此錯誤，請遵循下列步驟：

  1. 使用 SETSPN -Q spnName 找出SPN及其目前的帳戶。
  2. 使用 SETSPN -D 刪除現有的SPN。
  3. SETSPN -S使用將SPN移轉至正確的帳戶。

• SQL 別名可能無法正確運作 - SQL Server 別名可能會產生非預期的 SPN。 如果找不到 SPN，這會導致 NTLM 認證失敗;如果不小心符合另一部伺服器的 SPN，則會導致 SSPI 失敗。

  解決方案： SQL 別名會顯示在 SQLCHECK 報告中。 若要解決此問題，請識別並更正任何不正確或設定錯誤的 SQL 別名，使其指向正確的 SQL Server。

• 使用者屬於許多群組 - 如果使用者屬於多個群組，Kerberos 中可能會發生驗證問題。 如果您透過 UDP 使用 Kerberos，則整個安全性令牌必須符合單一封包。 相較於屬於較少群組的使用者，屬於許多群組的用戶擁有更大的安全性令牌。

  解決方案： 如果您使用 Kerberos over TCP，您可以增加 [MaxTokenSize] 設定。 如需詳細資訊，請參閱 MaxTokenSize 和 Kerberos 令牌 Bloat。

• 使用網站主機標頭 - HTTP 主機標頭在存取網頁的 HTTP 通訊協定中扮演非常重要的角色。

  解決方案： 如果網站具有主機標頭名稱，則無法使用 HOSTS SPN。 必須使用明確的 HTTP SPN。 如果網站沒有主機標頭名稱，則會使用NTLM。 NTLM 無法委派給後端 SQL Server 實例或其他服務。

NT LAN Manager (NTLM)

本節列出 NTLM (NT LAN Manager) 特有的問題：

• NTLM 對等登入的存取遭到拒絕 - 指的是與 NTLM 對等登入相關的問題。

  解決方案： 在工作站或網域中彼此不信任的計算機之間進行通訊時，您可以在這兩部計算機上設定相同的帳戶，並使用 NTLM 對等驗證。

  只有當兩部計算機上的用戶帳戶和密碼都相符時，登入才能運作。 用戶端或伺服器端可能已停用或不支援NTLM驗證。 這種情況可能會導致驗證失敗。 如需詳細資訊， 請參閱 MSSQLSERVER_18456。

• 多部計算機上的雙躍點案例 - 如果使用NTLM認證，雙躍點程式將會失敗。 需要 Kerberos 認證。

  解決方案： 若要解決此問題，請參閱 使用者 NT AUTHORITY\ANONYMOUS LOGON 的登入失敗。

• 回送保護未正確設定 - 回送保護的設計目的是要禁止應用程式呼叫相同電腦上的其他服務。 如果未正確設定回送保護，或有任何故障，這種情況可能會間接造成驗證問題。

  解決方案： 若要解決此問題，請 參閱MSSQLSERVER_18456。

• 當您連線到 Always-on 接聽程式時，回送保護會失敗 - 此問題與回送保護有關。 當您從主要節點連線到 Always-On 接聽程式時，聯機會使用NTLM驗證。

  解決方案： 如需詳細資訊， 請參閱 MSSQLSERVER_18456。

• 影響 LANMAN 相容性層級的問題 - 如果舊版 (Windows Server 2008) 和更新版本電腦所使用的驗證通訊協定不符，通常會發生 LAN Manager (LANMAN) 驗證問題。 當您將相容性層級設定為 5 時，不允許 NTLMv2。

  解決方案： 切換至 Kerberos 可避免此問題，因為 Kerberos 更安全。 如需詳細資訊，請 參閱使用者 NT AUTHORITY\ANONYMOUS LOGON 的登入失敗。

SQL 登入

本節列出與驗證認證相關的問題：

• 密碼錯誤 - 是指登入相關問題。

  解決方案： 若要解決此問題，請 參閱MSSQLSERVER_18456。

• 無效的使用者名稱 - 是指登入相關問題。

  解決方案： 若要解決此問題，請 參閱MSSQLSERVER_18456。

• 未啟用 SQL Server 登 入 - 指的是您嘗試使用 SQL Server 驗證連線到 Microsoft SQL Server 實例的案例，但已停用與帳戶相關聯的登入。

  解決方案： 若要解決此問題，請 參閱MSSQLSERVER_18456。

• 命名管道連線失敗，因為用戶沒有登入 Windows 的權 限 - 指的是 Windows 中的許可權問題。

  解決方案： 若要解決此問題，請參閱 SQL Server 中的命名管道連線問題。

Windows 許可權

本節列出 Windows 許可權或原則設定特有的問題：

• 存取權是透過本機群組授 與 - 如果使用者不屬於用來授與伺服器存取權的本機群組，則提供者會顯示「使用者 』contoso/user1' 登入失敗」錯誤訊息。

  解決方案： 資料庫管理員可以檢查 SQL Server Management Studio 中 的安全>性登 入資料夾， (SSMS) 來檢查這種情況。 如果資料庫是自主資料庫，請在 下 databasename檢查。 如需詳細資訊，請參閱 使用者 『<username>』 的登入失敗或使用者 『<domain>\<username』 的登入>失敗。

• 已啟用 Credential Guard - 此案例表示 Credential Guard 功能已在 Windows 系統上啟用，並用來建立安全的環境來儲存敏感性資訊。 不過，在某些情況下，這項功能可能會造成驗證問題。

  解決方案： 若要解決此問題，請要求網域系統管理員設定限制委派。 如需詳細資訊，請參 閱使用 Credential Guard 時的考慮和已知問題。

• 本機安全性子系統錯誤 - 當您遇到本機安全性子系統錯誤時，特別是連結到 LSASS 的子系統錯誤沒有回應時，可能會指出影響驗證的基礎問題。

  解決方案： 若要解決這些錯誤，請參閱 SQL Server 中的本機安全性子系統錯誤。

• 不允許網路登 入 - 當您嘗試登入網路，但因為某些原因而拒絕登入要求時，就會發生此案例。

  解決方案： 若要解決此問題，請參閱 用戶沒有登入網路的許可權。

• 只有系統管理員可以登入 - 如果計算機上的安全性記錄已滿，且沒有足夠的空間來填滿事件，就會發生此問題。 系統管理員會使用安全性功能 CrashOnAuditFail 來檢查所有安全性事件。 的有效值為 CrashOnAuditFail0、 1 和 2。 如果的金鑰設定為 CrashOnAuditFail2，這表示安全性記錄已滿，而且會顯示「只有系統管理員可以登入」錯誤訊息。

  解決方案： 若要解決此問題，請遵循下列步驟：

  1. 啟動註冊表編輯器。
  2. 找出並檢查 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa!crashonauditfail 子機碼，以查看值是否設定為 2。 這個值表示安全性記錄檔需要手動清除。
  3. 將值設定為 0，然後重新啟動伺服器。 您可能也想要變更安全性記錄檔，以啟用事件變換。 如需設定如何影響 SQL、IIS、檔案共用和登入等所有服務的詳細資訊，請參閱 當安全性事件記錄檔已滿時，用戶無法存取網站。

  注意事項

  此問題只會影響整合式登入。 命名管道連線也會在 SQL Server 登入中受到影響，因為命名管道會先登入 Windows 管理管道，然後再連線到 SQL Server。

• 服務帳戶不受信任而無法委 派 - 如果不允許服務帳戶將認證指派給其他伺服器，通常會發生這種問題。 此問題可能會影響需要委派的服務。

  解決方案：如果未啟用委派案例，請檢查 SQL Server secpol.msc，以判斷 SQL Server 服務帳戶是否列在 [本>機原則用戶權力指派>] 驗證安全策略設定之後模擬用戶端之下。 如需詳細資訊，請參閱讓電腦及使用者帳戶受信賴，以進行委派。

• 無法在 SQL Server 中載入 Windows 使用者設定檔 - 指的是 Windows 使用者設定檔問題。

  解決方案： 如需如何針對損毀的使用者配置檔進行疑難解答的詳細資訊，請參閱 無法在 SQL Server 中載入 Windows 使用者設定檔。

其他層面

本節列出與 Web 環境內驗證和訪問控制相關的問題：

• 未啟用整合式驗證 - 指的是整合式 Windows 驗證 (IWA) 未正確設定的設定問題。

  解決方案：若要解決此問題，請確定已在 [因特網選項] 設定中啟用 [整合式 Windows 驗證] 選項。

• 不允許 IIS 驗證 - 發生此問題是因為 IIS 中的設定錯誤。 在 Web 應用程式的 Web.config 檔案中定義的驗證設定，可能會與 IIS 中設定的設定衝突。 這種情況可能會導致驗證問題。

  解決方案： 若要解決此問題，請將網站設定為啟用 Windows 驗證， <identity impersonate="true"/> 並在 Web.config 檔案中設定值。

• 錯誤的因特網區域 - 如果您嘗試存取不在 Internet Explorer 中正確因特網區域中的網站，可能會發生此問題。 如果網站位於近端內部網路區域，認證將無法運作。

  解決方案： 將網頁伺服器新增至 IE 的近端內部網路區域。

協力廠商資訊免責聲明

本文提及的協力廠商產品是由與 Microsoft 無關的獨立廠商所製造。 Microsoft 不以默示或其他方式，提供與這些產品的效能或可靠性有關的擔保。

其他相關資訊

收集數據以針對 SQL Server 連線問題進行疑難解答