|
|
相关文章推荐
當您因為驗證失敗而拒絕連線嘗試時，您會收到此錯誤訊息。 使用者登入可能會因為許多原因而失敗，例如無效的認證、密碼到期，以及啟用錯誤的驗證模式。 在許多情況下，錯誤碼包含描述。
使用者動作
下列範例是一些常見的登入失敗。 選取您遇到以針對問題進行疑難解答的確切錯誤：
使用者 'username' 登入失敗，或使用者 '<<domain>\<username>>' 登入失敗
如果未指定功能變數名稱，問題就是 SQL Server 登入嘗試失敗。 如果指定功能變數名稱，問題就是 Windows 使用者帳戶登入失敗。 如需潛在原因和建議的解決方案，請參閱：
可能的原因 建議的解決方法 您嘗試使用 SQL Server 驗證 ，但 SQL Server 實例已設定為 Windows 驗證模式。 確認 SQL Server 已設定為使用 SQL Server 和 Windows 驗證模式 。 您可以在 SQL Server Management Studio 中對應實例的 [屬性 ] 下方的 [安全性 ] 頁面上 檢閱和變更 SQL Server 實例 的驗證模式。 如需詳細資訊，請參閱 變更伺服器驗證模式 。 或者，您可以將應用程式變更為使用 Windows 驗證模式 來連線到 SQL Server。注意 ：您可以在此案例的 SQL Server 錯誤記錄檔中看到如下的訊息：
Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only.
您正嘗試透過群組存取 SQL Server，並看到錯誤訊息。
如果您沒有存取伺服器的必要許可權，提供者會顯示「使用者 』contoso/user1' 登入失敗」錯誤訊息。 使用「透過群組存取」功能，協助您根據群組成員資格存取伺服器。
當您執行預
xp_logininfo 'contoso/user1'
存程式時，可能會發生下列情況：
- 如果您看到錯誤，SQL Server 完全無法解析使用者名稱。 名稱可能不存在於 Active Directory （AD） 中，或連線到域控制器時可能會發生問題。 嘗試使用另一個名稱來檢查問題是否為特定帳戶專屬。
- 如果您要連線到跨網域伺服器，群組必須位於 SQL Server 網域中，而不是使用者網域，才能解析其成員資格。
- 當資料庫查詢未傳回任何數據列時，表示沒有提供伺服器存取權的群組。 當查詢傳回一或多個數據列時，表示用戶屬於提供存取權的群組。
DBA 可以檢查 SQL Server Management Studio （SSMS） 中的 Security\Logins 資料夾，以再次檢查 許可權。 Security\Logins 會顯示已建立的登入清單。 如果是自主資料庫，DBA 可以檢查 資料庫名稱下的 Security\Logins ，以檢查和管理登入。
如需詳細資訊，請參閱 設定使用者 存取控制 和許可權 。 未啟用 SQL 登入 資料庫管理系統 （DBMS） 可能會顯示訊息的
Login failed for user '<username>'
一些變化。 請依照下列步驟解決此錯誤：
1.檢查 SQL Server 錯誤記錄檔是否包含錯誤訊息「使用者名稱登入<>失敗」。 原因：嘗試使用 SQL 驗證登入失敗。 伺服器僅針對 Windows 驗證 進行設定。」
2.使用下列其中一種方法來解決錯誤：
- 使用整合式登入。 例如，若為 OLE DB 提供者，請將 新增
INTEGRATED SECURITY=SSPI
至 連接字串，而針對 ODBC 驅動程式，請新增
TRUSTED_CONNECTION=YES
。 .NET 提供者接受任一語法。
注意： 如果未正確設定其他問題，以允許整合式驗證，而且需要調查為個別的問題，可能會導致其他問題。
- 在伺服器上啟用 SQL 登入：
a. 在 SQL Server Management Studio 中，以滑鼠右鍵按兩下 物件總管 中的 SQL Server 名稱，然後選取 [ 屬性 ]。
b. 在 [ 安全性] 窗格中，選取 [SQL Server] 和 [Windows 驗證 ] 模式。
c. 選取 [確定]。
d. 重新啟動 SQL Server 以進行變更。
注意： 這可能會導致其他問題，例如定義 SQL 登入。
- 嘗試為使用者名稱指定本機 Windows 帳戶或網域帳戶。 只允許 SQL 登入。 應用程式應該使用整合式安全性。 您嘗試連線的 SQL Server 實例上不存在登入。 確認 SQL Server 登入存在，且您已正確拼字。 如果登入不存在，請加以建立。 如果存在但拼錯，請在應用程式連接字串中加以校正。 SQL Server Errorlog 將有下列其中一個訊息：
-
Login failed for user 'username'. Reason: Could not find a login matching the name provided.
-
Login failed for user 'Domain\username'. Reason: Could not find a login matching the name provided.
如果您將使用 DEV 或 QA 伺服器的應用程式部署至生產環境，且無法更新連接字串，則這是常見的問題。 若要解決此問題，請驗證您正在連線到適當的伺服器。 如果不是，請校正連接字串。 如果是，請授與 SQL Server 的登入存取權。 或者，如果是 Windows 登入直接授與存取權，或將其新增至允許連線到資料庫伺服器的本機或網域群組。 如需詳細資訊，請參閱
建立登入
。
您使用 SQL Server 驗證
，但您為 SQL Server 登入指定的密碼不正確。
請檢查 SQL 錯誤記錄檔中是否有「
原因：密碼不符合所提供的
登入」等訊息，以確認原因。 若要修正此問題，請在應用程式中使用正確的密碼，或如果您不記得密碼，請使用不同的帳戶。 或者，請與您的 SQL Server 系統管理員合作，重設帳戶的密碼。
如果應用程式是 SQL Server Integration Services （SSIS），作業可能會有多個層級的組態檔，這可能會覆寫封裝的 連線管理員 設定。
如果應用程式是由貴公司所撰寫，且以程式設計方式產生 連接字串，請洽詢開發小組以解決問題。 暫時的因應措施是硬式編碼 連接字串 和測試。 使用 UDL 檔案 或腳本來證明與硬式編碼 連接字串 的連線是可能的。 連接字串 語法、伺服器名稱或使用者認證不正確。 若要解決此問題，請遵循下列步驟：
- 檢查 連接字串 格式。 連接字串 格式必須包含必要的參數，例如伺服器名稱、資料庫名稱、使用者名稱和密碼。
- 檢查 連接字串 中的伺服器名稱。
- 如果您使用具名實例，請包含實例名稱。
- 如果目標伺服器不正確，請更新 連接字串 以指向正確的伺服器。
- 如果 連接字串 正確，請提供資料庫的登入存取權。 若要這樣做，請在資料庫中建立使用者，然後對應至該登入。
- 如果您使用 Windows 登入，請將登入新增至允許連線到資料庫伺服器的本地組或網域群組。
Logon Error: 18456, Severity: 14, State: 11.
Logon Login failed for user 'CONTOSO\JohnDoe'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]
某些錯誤屬於匿名登入帳戶。 這與 Kerberos 問題有關。 HOSTS 檔案中有錯誤的手動專案，也就是說，已指定錯誤的伺服器名稱。
其餘問題可能分為下列類別：
- 使用者的登入遭到拒絕（或未授與）。
- 帳戶可透過Administrators群組存取。
- 用戶所屬的群組在 SQL Server 中具有 DENY 許可權。
有問題的使用者帳戶必須授與資料庫的明確存取權，或新增至 SQL Server 角色或具有數據庫存取權的本機 Windows 群組或網域群組。 如需詳細資訊，請參閱 CREATE USER 、 ALTER ROLE 和 ALTER SERVER ROLE 您不是以系統管理員身分執行應用程式（例如 SSMS）。 如果您嘗試使用系統管理員認證進行連線，請使用 [ 以系統管理員 身分執行] 選項啟動您的應用程式。 線上時，將 Windows 使用者新增為個別登入。 移轉至自主資料庫用戶之後，會刪除登入。 如果 資料庫引擎 支援自主資料庫，請確認登入在移轉至自主資料庫用戶之後並未刪除。 如需詳細資訊，請參閱 自主資料庫驗證：簡介 。 登入的預設資料庫已離線或無法使用。 請洽詢您的 SQL Server 系統管理員，並解決資料庫可用性相關問題。 如果登入具有伺服器上其他資料庫的許可權，而且您不需要存取應用程式中目前設定的預設資料庫，請使用下列其中一個選項：
- 要求系統管理員使用 ALTER LOGIN 語句或 SSMS 變更登入的預設資料庫。
- 在應用程式中 明確指定不同的資料庫 連接字串 。 或者，如果您使用 SSMS 切換至 [ 連線屬性 ] 索引標籤，以指定目前可用的資料庫。SSMS 之類的應用程式可能會顯示如下的錯誤訊息：
Cannot open user default database. Login failed.
Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)
SQL Server Errorlog 會有如下的錯誤訊息：
Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]
如需詳細資訊，請參閱 MSSQLSERVER_4064 。 連接字串 或 SSMS 中明確指定的資料庫拼字錯誤、離線或無法使用。 - 修正 連接字串 中的資料庫名稱。 如果在伺服器上使用區分大小寫定序，請注意區分大小寫。
- 如果資料庫名稱正確，請洽詢您的 SQL Server 系統管理員，並解決資料庫可用性相關問題。 檢查資料庫是否離線、未復原等等。
- 如果登入已對應至具有伺服器上其他資料庫許可權的使用者，而且您不需要存取應用程式中目前設定的資料庫，請在 連接字串 中 指定不同的資料庫。 或者，如果您要使用 SSMS 進行連線，請使用 [ 連接屬性 ] 索引標籤來指定目前可用的資料庫。
SQL Server Errorlog 會有如下的錯誤訊息：
Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]
注意 ：如果登入的預設資料庫可供使用，SQL Server 會允許連線成功。 如需詳細資訊，請參閱 MSSQLSERVER_4064 。 用戶沒有要求之資料庫的許可權。 - 嘗試以另一個具有系統管理員許可權的用戶連線，以查看是否可以建立連線。
- 藉由建立對應的使用者來授與資料庫的登入存取權（例如，
CREATE USER [<UserName>] FOR LOGIN [UserName]
）
此外，請在疑難解答錯誤 18456 中 檢查廣泛的錯誤碼清單。
如需更多疑難解答說明，請參閱 針對 SQL 用戶端/伺服器連線問題 進行疑難解答。
使用者 NT AUTHORITY\ANONYMOUS LOGON 登入失敗
此問題至少有四個案例。 在下表中，檢查每個適用的潛在原因，並使用適當的解決方法：如需雙躍點 一詞 的說明，請參閱下表下方的附注。
建議的解決方案 您嘗試將NT LAN Manager （NTLM） 認證從一個服務傳遞至同一部電腦上的另一個服務（例如：從 IIS 到 SQL Server），但程式中發生失敗。 新增 DisableLoopbackCheck 或 BackConnectionHostNames 登錄專案。 在多部計算機上都有 雙躍點 （條件約束委派）案例。 如果 Kerberos 連線因為服務主體名稱 （SPN） 問題而失敗，就會發生錯誤。 在每個 SQL Server 和網頁伺服器上執行 SQLCheck 。 使用疑難解答指南： 0600 認證委派問題和 0650 SQL Server 鏈接伺服器委派問題 。 如果沒有牽涉到雙躍點（條件約束委派），則可能會有重複的SPN存在，而且用戶端會以LocalSystem或另一個取得NTLM認證的電腦帳戶執行，而不是 Kerberos 認證。 使用 SQLCheck 或 Setspn.exe 來診斷和修正任何 SPN 相關問題。 另請檢閱 適用於 SQL Server 的 Kerberos Configuration Manager 概觀。 Windows 本機安全策略可能已設定為防止電腦帳戶用於遠端驗證要求。 流覽至 [ 本機安全策略 > >本機原則安全選項> ] [網络安全性：允許本機系統使用 NTLM 的計算機身分識別]，如果停用設定，請選取 [已啟用 ] 選項，然後選取 [ 確定]。注意 ：如 [說明 ] 索引標籤上 的詳細數據，預設會在 Windows 7 和更新版本中啟用此原則。 使用限制委派時發生此問題的間歇性發生，可能表示仲介層無法更新的過期票證存在。 這是連結的伺服器案例或任何持有登入會話超過 10 小時的應用程式的預期行為。 將仲介層伺服器上的委派設定從 [信任這部計算機] 變更為僅限指定的服務 - 僅使用 Kerberos 僅 信任此計算機來委派至指定的服務 - 使用任何通訊協定。 如需詳細資訊，請參閱 SQL Server 連結伺服器雙躍點 的間歇性匿名登入。 NTLM 對等登入 此錯誤與Microsoft Windows OS 所使用的NTLM驗證通訊協議有關。 在工作站或不信任彼此之網域的計算機之間進行通訊時，您可以在這兩部機器上設定相同的帳戶，並使用NTLM對等驗證NTLM對等登入。 只有在這兩部機器上的使用者帳戶和密碼都相符時，登入才能運作。 回送保護的設計目的是禁止應用程式在同一部計算機上呼叫其他服務。 您可以設定
DisableLoopbackCheck
或
BackConnectionHostNames
（慣用） 登錄機碼以允許此專案。 如需詳細資訊，請參閱
安裝 Windows Server 2003 Service Pack 1 之後，嘗試使用 FQDN 或其 CNAME 別名在本機存取伺服器時的錯誤訊息：拒絕存取或未接受指定網路路徑
的網路提供者。
Always-On 接聽程式回送保護
從主要節點連線到 Always-On 接聽程式時，聯機會是 NTLM。 這會與回送檢查互動，併產生「登入失敗」錯誤，指出使用者來自不受信任的網域。 若要解決此錯誤，請將接聽程式 NETBIOS 名稱和完整名稱輸入可用性
BackConnectionHostNames
群組中所有電腦的登錄機碼。 如需詳細資訊，請參閱
安裝 Windows Server 2003 Service Pack 1 之後，嘗試使用 FQDN 或其 CNAME 別名在本機存取伺服器時的錯誤訊息：拒絕存取或未接受指定網路路徑
的網路提供者。
LANMAN 相容性層級
這通常發生在舊版計算機（Windows 2008 之前）與較新的計算機之間。
將所有電腦上的 LANMAN 相容性層級設定為 5 。 這也不允許NTLM v1。 您也可以切換至 Kerberos 以避免發生此問題。 敏感性帳戶 某些帳戶可能會在 Active Directory 中標示為敏感性。 在雙躍點案例中，這些帳戶無法委派給另一個服務。 不是限制的目標 如果特定服務帳戶已啟用限制委派，如果目標伺服器的SPN不在限制委派的目標清單中，Kerberos 將會失敗。 Per-Service-SID 此功能會限制本機連線使用NTLM，而不是 Kerberos 作為驗證方法。 服務可以使用NTLM認證對另一部伺服器進行單一躍點，但若未使用限制委派，就無法進一步委派。 NTLM 和限制委派 如果目標是檔案共享，中介層服務帳戶的委派類型必須是 [限制-任何]，而不是 [限制-Kerberos]。
雙躍點通常牽涉到跨多部遠端計算機委派用戶認證。 例如，假設您有一 個名為 SQL1 的 SQL Server 實例，您可以在其中為名為 SQL2 的遠端 SQL Server 建立連結伺服器。 在連結的伺服器安全性組態中，您已選取 [使用登入目前的安全性內容 進行] 選項 。 使用此組態時，如果您從名為 Client1 的遠端用戶端電腦對 SQL1 執行連結的伺服器查詢，則 Windows 認證必須先從 Client1 躍點到 SQL1，再從 SQL1 跳到 SQL2 （因此稱為雙躍點）。 如需詳細資訊，請參閱 瞭解 Kerberos 雙躍點 和 Kerberos 限制委派概觀
使用者登入失敗（空白）
當使用者嘗試登入失敗時，就會發生此錯誤。 如果您的電腦未連線到網路，就可能發生此錯誤。 例如，您可能會收到類似下列錯誤訊息：
Source: NETLOGON
Date: 8/12/2012 8:22:16 PM
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <computer name>
Description: This computer was not able to set up a secure session with a domain controller in domain due to the following: The remote procedure call was cancelled.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.
空字串表示 SQL Server 嘗試將認證交給本地安全機構子系統服務 （LSASS），但因為發生問題而無法。 無法使用 LSASS，或無法連絡域控制器。
您也可以看到下列對應的 SSPI 錯誤碼：
SSPI 交握失敗，錯誤碼0x80090311與整合式安全性建立連線;線上已關閉。
SSPI 交握失敗，錯誤碼0x80090304建立與整合式安全性的連線;線上已關閉。
這些錯誤碼會轉譯如下：
錯誤 -2146893039 （0x80090311）：無法連絡授權單位進行驗證。
錯誤 -2146893052 （0x80090304）：無法連絡當地安全機構。
若要解決這些錯誤，您可以將冒犯DC離線， 或使用NLTEST.EXE 來切換DC。
- 若要查詢 DC，請執行 NLTEST /SC_QUERY:CONTOSO 命令。
- 若要變更 DC，請執行 NLTEST /SC_RESET:CONTOSO\DC03 命令。
如果您需要進一步的協助，請連絡 Microsoft Active Directory 小組。
檢查客戶端和伺服器上的事件記錄檔，以取得在失敗時間前後記錄的任何網路相關或 Active Directory 相關訊息。 如果您發現任何專案，請與您的網域系統管理員合作，以修正問題。
使用者 '（null）' 登入失敗
「Null」的指示可能表示 LSASS 無法使用 SQL Server 服務帳戶認證來解密安全性令牌。 此條件的主要原因是SPN與錯誤的帳戶相關聯。
若要修正此問題，請遵循下列步驟：
使用 SQLCheck 或Setspn.exe來診斷和修正 SPN 相關問題。
使用 SQLCheck 來檢查 SQL 服務帳戶是否信任委派。 如果輸出指出帳戶不信任委派，請與您的 Active Directory 系統管理員合作，以啟用帳戶的委派。
SETSPN -X和 -Q 是用來檢查重複或錯放 SPN 的實用命令。
診斷並修正功能變數名稱系統 （DNS） 名稱解析問題。 例如：
使用 PowerShell 命令本偵測 IP 位址：
ping -a <your_target_machine>-4（特別用於 IPv4 和 -6 IPv6）ping -a <your_remote_IPAddress>使用 NSLookup 多次輸入您的本機和遠端電腦名稱和 IP 位址。
在傳回的結果中尋找任何不一致和不相符之處。 網路上 DNS 設定的正確性對於成功的 SQL Server 連線很重要。 不正確的 DNS 專案可能會在稍後造成許多連線問題。
請確定防火牆或其他網路裝置不會封鎖用戶端連線到域控制器。 SPN 會儲存在Active Directory中。 如果客戶端無法與目錄通訊，連線將無法成功。
其他錯誤資訊
為了提高安全性，傳回給用戶端的錯誤訊息會刻意隱藏驗證錯誤的本質。 不過，在 SQL Server 錯誤記錄檔中，對應的錯誤包含對應至驗證失敗狀況的錯誤狀態。 比較錯誤狀態與下列清單，以判斷登入失敗的原因。
State
登入有效，但伺服器存取失敗。 此錯誤的其中一個可能原因是 Windows 使用者可以存取 SQL Server 作為本機系統管理員群組的成員，但 Windows 未提供系統管理員認證。 若要連線，請使用 [ 以系統管理員身分執行] 選項啟動連線程式，然後將 Windows 使用者新增至 SQL Server 作為特定登入。
登入是有效的登入，但伺服器存取失敗。
密碼必須變更。
38, 46
找不到使用者所要求的資料庫。
當 SQL Server 設定為僅使用 Windows 驗證時，客戶端會嘗試使用 SQL 驗證登入。 另一個原因是 SID 不相符。
102 - 111
Azure AD 失敗。
122 - 124
因為空的使用者名稱或密碼而失敗。
使用者所要求的資料庫不存在。
132 - 133
Azure AD 失敗。
其他錯誤狀態存在，並表示發生非預期的內部處理錯誤。
更罕見的可能原因
錯誤原因 嘗試使用 SQL 驗證登入失敗。伺服器僅針對 Windows 驗證 進行設定。在下列情況下可以傳回。
當伺服器設定為混合模式驗證，且 ODBC 連線使用 TCP 通訊協定，而且連線不會明確指定連接應該使用信任的連線。
當 SQL Server 設定為混合模式驗證時，ODBC 聯機會使用命名管道，而用來開啟命名管道的用戶端用來自動模擬使用者的認證，而 連接字串 不會明確指定使用受信任的驗證。
若要解決此問題，TRUSTED_CONNECTION = TRUE請在 連接字串 中包含 。
在此範例中，驗證錯誤狀態為8。 這表示密碼不正確。
使用 Windows 驗證模式安裝 SQL Server 時，稍後會變更為 SQL Server 和 Windows 驗證模式， 一開始會停用 sa 登入。 這會導致狀態 7 錯誤：「使用者 』sa' 登入失敗」。若要啟用 sa 登入，請參閱 變更伺服器驗證模式。
0420 一致驗證問題的原因
推荐文章