SSPI handshake failed with error code 0x80090304
-
Friday, January 27, 2012 10:56 PM
Hi,
I've seen the following errors on two different SQL Server 2008 R2 Express systems recently:
2012-01-25 16:56:29.49 Logon Error: 17806, Severity: 20, State: 14.
2012-01-25 16:56:29.49 Logon SSPI handshake failed with error code 0x80090304, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. [CLIENT: <local machine>].
2012-01-25 16:56:29.53 Logon Error: 18452, Severity: 14, State: 1.
2012-01-25 16:56:29.53 Logon Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: <local machine>]System Configuration is as follows: Both machines are workgroup members. SQL Server is running under localsystem. User is logged into a local account. Protocol is shared memory. Clients are connecting via System.Data.SqlClient.SqlConnection. Authentication is NTLM.
Does anyone know what could be causing these infrequent failures?
All Replies
-
Saturday, January 28, 2012 4:30 PM
Hello,
I've had this issue arise when the server could not contact any of the domain controllers. Verify that the server can contact the domain controllers through the same interface that SQL Server is listening on.
Edit: Double check to make sure your DNS entries are correct as well not being able to resolve the DC correctly could be a symptom of bad DNS records.
-Sean
- Edited by Sean GallardyMicrosoft Community Contributor Saturday, January 28, 2012 6:25 PM
-
Saturday, January 28, 2012 7:28 PM
Hi,
Systems are not domain members. Does the domain controller still apply in this case? Is there anyway to configure windows or sql server to ignore the domain controller?
Dean
-
Saturday, January 28, 2012 10:33 PMModerator
If clients are not domain members, consider using SQL authentication instead.
Dan Guzman, SQL Server MVP, http://weblogs.sqlteam.com/dang/- Proposed As Answer by Peja TaoModerator Monday, January 30, 2012 5:46 AM
-
Saturday, January 28, 2012 11:04 PM
But Dean0314 says protocol are Shared Memory, so the clients are local to the machine. When Windows Auth does not work on a local connection, it's not fun anymore. Particularly when we are talking about a workgroup, so there is no AD that can pull our legs.
Sorry, I have no idea of what is going on.
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se -
Saturday, January 28, 2012 11:35 PM
But Dean0314 says protocol are Shared Memory, so the clients are local to the machine. When Windows Auth does not work on a local connection, it's not fun anymore. Particularly when we are talking about a workgroup, so there is no AD that can pull our legs.
Sorry, I have no idea of what is going on.
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
You are correct, I did not read the last part of his post correctly.Dean, if this is code you are writing could you share with us the connection object code you are using?
When you say 'logged in with a local account' are you talking about an account such as public or an actual account in the users group that is a local login for windows?
-
Monday, January 30, 2012 2:55 PM
Hi,
The connection code is basically:
String connectionString = @"
Data Source=localhost\SQLEXPRESS;Initial Catalog=MyDb;Trusted_Connection=Yes";
SqlConnection con = new SqlConnection(connectionString);
con.Open();
The local accunt in this case is Administrator.
Dean
-
Wednesday, July 11, 2012 3:17 PMHave any of you found a solution to this? We are experiencing the same issue during a scripted SharePoint install.
-
Wednesday, July 11, 2012 6:20 PMWe never found a root cause. We did turn of auto_close on our databases for a different issue. We have not seen the issue since.

