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

  • 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

    Friday, June 22, 2012 3:13 PM

Answers

  • 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.


    • Edited by Don_Don Friday, June 22, 2012 4:44 PM grammar
    • Marked as answer by Iric WenModerator Saturday, June 30, 2012 2:23 PM
    • Unmarked as answer by Iric WenModerator Saturday, June 30, 2012 2:23 PM
    • Marked as answer by jakkampudi Thursday, July 12, 2012 4:11 AM
    Friday, June 22, 2012 4:31 PM

All replies

  • 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

    Friday, June 22, 2012 3:37 PM
  • 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

    Friday, June 22, 2012 3:49 PM
  • 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.


    • Edited by Don_Don Friday, June 22, 2012 4:44 PM grammar
    • Marked as answer by Iric WenModerator Saturday, June 30, 2012 2:23 PM
    • Unmarked as answer by Iric WenModerator Saturday, June 30, 2012 2:23 PM
    • Marked as answer by jakkampudi Thursday, July 12, 2012 4:11 AM
    Friday, June 22, 2012 4:31 PM
  • 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

    Thursday, January 9, 2014 8:40 AM
    Moderator
  • 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.
    Monday, November 3, 2014 12:21 PM
  • 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.

    • Proposed as answer by jarrodwee Tuesday, October 2, 2018 2:11 AM
    • Unproposed as answer by jarrodwee Tuesday, October 2, 2018 2:11 AM
    Monday, January 26, 2015 4:20 PM
  • 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

    Monday, March 14, 2016 8:53 PM
  • 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.
    • Edited by kentda Friday, April 1, 2016 10:49 PM
    Friday, April 1, 2016 10:49 PM
  • 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.
    Thursday, June 1, 2017 1:53 PM
  • 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.

    Wednesday, April 11, 2018 3:35 PM