Environment: Windows Server 2012, 2 Domain Controllers, 1 domain.

  • A server called Sharepoint1 was joined to the domain (running Sharepoint 2013 using NTLM).
  • The fresh install for Sharepoint1 (OS and Sharepoint) is performed and set up for Kerberos and joined to the domain using the same name. Two SPNs added for HTTP/sharepoint1 and HTTP/sharepoint1.somedomain.net for account SPFarm.
  • Active Directory shows a single, non-duplicate computer account with a create date of the first server and a modify date of the second server creation.
  • A separate server also on the domain has the server added to All Servers in Server Manager. This server shows a local error in the events exactly like This from Technet (Kerberos error 4 - KRB_AP_ERR_MODIFIED).


Can someone help me understand if the problem is:

  • The computer account is still the old account and causing a Kerberos ticket mismatch (granted some housekeeping in AD might have prevented this)
  • (In my limited understanding of Kerberos and SPNs) that the SPFarm account used for the SPNs is somehow mismatched with HTTP calls made by the remote server management tools services in Windows Server 2012
  • Something completely different?

I am leaning towards the first one, since I tested the same SPNs on another server and it didn't seem to cause the same issue. If this is the case, can it be easily and safely repaired? Is there a proper way to either reset the account or better yet, delete and re-add the account? Although it sounds simple enough with some powershell or clicking around in AD Users and Computers, I am uncertain what impact this might have on an existing server, particularly one running SharePoint. What is the safest and simplest way to proceed?


1 Answer 1


The computer account is still the old account and causing a Kerberos ticket mismatch

The use who joined the second server had enough rights to modify the machine account. While the machine account is still the 'old account' it's been changed and won't work with the first server any longer.

What is the safest and simplest way to proceed?

I'm assuming this server isn't in production; I've fixed this before by just doing a disjoin/rejoin of the first server or whichever you'd like to keep. You can try an account reset as well but I've had better success completely rejoining. I can't recall if having the host disjoined will make SharePoint unhappy (it's been a while since I managed a SP host) but it should be fine. The second server with this name will also need to be disjoined and rejoined (with a new name).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.