AW: AW: Different behaviour of mod_auth_kerb depending on kerberos stack

[Russ Allbery]

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

> I'll try to explain the differene I see:

> We've got an account with UserPricipalName
> HTTP/servername.enbw.net at ENBW.NET containing two SPNs:
> HTTP/servername.enbw.net
> HTTP/virtualhost.enbw.net

> From that account we generate one keytab, which is used by mod_auth_kerb.

> Webserver 1 uses mod_auth_kerb build against Heimdal:
> - firefox sends the ticket for the service "HTTP/servername.enbw.net".
> - IE sends the ticket for the service "HTTP/virtualhost.enbw.net".
> Both browsers can successfully access http://virtualhost.enbw.net.

> Webserver 2 uses mod_auth-kerb build against MIT:
> - firefox sends the ticket for the service "HTTP/servername.enbw.net"
>   and can access http://virtualhost.enbw.net.
> - IE sends the ticket for the service "HTTP/virtualhost.enbw.net" and is
>   rejected by mod_auth_kerb with the errormessage
>   "gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code
>   may provide more information (, Key table entry not found)".

Oh!  You already have principal aliases, but your Heimdal build supports
principal aliasing and your MIT build doesn't.  You could presumably also
fix this by upgrading your version of MIT Kerberos (unless that support is
buggy; I don't know if it is).

> Yesterday I would have expected IE to be able to access the website too
> on webserver 2.  Today - after you explanations - I would rather expect
> heimdal to check, if the requests service is in the keytab and IE to get
> no access on webserver 1.

> But in fact there is a difference ..

Heimdal is doing that check, but it's apparently smart enough to ask your
KDC and resolve the alias first, so it finds the right principal.

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