Kerberos and non-standard port number

Reading Time: 4 minutes

Kerberos in Windows Operating System is around for about 10 years and it is still causing problems and for many people it is like black magic voodoo. In most cases organizations and people in it are not aware that it is now working until it problem will occur on a surface with some application not working or reports not being displayed on MOSS web page …

… and when problem occurs some troubleshooting starts. To make this process a bit easier here is a short explanation of Kerberos, IE and and services running on non-standard port issue.

 

(cc) TheCX

This post is sponsored by letter A like Architect, because of our Architects inspired me to write it with his ranting about this problem.

Issue which is subject of this post is not related to Kerberos protocol itself, but to Internet Explorer and how IE handles such requests by default.

 

Never ending story,  SPNs …

Short reminder what SPN is  … when client application is trying to get access to resources and is using Kerberos authentication it requests at some point Ticket Granting Service (TGS). To specify to service to which it is requesting access in TGS request client specifies Service Principal Name (SPN). SPN then is being used by KDC to find an account which is related to this service and to prepare tickets for it. This is in short words how it works …

SPNs are just string values for servicePrincipalName attribute in form which consist of service prefix, host name and optionally port number.

For example for standard HTTP service running on www.w2k.pl host address SPN would be specified as HTTP/www.w2k.pl.

As I mentioned above there is also optional element of SPN which can be used to specify port on which service is running. In case of our HTTP service running on 8080 port SPN which will contain this port number will look like this HTTP/www.w2k.pl:8080.

Simple … it is helpful if we have services running on different ports and using different accounts – like application pools running on separate accounts associated with web sites on two different ports.

 

And here comes Internet Explorer …

Problem with Internet Explorer is that when it is being used as client application to request access to Kerberos enabled service on non standard port by default it will not include port number in SPN sent in TGS request. In such case network traffic capture will look somewhat like this (click to enlarge):

As we can see in this traffic IE is trying to request access to web site running on port 8080 but in TGQ request it is not exposing this information and instead of HTTP/lhr2dc01.w2k.pl:8080 it sends request with HTTP/lhr2dc01.w2k.pl as SPN value.

This behavior was first fixed for IE 6 with KB 908209. For IE6 it required fix to be installed and additional registry entry being made.

This article is not mentioning this but same behavior is present in IE7 and IE8. To fix this it doesn’t require fix to be installed but still it has to be enabled through same registry entry specified in KB mentioned above.

If this will be done same situation in network traffic looks as it is presented below (click to enlarge):

As it can be seen in this traffic analysis IE is requesting access to a web site with port specified in SPN and this allows authentication to be completed in this scenario.

 

When this is useful  …

“Why bother???” This is required in scenarios when we have multiple services running on single host, different ports and under different security accounts. Good examples are multiple application pools on single IIS machine.

Probably anyone who will deploy MOSS sites with multiple accounts will came across this scenario and will have to deal with it.

 

Why not make it default …

Question is … why this is not enabled by default in IE 7 and 8? problem was fixed for IE6 but for later versions it might be included in a default configuration.

I don’t know official answer but first thing which cross my mind is  – backward compatibility (you can call it IE6 curse if You want it 🙂 ).  Because IE6 worked in this way and many applications were configured to work in this way, which was allowed by IE6 problem turning it on by default in next versions would break all these applications.

IE6 was not specifying a port in SPN request and if there was suitable account with only one SPN without port being specified, and there was another service running on the same host with different port number but under the same service account it just works.

If You will enable this behavior applications running on different ports would break … registering additional SPN will fix it of course, but this would require some planning up front or quick troubleshooting (basic level of network traffic analysis required).

What I would like to see is configuration option which would enable this behavior through GPO … feedback given :).