I was reminded of something today as I was helping a custom reconfigure a utility I wrote that was moved to a new server.
When you are using the CRM web services an specifying the server's name, you must use the actual name of the server.
If you attempt to access the web service by using the server's DNS address ( if it is different than the server's physical address ). For example, here is how you would correctly access a CRM server using the web service:
Server Name: crmserver
Web Service Address: http://crmserver:5555/MSCRMServices
If, the server happens to have a DNS address of CRM, you could access the server using a web browser using the following URL:
However, attempting to access the CRM web services using:
will fail with an 401: unauthorized error.
Loading ...
I bet this is a Kerberos SPN issue. We access CRM webservices using the full DNS name just fine. When you say http://crm, it is translated behind the scenes to http://crm.domain.com. The web server fires back a Kerberos authentication request, at which point your client asks the domain controller for a ticket for crm.domain.com. The domain controller generates and encrypts the ticket with the password of the service account that is running the IIS app pool under crm.domain.com, and sends it back to you. That way, only crm.domain.com can decrypt your credentials (because only it knows its own password). This prevents you from unknowingly sending your credentials to a rogue server impersonating crm.domain.com – because it would have to decrypt your ticket, which would mean it would have to know the service account's password. You then send this ticket to crm.domain.com to successfully authenticate.
How does the domain controller know which service account is running the IIS app pool for crm.domain.com, and therefore, which password to use to encrypt the ticket? The almighty SPN. Google it to find more about how to set one up, or ask your friendly domain administrator. If the SPNs aren't set up correctly, the Kerberos ticket your machine gets back won't authenticate when you send it to crm.domain.com.
So – why are you getting 401 unauthorized on http://crm but not when you use the actual machine name? Because your CRM installation is most likely using the default NETWORK SERVICE to run the IIS app pool. NETWORK SERVICE is actually the local computer account in your domain, and an SPN is automatically created for that computer account when it joins the domain, so Kerberos authentication happens automatically.
Or, it might be something else… :)
Thanks Josh. Interesting info and observations.
I'll pass these along.
Thanks again for sharing.
Mitch