Service principal with port number

Roland C. Dowdeswell elric at
Mon Oct 22 13:02:20 EDT 2012

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/

More information about the krbdev mailing list