0

I was getting the following error every 4 minutes on the same sql server:

SSPI handshake failed with error code 0x8009030c, 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. The logon attempt failed [CLIENT: ipAddress here]

All the googling I do points towards being unable to connect when running something, but that's not quite my problem...

The errors were coming from the same ip address every time, which I tracked down to one of our developers. They have permission to log onto that server, and had been successfully running queries on it earlier, through sql server management studio.

We looked at what they had running, and decided to shut down one application at a time until the errors stopped. We did Visual Studio first, and got another error soon after. Then we closed all instances of sql server management studio, and the errors stopped.

Why was SSMS repeatedly (every 3-4 minutes) trying to connect to this server, and why would it have been failing, when all queries were run with a valid login? Is there a way to prevent this happening in future?

  • I usually see this when a domain account's password has expired. There's no reason that SSMS would be constantly trying to reconnect unless there's something running that's causing it to try reconnecting. – David Fowler Jan 4 '18 at 10:54
  • The password hasn't expired :( – BeanFrog Jan 4 '18 at 10:56
0

Possibly the developer is using a 3rd-party tool that provides a plug-in for SQL Server Management Studio. The 3rd party plug-in is started with SQL Server Management Studio and is trying to connect to the SQL Server using the credentials the process was initially started with.

If the initial process owner of the 3rd-party tool is running with an un-privileged account that does not have access to he SQL Server instance the developer is connecting to, then you will possibly see multiple error messages in the ERRORLOG file and in the Windows Event Log on the target server (see Link below for examples).

If the initial process owner of the 3rd-party tool is not allowed to delegate permissions on its own object, then you might see the SSPI Handshake error.

There is a Microsoft Blog article titled Common ‘SSPI handshake failed’ errors and troubleshooting which provides you with some ideas on how to find the main cause.

Most of the SSPI Handshake erros are because a process can not handover/delegate the permissions during the SSPI Handshake to another user/process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.