Okay, we have configured our MOSS site so that the users are able to authenticate with Kerberos.
But how do we know for sure that Kerberos was used and the authentication has not fallen back to NTLM? Here is what we can do with the right tools.

At first, we should install a tool which allows us to have a look on the traffic between the browser and the server. The tool I prefer is called Fiddler, you can download it from here: http://www.fiddlertool.com/Fiddler2/version.asp.
Just install it on a client machine and start it. It works as a proxy between the browser and the client, so you should take a client that reaches the MOSS server without another proxy. Then just open your browser and then your MOSS site. Fiddler should log the HTTP packets and you should get something like that:
 
In the screenshot we can see that NTLM was used and we have to find the reason why Kerberos was not used.

Very often the reason is a very simple one: duplicate SPNs.
Here is a way to export all existing SPNs of a domain:

ldifde -f c:spn_out.txt -d “DC=test,DC=local” -l serviceprincipalname -r “(serviceprincipalname=*)” -p subtree

In my test environment the Active Directory Domain was called test.local, you have to alter the command with your domain name.

Here is the output from the command:

Here is the generated text file:

As you can see, there are a lot of SPNs, even in a very small environment. This makes troubleshooting very difficult, especially in large environments.
What can we see in the screenshot above? The problem is, that the SPNs are sorted by security principals (computers, users) and not by services. In my example I intentionally created two SPNs for my MOSS site testapp.local.

Here is the screenshot with the highlited duplicate SPNs:

As you can see, the service HTTP/testapp.local is registered two times, for the user mossservice and the user sqlservice. When a user wants to authenticate to the MOSS site with Kerberos, he cannot know for which user he has to request a Kerberos ticket and Kerberos fails.

But there is an easier way to discover duplicate SPNs. When you are troubleshooting Kerberos authentication, you know the name of the service the user wants to connect to. In my case the MOSS site has the hostheader testapp.local and the service is HTTP/testapp.local.
Microsoft provides a script to discover duplicate SPNs. You can download the source here: http://support.microsoft.com/kb/929650. Just copy the sourcecode to a text file and rename it to SPNHelper.vbs. Then you can use this script with the following command:

cscript SPNHelper.vbs /f:duplicatespn /spn:HTTP/testapp.local

(Note that the help says the command should be cscript SPNHelper.vbs /f:duplicatespn /spn:HTTP:/testapp.local [the : after the HTTP in the SPN], but his is a typo!)

The script gives us this output:

Now we can be sure that Kerberos cannot work, because we have duplicate SPNs.
We have to delete the wrong SPN:

In my example, the application pool ID of the MOSS site is testmossservice, so testsqlservice was wrong.

Now we can make another authentication test with Fiddler, but at first we should delete the previously logged session for clarity:

After we open the MOSS site another time, Fiddler states that Kerberos was used:

That’s it!

Tags: Authenti- cation, Kerberos

This entry was posted on Friday, May 16th, 2008 at 10:36 am and is filed under SharePoint. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.