SSPI handshake error 0x8009030c

Question

SSPI handshake error 0x8009030c

Edwin Frydendall

SSCrazy

Points: 2361
More actions
December 3, 2007 at 10:35 am

#184519

We are getting an error in the SQL logs:
"SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: 192.168.xxx.xxx]" (not revealing the last two parts of the IP for security)
This is always immediately followed by:
"Login failed for user ''. The user is not associated with a trusted SQL Server connection. [CLIENT: 192.168.xxx.xxx]"
The first error is a Fatal error. There are no other SQL Log errors that show up with these two errors. We use Windows Authentication. We also use Active Directory.
Shouldn't a login attempt with a blank user just be a failed login? Why would it produce a fatal error?

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply

vonHarry Ten Centuries Points: 1206 More actions · Answer 1

Hi,

This is normally related to not having the correct permissions for the AD account on the SQL Server or attempting to login with the wrong account.

Check this kb article: http://support.microsoft.com/kb/889615

HTH!

NathanM

Chandra Sekhara Vyas Dhara SSChampion Points: 10207 More actions · Answer 2

Refer Following Link

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=285649&SiteID=1

@SQLApprentice SSC Eights! Points: 950 More actions · Answer 3

I am getting similar error, were you able to resolve your issue, and if so what steps did you take?

DESCRIPTION:SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed.

We are using:

Windows Server 2003

SQL Server 2005 SP3 Standard Ed.

We received this error when user was using SSMS to connect to remote SQL Server using SQL Authentication. Server and User are in different domains.

Server is configured for Mix Mode Authentication. This was a one-time error. Same user is able to connect to SQL Server in similar fashion, using same login and pwd. We have not made any configuration changes, but user is able to connect with out any errors.

I read this MSDN blog http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/thread/db3d8038-4c3b-4daa-b5c9-b1486fe1d3c5/# , but it didn't help.

Anyone who has experienced and resolved this issue, please respond ASAP!!

cvsayani Valued Member Points: 53 More actions · Answer 4

Check out this link:

http://sqlforums.windowsitpro.com/web/forum/messageview.aspx?catid=60&threadid=84680&highlight_key=y&keyword1=sspi

@SQLApprentice SSC Eights! Points: 950 More actions · Answer 5

Thanks for the link. I haven't fixed my error yet, but the link provides some insights. My errors occur on a random basis, so its not a top priority at this point. I will post after i resolved these errors.

Thanks to all who contributed!:-)

Eoin The Forge SSCrazy Points: 2932 More actions · Answer 6

Login Errors

Since beginning to use WA we have had the following errors

1. Cannot generate SSPI context. (.Net SqlClient Data Provider)

2. Login Failed for user '', the user is not associated with a trusted SQL Server connection

Workarounds are to

1. Use FQDN for '' user error i.e. Using servername.domain.com,1433 instead of servername

2. IP address for ''SSPI context'' error i.e 10.99.99.98 instead of servername

3. ALIAS for ''SSPI context'' error i.e Add alias in Microsoft SQL Server 2005/Configuration tools/ SQL Server Configuration manager e.g

4. For '' user error: flush out cached credentials: run>control userpasswords2>advanced>manage passwords>remove all

Other Microsoft fixes listed below

•Make sure that the clocks are synchronized across the domain.

You can manually synchronize a computer with the time on the domain,

Click Start, and then click Run.

Type net time /domain /set, and then click OK.

•Credential Cache( is used by Kerberos to store authentication information, namely the TGT and session ticked is cached so that can be used during their lifetime.)

The most general workaround is: clean up credential cache by using "klist.exe -purge" or kerbtray.exe or just reboot machine.

•SSPI uses a file named Security.dll. If any other application installs a file with this name, the other file may be used instead of the actual SSPI file. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

REF:1.…. http://support.microsoft.com/?id=811889

James L Kerr Right there with Babe Points: 760 More actions · Answer 7

Just to add my personal experience to this thread ...

We have a user application that uses Current Security Context to login to SQL Server (believe me, not my choice, I don't want to have 4,000 PCs logging on and off SQL Server every 30 seconds for this application, but our developers for that project cannot seem to figure out how to write a "middle-tier," so they made a thick-client).

Well, on Friday last week, an employee was logged in, using his terminal and that piece of software, and he was asked to step away from his desk (he was being released), and he just locked his computer. HR did the required Exit Interview, but left his computer alone, still running, locked with him logged in. This software continued to attempt logins through the entire weekend, producing hundreds of Severity 20 "SSPI Handshake failed with error code 0x8009030c" and Severity 14 "Login failed for user ''."

We knew what machine was the issue from the IP address, so one of my Desktop Support Team members logged in and saw the machine was still locked. Once we logged the person off and restarted the PC, everything was fine.

So, in short ...

In the SQL Server Logs, if you see Login Failed/SSPI handshake failed ... take the IP address

Open Command Prompt --> nbtstat -a 192.168.111.111 (replace with proper IP)

This will tell you the machine AND the domain user that is logged in.

From there, I checked that the user was both valid and locked (in our case, we have an employee management system that I searched in order to tell the the user had been terminated).

Or, in really really really short order ...

Reboot the machine with the IP address in the errors ... standard tech support first request, "Have you rebooted the machine in question yet?"

Rick.Cornell.SME SSCrazy Eights Points: 8597 More actions · Answer 8

Have your Domain Admin do a SETSPN for your MSSQLServ!!!:hehe:

James L Kerr Right there with Babe Points: 760 More actions · Answer 9

Actually ... we already had SETSPN done a long time ago. I verify that Kerberos Authentication is being used every time I spin up a new server or instance as part of my initial configuration checklist. But thanks for chiming in.

What happened is that the people that wrote the thick client decided that using Windows Authentication was the best thing since sliced bread ... they should have been using a middle-tier and a service account. So, when we terminated the employee and deactivated his Domain Account, since he was logged in to the computer with the system locked, the application just continued to attempt connecting to the database ... every 30 seconds. They should not have written this code in such a manner.