It’s one of the most frustrating errors I’ve ever encountered. When you try to connect to a SQL Server using Windows Authentication, you can a “Cannot generate SSPI context” error. If you Google this, you’ll find the most common cause is that SQL cannot generate a Service Principle Name (SPN). This usually happens when SQL is running under the local system account, as that account does not have permissions to create SPNs. It can also happen when SQL is installed and set to use the local system account, but then is changed to run under a domain account at a later time. There’s a good post from Microsoft on how to troubleshoot this issue here.

But I ran into this problem and none of those steps worked. I verified the SPN was created. I could see in the SQL logs that the SPN was successfully created when the SQL service started and was successfully de-registered when it was stopped. I was using a domain account that was used on other SQL Servers, so I knew the account had the correct permissions. To make things even more puzzling, I was able to connect with Windows authentication a couple days before and now I couldn’t. Nothing had changed, to my knowledge.

So I looked to the online community for help. I posted on SQL Server Central and on Twitter with the #sqlhelp hash tag. After several suggestions, @Vickyharp said “It’s a long shot, but is the system clock correct?”

Nope, it wasn’t. The system clock was 7 hours behind the network clock. I corrected the time and my SSPI error went away!

I have no idea how the clock got changed or why it wasn’t synced up with network time. The server in question is a virtual machine, so that might have played some role in it.

This is something to keep in mind when troubleshooting this issue. I never saw this mentioned anywhere in my searching, so it’s easy to overlook.