The biggest mistake: ServicePrincipalName’s
Note: All of your Kerberos configuration questions can be answered by using the DelegConfig tool that I wrote. You can find that tool here
Literally 99% of all Kerberos problems revolve around an incorrect, missing, or duplicate ServicePrincipalName (SPN). To be honest, the concept of an SPN is so simple that I am often confused that other people don't understand even after I explain. I suppose it is the 5+ years that I've had of helping people configure and troubleshoot Kerberos related issues that have finally made it all clear to me ;-p. I like to think in simple terms instead of making things complex . This is a carry-over from my Algebra-1 days when my teacher used to pick the easiest problem possible when explaining a concept.
Think of an SPN as a “username” used to identify a program that is busy dealing with credentials. And we're only allowed to talk to this program using its “username”. PERIOD. Simple! Yes, that's all an SPN is: a "username". And as with any username, the name itself isn't really that important. It is merely to make identifying a person (or entity) easier to remember to humans. In this particular case, however, there are some naming conventions for this "username". Okay, so what username (SPN) is the right one? And where do we set it? These 2 questions are where all the confusion lies. We split the SPN into 2 parts and occasionally 3 parts: The first part is the “service type” and the second part is the “host name”. And sometimes the 3rd part is present which is the “port”. In the end, however, all these different parts are simply used to come up with this "username" that we call the ServicePrincipalName.
Let’s say I wanted to connect to a process called BrianService.exe. And the DNS name to route my connection was blah.overthere.com. As the designer of this weird service I might come up with a “service type” of BRIAN. So the SPN would be BRIAN/blah.overthere.com. Okay, and where do we set that? Simple, simple, simple. If my BrianService.exe process is running under “DOMAINNAME\someAccount” then we’d set the BRIAN/blah.overthere.com SPN on “DOMAINNAME\someAccount”. If my process (BrianService.exe) were running as something like “Network Service”, “Local Service”, or “Local System” then I’d set BRIAN/blah.overthere.com on the computer account itself that is running that process. If you ever change the account that is running your program then you need to remove the SPN from the original account and set it on the new account because we can't have the same username assigned to multiple "people" (or accounts in our case).
Recap. An SPN is just a *name* that we've given to a "service" which is in the format of ServiceType/HostName and occasionally ServiceType/HostName:PortNumber. And it is set on which ever account is handling authentication for that service. I should also note that you as an administrator don’t get to pick whether you use a port. I used to think that maybe I could throw a port number on an SPN if I wanted to make it more secure. But it is the client application that has the decision built in on whether to use a port.
Okay, so let’s make this more complicated by using more realistic names. But while I do that I want you to maintain faith in what I just explained above regarding how simple these concepts are. Let’s say you’re connecting to an IIS server with a machine name of “iis-prod-01”. And let’s say the active directory domain name is “company.com.” In Internet Explorer you use an address of http://someInventedName. The “application pool” (i.e. the w3wp.exe process) is running under the account of “COMPANY\myserviceAccount”. With the knowledge that the web service’s Kerberos “service type” is “HTTP” (don’t confuse this with the browser’s protocol type) you’re probably thinking we can set an SPN of “HTTP/someInventedName” on “COMPANY\myserviceAccount”. Doh!! Sorry no. Almost, but Kerberos would probably not work with that. The problem with that idea is that you have to know how name resolution is working also because it is ultimately name resolution that dictates what the "host name" part of the SPN should be. If you open a CMD prompt and ping someInventedName, it will most likely resolve to someInventedName.company.com. Therefore the SPN that “IE” will request is “HTTP/someInventedName.company.com”. IE was not programmed to request an SPN using the port so that part of the SPN is not needed nor can it ever be used. What if the ping did show the name as just “someInventedName”? Then IE would in-fact use Kerberos with an SPN of “HTTP/someInventedName” When dealing with NetBIOS names, because name resolution can be affected by many things, the key is to make sure an SPN of both “HTTP/someInventedName” and “HTTP/someInventedName.company.com” are set on the “COMPANY\myserviceAccount” account. Or the way I prefer to say that is you need to create an SPN that represents both the NetBIOS name and the Fully Qualified name.
Okay, so I can hear what many of you are thinking. “But I thought that KB article said to set the SPN on the computer account!” Well, yes, that would be accurate *IF* the process handling authentication was running as “SYSTEM”. If the process for that service is not running as SYSTEM (or Network Service, or Local Service) then you can’t set the SPN on the computer account (well you can but Kerberos isn’t going to work).
Recap 2: An SPN should actually be in the format of ServiceType/NetBIOSName *and* ServiceType/FQDN. And we *always* set that on whatever account is running the process that is handling the authentication. Read the above paragraphs a couple times and just maintain faith that it is really that simple. Don’t complicate it with questions!!
I want to mention one last thing before I go. Whenever a computer is joined to a domain, it is assigned 2 SPN's by default: HOST/netbiosName, and HOST/FQDN.com. netbiosName being the machine name of the computer you're joining to the domain, and FQDN.com being the fully qualified machine name. These two SPN's use the generic "HOST" service type which includes all the various services that *come* with Windows. Therefore, if you connect to http://machineName or http://machineName.company.com, you will already have SPN's set that will handle Kerberos when using those names. Or if you connected to \\machineName\SomeShareName you'd also be all set for Kerberos (UNC's need a "CIFS" SPN which is included under "HOST" also). For a full list of the different service types included in HOST please see Table 1 of this technet article.
--Brian Murphy-Booth