Implementing List Web Part for Microsoft Dynamics CRM 4.0 on your SharePoint Intranet

Recently, I started my project of rebuilding my company’s Intranet on the Windows SharePoint Service 3.0 platform.  Since I also manage my company’s MS CRM system, and I know Microsoft has released a List Web Part for CRM 4.0, so it was a natural decision to integrate CRM with SharePoint.  First of all, I started out my work following instructions from these posts on MS CRM Team blog:

• List Web Part for Microsoft Dynamics CRM 4.0 Deployment Scenarios
• Trust for Delegation in List Web Part for Microsoft Dynamics CRM 4.0

The List Web Part installation was very easy, and no error occurred.  Then I went on to configure Kerberos authentication on all the IIS servers, and configured trust for delegation for all involved servers.  And when I was ready to test and added the List Web Part to a test page, I faced the same famous Log In prompt window like a lot of others do. 

I went over the following checklist provided by one of commentators on the blog post over and over again, and yet still clueless of what went wrong.

• Create NetBIOS SPN’s for all servers in the farm
• Create FQDN SPN’s for all servers in the farm
• Create CNAME SPN for intranet site (if you have MOSS you're likely to have mysites etc as well)
• Set up trust for delegation (Kerberos, trust any) on each server in the farm
• Set up trust for delegation (Kerberos, trust any) on each service account in the farm (including the SQL service account)
• Switching authentication methods using a script to use both NTLM and Kerberos
• Switching authentication methods in the SP central admin GUI/site using Kerberos (only).

So I left it alone for a few days.  And last week, I went back and revisited the issue.  Then all of a sudden, I realized one difference in my topology set up comparing to the others.  Due to limited hardware resource, I had the SharePoint Central Administration site on the same server as the SharePoint Intranet application, yet on different ports.  The SharePoint Central Administration site used a domain user account on one port number, and the Intranet application used the default Network Service account on another port number, so I should have defined separate SPN for each.  And then I did.  This time, the List Web Part is working fine, but then I got “Access Denied” error when I tried to access the SharePoint Central Administration site from my workstation. 

And after searching on Google, I dig up an article that described how IE 6.0 and later versions of IE ignores port number on Kerberos authentication, thus causing a “Duplicate SPN” error.  Once identified the cause of the problem, I followed the steps in this post to apply registry changes on my machine.  Wah-lah !  Everything is now working fine on my machine, both the web part page and the administration site.  I sure learned a lot about Kerberos authentication through this exercise.