cyradm auth failure with krb admin instances

Jukka Salmi j+asg at 2006.salmi.ch
Wed Oct 25 16:37:51 EDT 2006


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 ~


More information about the Info-cyrus mailing list