Service principal with port number

[Adam McLaurin]

As emailed to me directly from one of the users on this list, it does
seem like there is a solution to how the browser (at least for Internet
Explorer) constructs the SPN:
http://blogs.dirteam.com/blogs/tomek/archive/2009/12/20/kerberos-a-sprawa-portu.aspx
http://support.microsoft.com/kb/908209

However, this solution is incomplete unless gssapi/krb5 can actually
support an SPN with an optional port number.

Can someone please give some details regarding the priority of
introducing such a feature, and when is the earliest date that we might
a build the supports it?

Thanks again,
Adam


On Mon, Oct 22, 2012, at 01:02 PM, Roland C. Dowdeswell wrote:
> On Thu, Oct 18, 2012 at 09:04:44PM -0400, Adam McLaurin wrote:
> >
> 
> > The issue arises when we have multiple authenticating web servers
> > running on the same host but under different user accounts. Out of
> > necessity the web servers will need to run on different ports, but as
> > far as I know the web browser simply "guesses" the SPN by constructing
> > it as "HTTP/<hostname>". Without the port number, I don't know how to
> > distinguish the SPN for one server versus another. Perhaps I'm wrong
> > about how the browser constructs the SPN - if so please correct me.
> 
> Yes.  The web browsers, however, don't use the port number to
> construct the name which means that it is of limited utility to
> try to use it.  If you are writing your own Kerberised applications,
> you can vary the service in the service principal rather than adding
> a port number.  This is the more generally accepted way to do these
> things and is easier to understand than encoding a port number into
> the principal.  Remember that a Kerberos service principal's can
> be thought of as <service> / <hostname> @ REALM.  <service> is not
> in general protocol, although you do see a lot of that in practice
> which is a little unfortunate.
> 
> If you are constrained to use web browsers, however, your options
> become a little more limited as you are not in control of the client
> application.  They will use HTTP/<hostname> only, IIRC.  Your
> options here include: (1) share the HTTP/<hostname> keys which is
> not a terribly good idea for a number of reasons, (2) run a proxying
> web server as a trusted user that authenticates users and hands
> them off to the web servers run by less trusted users passing along
> the authenticated user names in some non-krb5 fashion, (3) maybe
> experiment with using different hostnames pointing at the same
> machine and manage the keytabs carefully, (4) write a service that
> will validate the GSSAPI tokens which is accessible by each of the
> web servers and modify each web server to use it, etc.
> 
> --
>     Roland Dowdeswell                      http://Imrryr.ORG/~elric/