Jukka Salmi --> info-cyrus (2006-10-24 18:46:52 +0200): > Jukka Salmi --> info-cyrus (2006-10-22 16:32:58 +0200): > > Jukka Salmi --> info-cyrus (2006-10-22 16:23:30 +0200): > > > Hi, > > > > > > I'm using Cyrus IMAP4 v2.2.13. > > > > > > I haven't used cyradm for some time, but today I noticed I can't log > > > in as admin anymore because GSSAPI authentication fails. My imapd.conf > > > contains `admins: jukka/admin'; I successfully require a TGT for > > > jukka/admin, but authentication fails: > > > > > > $ cyradm --user jukka/admin --authz jukka/admin host > > > cyradm: cannot authenticate to server with as jukka/admin > > > > > > The following is logged: > > > > > > imap[15512]: accepted connection > > > imap[15512]: badlogin: [...] GSSAPI [SASL(-13): authentication failure: bad userid authenticated] > > > > > > Using a principal without a "admin" instance as a cyrus admin works > > > fine. This used to work some time ago, but I can't remember when > > > exactly... > > > > This is badly worded. I tried to say that using an /admin instance of > > a Kerberos principal as a cyrus admin user id used to work, but right > > now only non-admin instances seem to work. > > > > > > > Any hints what could have cause this regression? Or even better how > > > to fix it? ;-) > > This regression was introduced with Cyrus IMAPd v2.2.13: I just failed > to reproduce the problem with v2.2.12, i.e. 2.2.12 works fine. I found the problem: for some reason I don't understand (or is it just a bug?) HAVE_GSSAPI_H is only defined if .../gssapi.h is found, but _not_ if .../gssapi/gssapi.h is found: $ ./configure [...] [...] checking gssapi.h usability... no checking gssapi.h presence... no checking for gssapi.h... no checking gssapi/gssapi.h usability... yes checking gssapi/gssapi.h presence... yes checking for gssapi/gssapi.h... yes [...] checking for gss_unwrap in -lgssapi... yes checking GSSAPI... with implementation heimdal [...] $ grep HAVE_GSSAPI_H config.h #undef HAVE_GSSAPI_H Defining HAVE_GSSAPI_H and rebuilding fixed the problem: using a principal's /admin instance as a cyrus admin now works again. I had a glance at the latest Cyrus IMAPd 2.3 sources and the problem seems to be still there. Any comments? Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~ ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
