Tag Archives: Kerberos

Duplicate SPNs and Windows Server 2008

Recently I got a comment how to locate duplicate SPNs when using Windows Server 2008.

Luckily, this is very easy, because the SETSPN command from Windows Server 2008 has this functionality builtin:

Remove the duplicate service prinicipal name

Each service principal name (SPN) must be unique. Without unique principal names, the Kerberos client is not able to ensure that the server it is communicating with is the correct one. You must identify the duplicate SPN, and then remove it.

To perform these procedures, you must be a member of the Domain Admins group, or you must have been delegated the appropriate authority.

To identify the duplicate SPN:

1. Log on to the computer referenced in the event log message. If this computer is not running Windows Server 2008, you must download and install the Windows Server 2003 Resource Kit, which includes setspn.exe.
2. Click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
3. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
4. Type setspn -X.
5. The output of this command will show the duplicate SPNs.
6. Use the following procedure to remove one of the duplicate SPNs.

Remove an SPN

To remove an SPN:

1. Click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
3. Type setspn -D<SPN> <computer_name>, where SPN is the name of the duplicate SPN and computer_name is the name of the computer that is assigned the duplicate SPN.

Want to test and troubleshoot Kerberos authentication to your MOSS site?

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:
 1 - Fiddler-NTLM
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:
2 - ldifde

Here is the generated text file:
3 - ldifde2

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:
3 - ldifde2

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:
4 - SPNhelper-Duplicate-SPN

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

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:
6 - fiddler-cleanup

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

That’s it!

Want to authenticate with Kerberos? (on your MOSS site)

When you create a new web application on your MOSS 2007 server, you have to make a tough choice: NTLM or Kerberos.
The differences for the user are not visible, but we have to make a few settings to make Kerberos work.

The easy settings are done with the Central Admin of MOSS:
Just enable Kerberos in the Authentication Provider of the desired Web Application.

That was the easy one.

Another thing we have to do is to set a “Server Principle Name”(SPN). A SPN is needed, because the user who wants to authenticate with Kerberos needs to know the account under which the Application Pool is running (Application Pool ID). The authenticating user needs this information, because he needs to ask the Kerberos Key Distribution Center (KDC) for a ticket for this account.
Naturally, we provide this information with a directory service. You have three guesses what directory service we will use.

The tool for registering SPNs is called SETSPN and it is installed with the Support Tools.

Here is an example:

Application Pool ID:

The application pool ID in my example is the user MOSSSERVICE in the domain TEST.LOCAL (TEST).

URL (Hostheader) of the application:
This is what your users enter into the address bar of their browser.

So we have:

Application Pool ID Hostheader:
testmossservice testapp.local

That gives us this SETSPN command:
setspn -a http/testapp.local testmossservice

That’s it.

Yes, really, it is that easy!

In my next post I will show you how to test if the authentication is made with Kerberos or falls back to NTLM.