Troubleshooting CRM, Kerberos, and the Error 401.1 – Unauthorized: Access is denied
Posted on January 23, 2009 by Dan Blake
You install Microsoft Dynamics CRM 4.0 and follow the instructions to the best of your ability only to find that when you try to access the CRM web site, it prompts you for a password three times then you get the message:
You are not authorized to view this page.
HTTP Error 401.1 – Unauthorized: Access is denied due to invalid credentials.
This has got to be the #1 most common error people run into when installing Microsoft Dynamics CRM 4.0. In all of the production, testing, and development environments I have set up, the 401.1 error is the one I have spent the most time troubleshooting. It is ALWAYS caused by a problem with Kerberos and double-hop authentication. The trouble is that there are SO MANY ways you can break Kerberos. Over the weekend, I went through another marathon troubleshooting session to resolve yet another Kerberos issue. This time it was in our Sandbox (testing) hosting environment. It came down to an incorrect SPN this time.
Service Principal Names (SPNs) and Delegation
For Kerberos double-hop authentication to work, you must have the proper SPNs configured and you must configure delegation for the computer account or service account that the service runs under. For CRM, this is the identity that your CRM web site’s application pool uses.
The SPNs you need to configure for Kerberos double-hop authentication to work properly are set up as follows:
setspn –A HTTP/servername:5555 domain\serviceusername_or_computername
setspn –A HTTP/servername.company.com domain\serviceusername_or_computername
If you configure the application pool to use an AD user account (service account) as its identity, you should use the name of that account in the above configuration. If you use Network Service, you should use the computer name (and you won’t need to prefix it with domain\). These commands add an SPN in Active Directory. You can also use ADSIEdit to configure this. Note that you need to use the port number for the short (NetBIOS) name version of the SPN but NOT for the FQDN version. This one got me recently.
Next, you need to allow delegation for the computer or service account using ADUC.
Incorrect or Missing SPN
You need to make sure that you have the correct SPN configured. Use setspn -L “computer_or_account_name” to list all SPNs for the service account and computer accounts.
Ex:
setspn -L CRMSERVERNAME
setspn -L Domain\service_account_name
In a recent troubleshooting experience, I had the port number added to the FQDN SPN and I got the following misleading error in the event log:
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 1/20/2009
Time: 1:55:03 PM
User: N/A
Computer: ONCCRM01
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/crmdiscoveryserver.domain.net. The target name used was HTTP/crmdiscoveryserver.domain.net. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (MSCRMHOST.NET), and the client realm. Please contact your system administrator.
For more information, see Help and Support Center at
All of the info I found while searching indicated that the problem was due to the next issue, Duplicate SPNs, when in reality, it was because Kerberos was looking for an SPN without the TCP port and I had configured it with the TCP port.
Duplicate SPNs
Duplicate SPNs can be difficult to resolve if you don’t know how.
Knowledgebase Article Windows 2000 Server Prompts Domain User for Credentials describes how to use LDP and Adsiedit.msc to troubleshoot and fix a duplicate SPN problem. When you run LDP, make your search string http/* to return all SPNs configured for web sites. You can narrow that down further to http/computername* if the former string yields too many results. Do the same for host/* and MSSQLServer/* just in case.
Event ID 11 — Service Principal Name Configuration
Note the important comment that the “setspn -X” option is only available in Windows Server 2008, not 2003. If you have Server 2008, this is much simpler than using LDP which can be daunting to those unfamiliar with AD and LDAP.
“Negotiate,NTLM” not configured on the web site and/or virtual directories
Your web site must have Negotiate/NTLM configured or the client and server will not negotiate Kerberos. This is the default setting but any number of things can change this configuration. The following article discusses how to configure this parameter using adsutil. I prefer to use the Metabase Explorer in the IIS Resource kit because it lets me see all of the configuration parameters and edit them directly. Either way will work.
Error message when you try to access the Microsoft Dynamics CRM Web site: “You are not authorized to view this page”
Keepalives not enabled on the CRM web site
Keepalives are turned on by default in IIS. If they are turned off, Kerberos will break. This is the most difficult issue I have ever had to troubleshoot related to the 401.1 error in CRM. I don’t know how it got turned off but the only thing that led me to the fix was to analyze the traffic with Netmon then use IIS Diagnostics to troubleshoot Kerberos. Use Metabase Explorer or adsutil to examine and change the keepalive setting.
