Here are some quick tips to check if you are having problems with MS CRM 4.0.
1) Verify the
website identifier number in the registry as well as the Kerberos
authentication.
2) Check permissions: Network Service (check account selected in the Application Pool) and IIS_WPG.
3) Download Windows Support Tools for Windows 2003 Server (Windows Resource Kit) and verify the Service Principal Names
(SPNs).
Here is some additional reading about SPNs:
Validating & Creating SPN’s
Only a domain administrator will be able to view and create SPN’s.
There are multiple ways to manage SPN’s, and I will be showing examples
using the setspn.exe (Setspn.exe Download).
This simple command line tool can be installed on any machine in the
domain, but you will need to execute as a domain administrator.
For example, you can list all SPN’s for a computer account by using the following:
setspn -l computer
In the sample scenario above, you would use the following to list all SPN’s for the web server:
setspn -l crmserver
To create a new SPN for the HTTP service, you would use the following syntax:
setspn -a http/<name> <server netbios name> (if the identity is running under the computer account)
setspn -a http/<name> <domainname> (if the identity is running under a domain account)
When creating a new SPN for our CRM web server, you will need to
first determine the account running IIS by reviewing the identity of
the Application Pool (IIS 6.0). If that account is local system or
network service, then it is running under the computer account. You
would also need to determine the name your clients will access this
service.
In our sample scenario, you would need to do the following:
setspn -a http/crmserver crmserver
setspn -a http/crmserver.domain.local crmserver
setspn -a http/crmalias crmserver
Note, if your service is running under a domain account, then you will need to specify that account in your setspn -a statement:
setspn -a http/crmserver.domain.local domainuser
You will also need an SPN for the SQL service (usually this is
created automatically when you install SQL Server). The usual reason
this is configured incorrectly is when the account that is running SQL
Server changes after installation. If you do need to create a new SPN
for the SQL service, use something similar to:
setspn -a mssqlsvc/database.domain.local domainuser
If you want to read additional articles, here are some good ones: