none
"SSPI handshake failed with error code 0x8009030c ..."

    Question

  • Hi All,

    Below are the farm configuration.

    • 1 SQL server with SQL 2005 STD edition in windows 2003 server Std 64 bit.
    • 1 Application server and 1 WFE server with SharePoint 2007 Std edition in windows 2003 server STD 64 bit.
    • Configured with AD account and it has local admin rights on 3 servers.

    Issue:

    • Daily morning SQL server is reporting Event ID 17806 error. SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [ IP of Application and WFE servers].
    • During same time SQL server is logging 5788 and 5789 errors. 
    • 5788 error: Attempt to update HOST Service Principal Names (SPNs) of the computer object in Active Directory failed. The updated values were 'HOST/FQDN name of SQL Server' and 'HOST/SQL Server Name'. The following error occurred:
      There are no more endpoints available from the endpoint mapper. 
    • 5789 error: Attempt to update DNS Host Name of the computer object in Active Directory failed. The updated value was 'FQDN Name of SQL server'. The following error occurred:
      There are no more endpoints available from the endpoint mapper. 
    • At the same point Application and WFE servers are getting 27745 error for thousands of time in 2 minutes. As it is early morning we don't know how the sharepoint application is behaving (accessible are not).  From past 2days we are getting these errors. It is happening only for 2 min in the morning.
    • 27745 error : The description for Event ID ( 27745 ) in Source ( Windows SharePoint Services 3 ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: #50071: Unable to connect to the database WSS_Content_DB on SQL server.  Check the database connection information and make sure that the database server is running..

    To resolve this found few SPN queries, but didnt tried as it is production environment. Is this issue with SPN name of SQL server?

    how to stop this errors?

    --------------------------------

    Thanks & regards

    V235

     

    • Edited by Mike Walsh FIN Monday, December 27, 2010 8:34 AM Title far too long. Do not use entire error message as a title
    Tuesday, December 21, 2010 12:25 PM

Answers

All replies

  • We had this issue yesterday, its started around 5:25 and finished 5:26. But in our case it automatically fixed. in our case our whole farm went down for a min then came back after investigation we found its due to AD problem. AD server was not able to authenticate the windows account for a moment.

    we see bunch of unable to connect database.

     

    thanks

    -ws


    SharePoint administrator, MCTS,MCITP
    Tuesday, December 21, 2010 3:27 PM
  • Hi,

    Thanks to share your post in this forum.

    For the issue that you have encountered, if your local asp.net site is running under iis, then you need to set to
    run under a domain account with access the SQL server.

    1) If you only hit the website locally just set impersonate=true in the
    web config and require authentication to ntlm in iis.

    2) If your local box is vista or server2003 set the app pool for the
    asp.net site to the desired domain account.

    3) If none of above, in web.config set impersonate with a username and
    password.

    And some other useful references:

    http://www.associatedcontent.com/article/5725578/techtips_how_to_fix_the_error_sspi.html.

    http://msdn.microsoft.com/en-us/library/ms998320.aspx.

    http://www.bigresource.com/Tracker/Track-ms_sql-HDpysQ7v/.

    Hope this could help you!

    Leo

    • Marked as answer by Mike Walsh FIN Monday, December 27, 2010 8:35 AM
    Wednesday, December 22, 2010 8:40 AM
  • Hi ,

    In my case also, it fixed automatically. we got this for two days at 4:45AM to 4:46AM. Today there is no such errors.

    Are you able to get the information which caused this?

     

    ----------------------

    Thanks & Regards

    V235

    • Edited by Mike Walsh FIN Monday, December 27, 2010 8:34 AM Use English in posts. Do not text.
    Wednesday, December 22, 2010 8:41 AM
  • Hi,

    Thanks to follow up your post in this forum.

    For the issue, I think it may due to the communications with AD and also your server is not properly recognized. And some other reason may be your SQL server credentials error.

    Hope it helps!

    Leo

    Monday, December 27, 2010 8:26 AM

  • 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 09, 2014 8:43 AM
  • I know that this post is rather old but searching for event 17806 shows this as a top result.

    I feel that the primary concern with this event, as well as events 18452 and 18456, should be that of security.  For me, I stop doing everything until I can determine if this is a security issue or some other issue.  This should not take a long time to sort out.

    One company I worked with has the server hosted.  That server is out of state.  Smaller business saving costs, not discussing the pro/cons with that. This server had numerous 17806's and 18452's.

    The security risk should be eliminated first and foremost, does the client IP require access to perform their duties? Then moving on to other troubleshooting steps to resolve the issue.  Doing so will eliminate unnecessary work.

    For example, IPs 192... and 61... were used to access a SQL server and it was quickly determined they were a security threat/issue.  There were IPs that were included in the logs that were 'known good' IPs and had to be filtered out. For each IP, we had to ask 'Security Issue or not?'.

    Both of these IP were used in numerous attacks on that company's SQL server.  The first was determined to be located in California while the second was located in China.  The second was responsible for over 50 17806's and 18452's in a 10 minute window.  There were also an obscene amount of 18456's (like > 47K and thats only what we had access too).  This activity filled the log, which only had ~40 hours of log entries.

    thomas


    Thursday, January 23, 2014 8:23 PM