Different behaviour of mod_auth_kerb depending on kerberos stack

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Different behaviour of mod_auth_kerb depending on kerberos stack

Beier Michael
Hi,

we're using kerberos to authenticate our users accessing websites hosted on apache 2.2 webservers using mod_auth_kerb. Currently we're trying to update our kerberos-stack on SuSE linux from heimdal 0.7.2 to MIT 1.6.3 (this version comes with SuSE Linux Enterprise Server 11).

Currently we're running mulitple websites configured as virtual hosts in apache. All virtual hosts could be served using one single keytab file representing one single account in our active directory (win 2003) with one ServicePrincipalName for each virtual host.

The keytab file contains only one entry for "HTTP/[hidden email]".

This worked fine, using the heimdal kerberos implementation, even if the browser (i.e. InternetExplorer 7) accesses a virtual host http://virtualhost.enbw.net/ and sends a ticket for the service HTTP/virtualhost.enbw.net.

Using the MIT implementation, accessing the virtualhost using firefox still works, because firefox does a reverse and forward dns-look and sends a kerberos ticket for HTTP/hostname.enbw.net, which is found in the keytab file. With InternetExplorer mod_auth_kerb declines the access to http://virtualhost.enbw.net, because it sends (actually the same) kerberos ticket (but) for HTTP/virtualhost.enbw.net, which is not found in the keytab file. Apache shows the following error:

gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information (, Key table entry not found)

At the moment I've no really good ides how to solve this - the first idea was to create a separate account and keytab for each virtualhost, but the different behaviour of firefox and IE seem to make that impossible, because one ServicePrincipalName would have to be added to multiple accounts, but must be unique in active directory at the same time.

Can anyone provide me some help or idea, how to solve this?

Thanks and best regards,

Michael

Michael Beier
Team SIS OIOAW (Web Basis)

EnBW Systeme Infrastruktur Support GmbH
Durlacher Allee 93
76131 Karlsruhe

Tel.: +49 (7 21) 63 - 14545
Fax: +49 (7 21) 63 - 15099
mailto:[hidden email]

EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim ‑ HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Different behaviour of mod_auth_kerb depending on kerberos stack

Russ Allbery
Beier Michael <[hidden email]> writes:

> Using the MIT implementation, accessing the virtualhost using firefox
> still works, because firefox does a reverse and forward dns-look and
> sends a kerberos ticket for HTTP/hostname.enbw.net, which is found in
> the keytab file. With InternetExplorer mod_auth_kerb declines the access
> to http://virtualhost.enbw.net, because it sends (actually the same)
> kerberos ticket (but) for HTTP/virtualhost.enbw.net, which is not found
> in the keytab file. Apache shows the following error:

> gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code
> may provide more information (, Key table entry not found)

> At the moment I've no really good ides how to solve this - the first
> idea was to create a separate account and keytab for each virtualhost,
> but the different behaviour of firefox and IE seem to make that
> impossible, because one ServicePrincipalName would have to be added to
> multiple accounts, but must be unique in active directory at the same
> time.

> Can anyone provide me some help or idea, how to solve this?

Add keytabs for each virtual host and then use "KrbServiceName Any" in
your Apache configuration.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

AW: Different behaviour of mod_auth_kerb depending on kerberos stack

Beier Michael
This approves a note in the following guide I found at microsoft:
http://technet.microsoft.com/en-us/library/bb742433.aspx

"You cannot map multiple service instances to the same user account."

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.

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.

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

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?

Best regards,
Michael

-----Ursprüngliche Nachricht-----
Von: Russ Allbery [mailto:[hidden email]]
Gesendet: Dienstag, 19. Oktober 2010 20:02
An: Beier Michael
Cc: '[hidden email]'
Betreff: Re: Different behaviour of mod_auth_kerb depending on kerberos stack

Beier Michael <[hidden email]> writes:

> Using the MIT implementation, accessing the virtualhost using firefox
> still works, because firefox does a reverse and forward dns-look and
> sends a kerberos ticket for HTTP/hostname.enbw.net, which is found in
> the keytab file. With InternetExplorer mod_auth_kerb declines the access
> to http://virtualhost.enbw.net, because it sends (actually the same)
> kerberos ticket (but) for HTTP/virtualhost.enbw.net, which is not found
> in the keytab file. Apache shows the following error:

> gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code
> may provide more information (, Key table entry not found)

> At the moment I've no really good ides how to solve this - the first
> idea was to create a separate account and keytab for each virtualhost,
> but the different behaviour of firefox and IE seem to make that
> impossible, because one ServicePrincipalName would have to be added to
> multiple accounts, but must be unique in active directory at the same
> time.

> Can anyone provide me some help or idea, how to solve this?

Add keytabs for each virtual host and then use "KrbServiceName Any" in
your Apache configuration.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery
Beier Michael <[hidden email]> 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 ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Beier Michael
I'll try to explain the differene I see:

We've got an account with UserPricipalName HTTP/[hidden email] 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)".

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

Best regads,
Michael

-----Ursprüngliche Nachricht-----
Von: Russ Allbery [mailto:[hidden email]]
Gesendet: Dienstag, 19. Oktober 2010 22:26
An: Beier Michael
Cc: '[hidden email]'
Betreff: Re: AW: Different behaviour of mod_auth_kerb depending on kerberos stack

Beier Michael <[hidden email]> 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 ([hidden email])             <http://www.eyrie.org/~eagle/>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery
Beier Michael <[hidden email]> writes:

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

> We've got an account with UserPricipalName
> HTTP/[hidden email] 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 ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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:[hidden email]]
Gesendet: Mittwoch, 20. Oktober 2010 01:18
An: Beier Michael
Cc: '[hidden email]'
Betreff: Re: AW: AW: Different behaviour of mod_auth_kerb depending on kerberos stack

Beier Michael <[hidden email]> writes:

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

> We've got an account with UserPricipalName
> HTTP/[hidden email] 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 ([hidden email])             <http://www.eyrie.org/~eagle/>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Different behaviour of mod_auth_kerb depending on kerberos stack

Simo Sorce
In reply to this post by Russ Allbery
On Tue, 19 Oct 2010 16:18:10 -0700
Russ Allbery <[hidden email]> wrote:

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

Or maybe it just tries all the keys regardless of their principal name,
and if one succedes in decrypting the payload it just uses it.
It is probably much faster this way.

Simo.

--
Simo Sorce * Red Hat, Inc * New York
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Different behaviour of mod_auth_kerb depending on kerberos stack

Tom Yu
Simo Sorce <[hidden email]> writes:

> On Tue, 19 Oct 2010 16:18:10 -0700
> Russ Allbery <[hidden email]> wrote:
>
>> 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.
>
> Or maybe it just tries all the keys regardless of their principal name,
> and if one succedes in decrypting the payload it just uses it.
> It is probably much faster this way.

We implemented this behavior in MIT Kerberos, but I think the
application needs to avoid specifying an explicit GSS acceptor name in
order for it to work.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Different behaviour of mod_auth_kerb depending on kerberos stack

Russ Allbery
In reply to this post by Simo Sorce
Simo Sorce <[hidden email]> writes:
> Russ Allbery <[hidden email]> wrote:

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

> Or maybe it just tries all the keys regardless of their principal name,
> and if one succedes in decrypting the payload it just uses it.
> It is probably much faster this way.

Oh, good point.  You're right, that would be a lot more efficient, and I
don't see any obvious drawback.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos