SSPI handshake failed with error code 0x8009030c.[CLIENT: <named pipe>].

Question

Found below alerts in SQL log. And it got stop automatically stopped. How can I find from this connection was established and what may be causes. the same error was logged in Event VWR too 

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.  [CLIENT: <named pipe>].

---

ramakrishna

Answer 1

This can happen when the SPNs for the service account have not been created in Active Directory.  Have a look at this link for more information:

http://technet.microsoft.com/en-us/library/bb735885.aspx

Answer 2

Thanks for the reply.. But alert was stopped automatlically, with out performing any anyaction. now how do we find RCA for this error.. thanks..

---

ramakrishna

Answer 3

The alert will show up periodically, and may have different error codes associated with it.  So far, for the half dozen or so SSPI errors I've come across (not nearly as much as some folk), they've been traced back to either a missing SPN, or an incorrectly configured SPN. 

Apologies I'm not much more help.

Answer 4

Follow  the steps mentioned in http://mssqlwiki.com/2013/12/09/sql-server-connectivity-kerberos-authentication-and-sql-server-spn-service-principal-name-for-sql-server/

you should be able to crack the issue.

---

Thank you,

Karthick P.K |My blogs|My Scribbles|Twitter|My Facebook Group|

www.Mssqlwiki.com

Please click the Mark as answer button and vote as helpful if this reply solves your problem

Answer 5

I came across the error "SSPI handshake failed with error code 0x80090311" in my SAP environment. There was a physical firewall between App servers and Domain Controllers. I got it once i shutdown all Windows 2003 DCs. The resolution was to allow  higher RPC dynamic port range for Windows 2008 R2 DCs on the FW.

Answer 6

I know this is an old thread, under T-SQL, but I recently had the same message so I am offering this.  I feel it is appropriate because this thread was one of the first that showed up in my search engine.

Every minute, exactly one minute apart, I was getting "SSPI handshake failed with error code 0x8009030c, state 14...".  I knew why it was failing, but not what was causing it to fail.  Here were the circumstances:

•   We set up a server
•   Installed SQL 2008R2, including Reporting Services.
•   After testing we:  renamed the server, used T-SQL to change %%SERVERNAME.
  

Renaming the server was obviously the problem, but we thought it was failing to update the underlying data.  The solution was so simple I missed it, as other forum advice was more focused on going "in the weeds" of SQL. 

I had to use the reporting services configuration manager to change the server name there, too.  After reconfiguring, the "SSPI handshake" error stopped completely.

Answer 7

And more info for an old post....  We get a spurt of these from a server once in a great while.  We use the service SID for the service account.  I think the source is a combination of a lack of a SPN, the domain's automatic update of the machine account password, and the time required for domain replication.  Just a guess.  

---

Randy in Marin

Answer 8

How can this be an answer... Its not just an error. When it happens people cannot log on or use the tfs server. And it it cannot be a missing SPN or it would never work. It works 90% of the time.

Answer 9

You're absolutely correct.  I'm running into this now and it appears as though we're running out of available RPC ports.  We've expanded from about 1000 to 16384 and it runs for about 2 days before running out.  I suspect this is an application bug chewing up all of the available ports.

Answer 10

In my case I moved the SQL server to a different active directory domain.  To resolve the above error I went into SQL Server 2016 Reporting Services Configuration Manager, attached to the instance, on the left side selected "Database", on the right side selected "Change Database", Selected "Choose an existing report server database", and selected the original report server database using the new domain credentials.  This resolved my problem.