The target principal name is incorrect. Cannot generate SSPI context.

Today's problem occured after I restarted a Hyper-V based SharePoint 2013 farm (Windows Server 2012, one SharePoint 2013 machine, one SQL Server 2012 machine, one DC). I fired up Central Administration and was hit with the following error:

Unknown SQL Exception 0 occurred. Additional error information from SQL Server is included below.

The target principal name is incorrect. Cannot generate SSPI context.

After checking the obvious things - testing connectivity to the DB server, checking the SQL service was running, verifying permissions, etc - I initially figured this was an issue with my Hyper-V snapshots being out of sync, so I ran the SharePoint Products Configuration Wizard. This hit me with the following error:

Failed to detect if this server is joined to a server farm. Possible reasons for this failure could be that you no longer have appropriate permissions to the server farm, the database server hosting the server farm is unresponsive, the configuration database is inaccessible or this server has been removed from the server farm.

I attempted to rejoin the server farm to no avail, then I realised I was barking up the wrong tree. The initial error message suggests a Kerberos issue, while my farm is set up to use NTLM. After a lot of searching, this ancient forum thread pointed me in the right direction. In Active Directory, I opened the computer record for the DB server. In the attribute list, the servicePrincipalName attribute showed the following entries:



























Delete the two MSSQLSvc entries and then restart the database server. In most cases this should solve the problem. Without the SPNs, authentication falls back to NTLM as it should and the farm comes back to life.

Other users have reported that they also need to delete the RestrictedKrbHost entries. In a previous version of this post, I suggested deleting every entry - after all, if we're using NTLM, we shouldn't need any SPNs. However, if you delete all the entries you may find you have to remove and then re-add the database server to the domain.

I'm fairly certain that this issue arose when I added Analysis Services to the SQL Server instance on the database server. Other users have reported similar issues when adding Reporting Services and Integration Services to a SQL Server instance.

Comments

  1. I've just completed an install very similar to yours and found exactly the same problem. This post sorted my problem.

    ReplyDelete
  2. I just read this post and it helped me to determine that I had to remove the two Restricted service principal names as they restrict access to the local server.

    Thanks!!

    ReplyDelete
  3. Well, I got the exact same problem when adding SQLServer features (but it was SSIS or SSRS in my case)

    ReplyDelete
  4. Great goods from you, man. I’ve understand your stuff previous to and you’re just extremely magnificent.

    SharePoint 2013 Administrator Training

    ReplyDelete
  5. Excellent - you are life saver! Your link was second - googled displayed when I searched - and it took me 4 hrs to arrive to you link as I was trying other solutions. None of them worked and yours finally did. I installed Reporting services and changes from local users to domain user and got this problem. You saved my day.
    Many thanks
    Ven

    ReplyDelete
  6. Solved my problem too. Many thanks

    ReplyDelete
  7. THANK YOU SO MUCH!!! I'VE BEEN TROUBLESHOOTING THIS ISSUE FOR DAYS!!! THIS SAVED MY LIFE!!!

    ReplyDelete
  8. Spent so much time trying fix this. You are God. It's been 5 hours of constant TShooting. I'll pray to you every night from now on.

    ReplyDelete

Post a Comment

Popular posts from this blog

Server-side activities have been updated

Custom Workflow Activity for Creating a SharePoint Site