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 * http://sourceforge.net/mailarchive/forum.php?thread_id=6684370&forum_id=9893 * http://comments.gmane.org/gmane.comp.apache.mod-auth-kerb.general/614 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 Shirish 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 2.0.51.22-r2 (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/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -mmmx -msse2 -mfpmath=sse -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" 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" DISTDIR="/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.pacific.net.au/gentoo" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://xx.xx.xx.xx/gentoo-portage" 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" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
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?
I agree with comment #2, this looks like an issue with mit-krb5, not with apache.
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.
Has anyone taken a look at this? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340360 I applied the patch against 5.0_rc7 and it seems to work with 1.4.3-r1
There is also a new version that fixes the replay cache issue with mit-krb5-1.4.3 http://sourceforge.net/project/showfiles.php?group_id=51775&package_id=45786&release_id=443935
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).
Martin, Seemant, anyone of you got any idea why this might be happening ?
mod_auth_kerb-5.3 is in cvs for 5 months now... please reopen if it's still an issue
