AW: Different behaviour of mod_auth_kerb depending on kerberos stack

[Russ Allbery]

Beier Michael <M.Beier at EnBW.com> writes:

> But on the other hand: we ARE currently running a setup with ~ 300
> services shared in only a few accounts. The only limitation seems to be,
> that this only works with heimdal. It would be a gigantic effort to
> create separate accounts for each service - and that without impact on
> the running services. So at the moment using heimdal on sles11 would be
> the better option.

It's rather surprising to me that you're seeing any difference in the
behavior between Heimdal and MIT.  Our experience is that this is a
browser issue.  IE uses the name of the virtual host, and Firefox uses the
results of a reverse DNS query.  (Some of this may change depending on how
you configure your GSSAPI libraries as used by Firefox.)

We've always had to add both principals to the keytab of a system using
mod_auth_kerb even when using the MIT Kerberos libraries.

> My questions are now: 
> 1) Will the following setup work?

> keytab 1 will be generated for an account containing spn HTTP/hostname.enbw.net.
> keytab 2 will be generated for an account containing spn HTTP/virtualhost.enbw.net
> ...
> keytab x will be generated for an account containing spn HTTP/virtualhostx.enbw.net

> We have to create one "big merged" keytab file, containing all generated
> above, which will be used by mod_auth_kerb.

Yes, that's what we do.

> 2) Firefox will always deliver the ticket for service
> HTTP/hostname.enbw.net - no matter which virtualhost is accessed?

This is generally true, although may change if you, for instance, disable
reverse DNS checks in your GSSAPI library.

> 3) Am I right, that the MIT kerberos implementation checks, if the
> referenced keytab file contains the service requested by the client and
> that this behaviour can not be changed?

Right, this behavior cannot be changed without breaking the Kerberos
protocol.  The server has to find a keys matching the principal used by
the client or it has no way of decrypting the authenticator.  This is also
true of the Heimdal implementation and, indeed, any possible Kerberos
implementation.

The other alternative method is to set up Kerberos aliases so that all of
your virtual host HTTP/* principals alias the principal for the real
hostname, in which case clients will be told to use a different principal.
However, this requires both a KDC and client Kerberos libraries with
support for aliasing, which may not be the case for you.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>