If you have installed CRM you might have been unluckily enough to come up against some SPN (Service Principal Name) problems.
SPN problems are usually difficult to resolve because it usually involves explaining to an IT department what SPN’s are and what they do and finally the changes that need to be made.
The changes usually have to be made on the Domain Controller which instantly makes the IT department very suspicious (although why they think you are going to sabotage a customers domain controller doesn’t make sense but then you could do it accidently)
So what are SPN’s, they are ways for helping Kerberos authentication when software is split over different servers.
For CRM they are very important because the standard installation involves CRM on seperate server and SQL and SSRS reporting services on at least one other server. This will mean that when a user’s credentials will need to be passed between servers and that is where Kerberos comes in.
Rather than actually passing credentials CRM will impersonate the user and it will be validated by Kerboros on the different servers.
So how do SPN’s come into play, well a Hosky explanation is when you set an SPN it is basically saying that Kerbero’s authentication is ok on/from this server.
So usually for the CRM server it has an SPN for the crm service account something like
and the for the CRM server
The reason I am writing this blog is because although I have tried to explain it but also so I can always find the link I am going to post below, it is without doubt the most comprehension explanation with instructions I have found on the internet.
It also has lots of other links on how to troubleshoot spn problems. I would also recommend the article above for people installing the Dynamic Connector because when I have installed that I have run into quite a few SPN problems and the Dynamic Connector has zero help with it and no forum!!!