共用方式為

SQL Server 中的一致驗證問題

  • 發行項

適用於：SQL Server

注意

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

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

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

必要條件

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

錯誤的類型

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

  • 目錄服務錯誤：如果 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 狀態值中的 SQL Server 錯誤記錄檔。 您可以嘗試根據狀態值的描述來修正問題。

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

    錯誤訊息 其他相關資訊
    「傳送要求至伺服器時發生傳輸層級錯誤。」 檢查連結的伺服器帳戶對應是否正確。 如需詳細資訊，請參閱 sp_addlinkedsrvlogin。
    「無法產生 SSPI 內容」
    「無法開啟登入所要求的資料庫 <測試> 。 登入失敗。 資料庫可能脫機，或許可權可能不足。 如需詳細資訊，請參閱 資料庫脫機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 內容錯誤。

Database

本節列出 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） 的可見度。

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

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

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

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

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

Kerberos 驗證

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

  • 將不正確的 DNS 後綴附加至 NetBIOS 名稱 - 如果您只使用 NetBIOS 名稱 （例如，SQLPROD01），而不是完整功能變數名稱 （例如，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 檔案，並移除伺服器的專案。 SQLCHECK 報表中會顯示 HOSTS 檔案專案。

  • 個別服務安全性標識碼 （SID） 許可權 的問題 - 個別服務 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位電腦上。

    注意

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NT LAN 管理員 （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 相容性層級 的問題 - 如果舊版 （Pre-Windows Server 2008） 和較新的電腦所使用的驗證通訊協定中存在不符，通常會發生 LAN Manager （LANMAN） 驗證問題。 當您將相容性層級設定為 5 時，不允許 NTLMv2。

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

SQL Login

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

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

    解決方案： 若要解決此問題，請參閱 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>>』 登入失敗。

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

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

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

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

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

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

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

    解決方案：若要解決此問題，請依照這些步驟執行：

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

    注意

    此問題只會影響整合式登入。 命名管道連線也會在 SQL Server 登入中受到影響，因為命名管道會在連線到 SQL Server 之前先登入 Windows Admin Pipe。

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

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

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

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

其他層面

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

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

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

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

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

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

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

協力廠商資訊免責聲明

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

其他相關資訊

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