Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 107063 - GSSAPI/SPNego "Single Sign On" stops working with Mit-krb5 1.4.x & Mod_auth_kerb
Summary: GSSAPI/SPNego "Single Sign On" stops working with Mit-krb5 1.4.x & Mod_auth_kerb
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Apache Team - Bugzilla Reports
Depends on:
Reported: 2005-09-23 21:45 UTC by Shirish Jain
Modified: 2007-06-15 18:28 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Shirish Jain 2005-09-23 21:45:09 UTC
On upgrade to mit-krb5, Apache websites using SPNego via mod_auth_kerb fail to
work. Error message reported is 

"Misc Failure: error code 34" or "request is a replay"

Authentication fails. If enabled it falls back to 'kpasswd' method which is not
only insecure since it requires transmitting userid/password but defeats the
very reason of single sign on.

This error doesnt represent itself on mit-krb5 1.3.x series.

>> I have searched on the various forums, and it seems an issue for upstream (MIT).

>> suggested work arounds from


I believe this should be included as part of ebuild since a lot of apps depend
on kerberos provider and its not a good idea to avoid using portage ebuild but
compile from the sources directly to put in this "clever and nasty heck"!

thanks & regards


Reproducible: Always
Steps to Reproduce:
1. setup & correctly configure apache + mit_krb5 + mod_auth_kerb 
2. setup & correctly web browser (AuthNegotiation enabled)
3. search the Mod_auth_kerb enabled site (step 1) and watch the logs

Actual Results:  
a) error -- in logs .. "misc failure :: request is a replay or code 34)

Expected Results:  
a) should have authenticated the user
b) shown the secure web content not an error

Portage (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r1,
2.6.12-gentoo-r10 x86_64)
System uname: 2.6.12-gentoo-r10 x86_64 Intel(R) Xeon(TM) CPU 3.00GHz
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5-r2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
CFLAGS="-march=nocona -O2 -mmmx -msse2 -mfpmath=sse -fomit-frame-pointer"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=nocona -O2 -mmmx -msse2 -mfpmath=sse -fomit-frame-pointer"
FEATURES="autoconfig distlocks sandbox sfperms strict"
USE="amd64 acl apache2 bash-completion crypt dlloader erandom expat fam gd gdbm
gif hardened hardenedphp jpeg kerberos ldap maildir nls nptl nptlonly pam perl
php png python readline samba ssl userlocales webdav winbind x86 xml2 zlib
userland_GNU kernel_linux elibc_glibc"
Comment 1 Shirish Jain 2005-10-05 09:44:14 UTC
Folks, shouldnt this bug be assigned to Applications/maintainers for mit-krb5 as
it has not much to do with Apache?

also, anyone with any suggestions?
Comment 2 Michael Stewart (vericgar) (RETIRED) gentoo-dev 2006-01-04 19:41:14 UTC
I agree with comment #2, this looks like an issue with mit-krb5, not with apache.
Comment 3 Shirish Jain 2006-04-21 10:27:16 UTC
back again with some steps to fix this problem.
This is a more so gentoo specific problem as we are source based and we need to calculate the exact padding required. e.g. I got 3 different values on 3 diff environments i have.

Following steps (i m sure I probably forgot something)

a) equery which mit-krb5
... /usr/portage/app-crypt/mit-krb5/mit-krb5-1.4.3.ebuild
b) ebuild /usr/portage/app-crypt/mit-krb5/mit-krb5-1.4.3.ebuild clean
c) ebuild /usr/portage/app-crypt/mit-krb5/mit-krb5-1.4.3.ebuild unpack
d) ebuild /usr/portage/app-crypt/mit-krb5/mit-krb5-1.4.3.ebuild compile
e) cd /var/tmp/portage/mit-krb5-1.4.3/work/krb5-1.4.3/src/
f) nano k5test.c
> ----- k5test.c
> #include "k5-int.h"
> #include <stdio.h>
> int main (void) {
>   printf("Sizeof(k5_mutex_t) is %d\n",sizeof(k5_mutex_t));
>   return 0;
> }
> -----
g) cc -Iinclude -Iinclude/krb5 k5test.c -o k5test.o
h) ./k5test.o
... Sizeof(k5_mutex_t) is xx
(xx could be say 88 on a 2-way AMD64)

wow ... so now we know the padding required. lets move on to the hard yards

1) echo "net-www/mod_auth_kerb ~x86" >> /etc/portage/package.keywords
2) equery which mod_auth_kerb
... /usr/portage/net-www/mod_auth_kerb/mod_auth_kerb-5.0_rc7.ebuild
(below instructions work for rc6 too, however, i havent tested it. YMMV)
3) ebuild /usr/portage/net-www/mod_auth_kerb/mod_auth_kerb-5.0_rc7.ebuild setup
4) ebuild /usr/portage/net-www/mod_auth_kerb/mod_auth_kerb-5.0_rc7.ebuild unpack
5) ebuild /usr/portage/net-www/mod_auth_kerb/mod_auth_kerb-5.0_rc7.ebuild compile
6) cd /var/tmp/portage/mod_auth_kerb-5.0_rc7/work/mod_auth_kerb-5.0rc7
7) vi src/mit_internals.h
typedef struct _krb5_gss_cred_id_rec {
        /* name/type of credential */
+        char pad[xx];
        gss_cred_usage_t usage;

(xx is the number that was output from step h above)
8) rm /var/tmp/portage/mod_auth_kerb-5.0_rc7/.compile
9) ebuild /usr/portage/net-www/mod_auth_kerb/mod_auth_kerb-5.0_rc7.ebuild compile
10) ebuild /usr/portage/net-www/mod_auth_kerb/mod_auth_kerb-5.0_rc7.ebuild install
11) ebuild /usr/portage/net-www/mod_auth_kerb/mod_auth_kerb-5.0_rc7.ebuild qmerge

well thats about it ... configure ur Apache configuration files as normal. You can now use 
>>>        KrbMethodK5Passwd off
>>>        KrbMethodNegotiate on

and above will work without those "Request is a Replay" errors.

please feel free to suggest corrections.

Will be good if these can be included as part of the ebuild ... I belive this is only required if using mit-krb5.
Comment 4 James Oulman 2006-09-05 13:24:39 UTC
Has anyone taken a look at this?

I applied the patch against 5.0_rc7 and it seems to work with 1.4.3-r1
Comment 5 James Oulman 2006-09-05 13:31:16 UTC
There is also a new version that fixes the replay cache issue with mit-krb5-1.4.3
Comment 6 Seemant Kulleen (RETIRED) gentoo-dev 2007-04-03 20:50:10 UTC
Honestly, I'm not sure what kerberos can do about this.  It seems all the patches and fixes are for the apache module (which I don't maintain).
Comment 7 Christian Heim (RETIRED) gentoo-dev 2007-06-15 16:02:42 UTC
Martin, Seemant, anyone of you got any idea why this might be happening ? 
Comment 8 Benedikt Böhm (RETIRED) gentoo-dev 2007-06-15 18:28:07 UTC
mod_auth_kerb-5.3 is in cvs for 5 months now... please reopen if it's still an issue