AW: Different behaviour of mod_auth_kerb depending on kerberos stack

[Beier Michael]

Thank you for that hint. 

Today I recompiled mod_auth_kerb with MIT 1.8.1 from http://download.opensuse.org/repositories/network/SLE_11
and set "allow_weak_crypto = true" in libdefaults section of krb5.conf.
But both firefox and IE could not access my website :-( The error code is the same as described here: http://diswww.mit.edu:8008/menelaus.mit.edu/kerberos/32685

So my "last" try was MIT 1.7 found at
http://download.opensuse.org/repositories/openSUSE:/11.2/standard
With this setup firefox and IE can access my website.

Both versions were built with the same configure-string and almost the same SuSE patches.

So for the moment I'm almost happy.

Best regards,
Michael

-----Ursprüngliche Nachricht-----
Von: Russ Allbery [mailto:rra at stanford.edu] 
Gesendet: Mittwoch, 20. Oktober 2010 01:18
An: Beier Michael
Cc: 'kerberos at mit.edu'
Betreff: Re: AW: AW: Different behaviour of mod_auth_kerb depending on kerberos stack

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/>