Server Principal Name [SPN]

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 baffled by why they are so hard for many people to understand. 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 (process) that deals with usernames/passwords. And you’re only allowed to talk to this program using its “username”. PERIOD. Simple! Okay, well almost that simple. What username (SPN) is the right one? And where do we set it? We split the SPN into 2 parts and occasionally 3 parts: There is the “service type” and the “host name” (and sometimes the “port”… but not usually). Let’s say I wanted to connect to a process called BrianInfoService. 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. Where do we set that? Simple, simple, simple. If my BrianInfo.exe process is running under “DOMAINNAME\someAccount” then we’d set the BRIAN/blah.overthere.com SPN on “DOMAINNAME\someAccount”. If my process (BrianInfo.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 username that is running your program then you need to remove it from the original username and set it on the new account.
Why does that confuse people? Well… I suspect it is because of all the vague, misleading, or plainly inaccurate KB articles, news group postings, or other forms of documentation floating around on the Internet. Or… it might be because real life doesn’t use simple names like “someAccount”.
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. Recap. An SPN 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. Also, you as an administrator don’t get to pick whether you use a port. The client application has that decision built in. 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. 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” But 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. 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 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!!
Incidentally, I wrote an ASP.NET application that looks at all the relevant settings needed for Kerberos and Delegation to work. Currently, however, I don't have a good public way of distributing it. If you want to quickly get your server in shape for Kerberos and Delegation, you can open a support incident with Microsoft and you can get ahold of the tool I wrote.