Kerberos Authentication problems - Service Principal Name (SPN) issues - Part 2

First published on TechNet on Jun 09, 2008

Rob here. So, we saw in Part 1 what kind of error you could expect when there is no Service Principal Name defined for the Kerberos ticket the application is requesting. The next part I would like to show you is what might be the error message you would get if there were multiple accounts with the same SPN defined on them.

We are not going to cover the basics of how to capture a network trace and how to review it this time so this part should be fairly quick. We are going to be using the same configuration as the previous blog post.

Again, we notice that the website shows that we are authenticating with NTLM and the web server’s auditing log also shows that we authenticated using NTLM.

Now when we look at the network trace, we see the following:

1. We see proper name resolution, for webapp.fabrikam.com and the DNS server response back with the IP address of 10.10.200.105 (frames 11 & 12)

2. The machine then makes an http connection to the web server, and gets “401 Unauthorized” (frames 18 -21). Note, I am showing you in the detail pane that the web server responded back with “WWW-Authenticate: Negotiate” and “WWW-Authenticate: NTLM” to let you see that the web server is configured properly to support Kerberos Authentication.

3. The machine then goes to the domain controller and gets its TGT (see the AS-REQ and AS-REP frames 23 & 24) then it does a TGS-REQ request but the domain controller responds back again with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN (frames 25 & 26). As you can see below, the machine was asking for a Kerberos ticket of HTTP/webapp.fabrikam.com.

If you read the previous blog posting, your first thought might be to just add the Service Principal Name to the KerbSvc account and call it a day. If you did this, you would be wrong! If we look at the domain controllers System Event log we will see this really nice Event log entry.

This event log basically is stating that there are multiple computer or user accounts that have a Service Principal Name of HTTP/webapp.fabrikam.com within the Active Directory Forest. You can use LDP , LDIFDE or QuerySPN.vbs to find where the SPN's are registered. When you use these tools to search for duplicate SPN’s you should always start at the forest root and target a global catalog server. I prefer to use the queryspn.vbs and use wildcards in my statement. Review KB321044 if these tools are new to you. Just because the event shows that the FQDN is duplicated, you might be surprised by a duplicate SPN of the NetBIOS name HTTP/webapp too.

As you can see from this output, the account FAB-RT-MEM1 (Computer Account) and the account “Kerberos Service” (User Account) both have “http/webapp” and “http/webapp.fabrikam.com” assigned to them. No wonder the domain controller reported the KDC 11 event.

The resolution to this issue is fairly simple. If you remember from the previous blog, the web application is running in a Web Application Pool that is running under the context of the KerbSvc account. So in this instance we would want to use SetSPN to delete the HTTP SPN's from the computer account FAB-RT-MEM1.

Now, when we test the application, we can see that Kerberos authentication is used to access the website.

I am not going to show the network traces of it working again. If you would like to review what a working trace looks like please review Part 1 .

Summary

In support we see duplicate Service Principal Name issues quite frequently. Usually this is when the Administrator has used the SetSPN on different accounts in an effort to get Kerberos Authentication to work. One great example of this is MS SQL. If you install MS SQL as an Administrator of the domain, it will add the MSSQLSVC SPN to the SQL Server’s computer account; later an Administrator changes the SQL Service startup account from Local System to a domain account and Kerberos Authentication starts to fail. Usually we will find that the MSSQLSVC SPN is configured on both the computer account as well as the domain user account that is used to run the service.

I hope that you have learned something new on how to troubleshoot a Kerberos Service Principal Name issue and that you’re starting to feel more comfortable using network traces to determine why Kerberos Authentication might be failing. Stay tuned for Part 3 where we will cover some more ways in which Kerberos Authentication can fail when Service Principal Names are not correctly configured.

- Robert Greene