Maybe you’ve already heard of SPNs, also known as Service Principal Names. Most CRM technical people have heard of them, but not many can really explain WHY they are necessary. Some can say it is for ensuring “mutual authentication”, but few can really explain how this mechanism works.
Today, let me explain to you my understanding of SPN’s, based on this article.
The Kerberos mechanism by which a client authenticates a service works as follows:
- When a service is installed, a service installer, running with administrator privileges, registers one or more unique SPNs for each service instance.
- The names are registered in the Active Directory Domain Controller (DC) on the user or computer account object that the service instance will use to log on.
- When a client requests a connection to a service, it composes an SPN for a service instance, using known data or data provided by the user.
- The client then uses the SSPI negotiate package to present the SPN to the Key Distribution Center (KDC) for the client domain account.
- The KDC searches the forest for a user or computer account on which that SPN is registered.
- If the SPN is registered on more than one account, the authentication fails.
- Otherwise, the KDC encrypts a message using the password of the account on which the SPN was registered.
- The KDC passes this encrypted message to the client, which in turn passes it to the service instance.
- The service uses the SSPI negotiate package to decrypt the message, which it passes back to the client and on to the client’s KDC.
- The KDC authenticates the service if the decrypted message matches its original message.
Let me rephrase this in the CRM world:
- When CRM is installed, SPNs are registered for the identity of the application pool CRMAppPool. It can be Network Service or some other account.
- That’s why, when changing the identity of the application pool, you need to remove existing SPNs and create new ones.
- When a client requests a connection to CRM, it composes an SPN for it.
- That’s why you need to register SPNs for both server the server name and the FQDN, because you can’t be sure how the SPN will be composed by the client.
- (1) The client presents the SPN to the KDC for the client domain account
- (2) The KDC searches the domain for a user or computer account on which that SPN is registered
- Here, the KDC must find the identity of the CRMAppPool
- If the SPN is registered on more than one account, the authentication will fail
- Indeed, because the KDC will not know which account to use
- The KDC encrypts a message with the password of the CRMAppPool identity
- (3 & 4) The KDC passes the message to the client, which passes it to the service instance, ie to the CRM server
- (5 & 6) The CRM server can decrypt the message, passes it back to the client which passes it back to the KDC
So that’s why we talk about mutual authentication: not only is the client identified (this aspect is not described here), but also the service.