{Quick Tip}Understanding SPN (Service Principal Name) for Dynamics CRM on premise and why it is required?

The reason for writing this blog is to make the audience understand why SPN is very important for a multi-box CRM on –premise installation.

Let’s first start from an error

Have you ever been on this screen on On-Premise CRM reports?

Experienced CRM consultants call it the dreadful CRM reporting error and there are variety of blogs which tell you the ways to solve this one.

This is one of the best documented ones: http://blog.simpletrees.com/2013/04/mscrm-and-dreaded-rsprocessingaborted.html

So, if you want the solution to the problem, you can stop here and refer the link mentioned above.

I wanted to go a bit ahead than that and mention why CRM administrators and consultants face this error?

9 out of 10 times this error is due to incorrect SPN configuration.

Well let me start by trying to put it in very simple fashion for Technical audience:

Put simply, an SPN (Service Principal Name) mapping allows a service on a particular server to be associated with an account responsible for the management of the service, thereby permitting mutual Kerberos Authentication. To use mutual Kerberos authentication, the Windows security layer must be able to determine the account that a service is using.

With an SPN map defined in Active Directory (AD), the Windows account responsible for the service can be ascertained and used for Kerberos authentication. This mapping is necessary because many clients will compose an SPN based on the hostname and port the client is connecting to. Many services register SPNs for this reason.

Didn’t understand this jargons spoken above?

Ok, let’s try to make it a little more understandable for the rest of us now in normal language.

CRM can have a database server separate to the Application Server (where IIS is hosted). For security purposes, it is advisable to run CRM as a service account which is also existed on Domain.

Similarly, it is advisable to run SQL server on the Database server in a separate service account on domain.

So, when SPN is not configured Application server is not able to authenticate SQL server as both are running under different accounts.

SPN creates a mapping so that Authentication can happen and thus reports start working most times after this is configured correctly.

Hope it helps and Happy CRMing!

Please do leave comments to share feedback and do share on your social networks.