SASL + IMAP + GSSAPI failure (other gssapi stuff works)

Jeff Blaine jblaine at kickflop.net
Wed Feb 7 17:04:48 EST 2007


[ Next 6 paragraphs added after writing the stuff further down ]

I'm not sure when this changed, but the error is now the
following.  Perhaps when I started using a real 'jblaine'
shell with k5 creds via Russ Alberry's pam_krb5.so

     Feb  7 16:50:38 noodle.foo.com imtest[25918]: GSSAPI Error:
     Unspecified GSS failure.  Minor code may provide more information
     (Server not found in Kerberos database)

As an aside, you know, the whole SEAM stuff really kind of pisses
me off.  It just completely gets in my way.  If they're not going
to provide Kerberos API files so I can build OpenAFS against it,
it's garbage to me.  I've checked the latest official Solaris 10
release via Sun Download and the stuff STILL isn't there.

So, now the question is, if I already added imap/noodle.foo.com
as a principal, what is it bitching about?

Answer: imap/localhost

We'll specify the host and... on to a new error!  Good grief.

cyrus-sasl-2.1.22 > /export/home/bin/imtest -m gssapi -u jblaine -a 
jblaine noodle
S: * OK noodle.foo.com Cyrus IMAP4 v2.2.12 server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS 
NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND 
BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE 
LOGINDISABLED AUTH=GSSAPI SASL-IR
S: C01 OK Completed
C: A01 AUTHENTICATE GSSAPI YIICBwYJKoZIhvcSAQICA...HUGE_STRING_HERE
S: + YIGWBgkqhkiG9xIBAgIC...HUGE_STRING_HERE
base64 decoding error
Authentication failed. generic failure
Security strength factor: 0

Feb  7 17:02:37 noodle.foo.com imap[25920]: [ID 824502 local6.notice] 
badlogin: noodle.foo.com [192.168.168.100] GSSAPI [SASL(0): successful 
result: mech EXTERNAL is too weak]

*tilts head*

Ken Hornstein wrote:
>>> - What version of Kerberos are you using?
>> MIT 1.5.1
> 
> .... are you _sure_?
> 
> I ask because of this
>> 25789:  open("/tmp/krb5cc_26560_VKaqJX", O_RDONLY)      = 5
> 
> The default credential cache when using MIT Kerberos is /tmp/krb5cc_<uid>
> Without a KRB5CCNAME environment variable being set ... I honestly don't
> know how MIT Kerberos is supposed to know how to find this credential cache.
> What I see there makes me think you're using the Solaris-supplied Kerberos
> tools, at least for kinit.  If that's the case and you're using MIT Kerberos
> to compile Cyrus-SASL, that would make sense that it can't find the
> crendential cache.  It might be interesting to set KRB5CCNAME to
> the value of FILE:/tmp/krb5cc_26560_whatever and then try running imtest.

[ Pretty irrelevant info below now ]

Let's go with the "jblaine + creds" instance from here on out
that I showed failed.  Ignore my first attempt as root +
'kinit jblaine'.

jblaine gets creds from Russ Alberry's pam_krb5 with
/export/home/lib/security/pam_krb5.so referenced in
/etc/pam.conf always.  So, there's no "which kinit
was used?" involved as I see it:

pam-krb5-3.2 # pwd
/export/home/src/pam_krb5_russ/pam-krb5-3.2
pam-krb5-3.2 # sum pam_krb5.so
3896 604 pam_krb5.so
pam-krb5-3.2 # sum /export/home/lib/security/pam_krb5.so
3896 604 /export/home/lib/security/pam_krb5.so
pam-krb5-3.2 # ldd pam_krb5.so
         libpam.so.1 =>   /usr/lib/libpam.so.1
         libkrb5.so.3 =>  /export/k5/lib/libkrb5.so.3
         libk5crypto.so.3 =>      /export/k5/lib/libk5crypto.so.3
         libcom_err.so.3 =>       /export/k5/lib/libcom_err.so.3
         libresolv.so.2 =>        /usr/lib/libresolv.so.2
         libsocket.so.1 =>        /usr/lib/libsocket.so.1
         libnsl.so.1 =>   /usr/lib/libnsl.so.1
         libdl.so.1 =>    /usr/lib/libdl.so.1
         libgcc_s.so.1 =>         /export/home/lib/libgcc_s.so.1
         libc.so.1 =>     /usr/lib/libc.so.1
         libcmd.so.1 =>   /usr/lib/libcmd.so.1
         libkrb5support.so.0 =>   /export/k5/lib/libkrb5support.so.0
         libmp.so.2 =>    /usr/lib/libmp.so.2
         /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
pam-krb5-3.2 #

An error in my paste before *did* show klist output of Sun's.

So, here's a brand new shell with the proper output:

     jblaine > /export/k5/bin/klist
     Ticket cache: FILE:/tmp/krb5cc_26560_m_aGLY
     Default principal: jblaine at JBTEST

     Valid starting     Expires            Service principal
     02/07/07 16:47:41  02/08/07 16:47:41  krbtgt/JBTEST at JBTEST
     02/07/07 16:47:42  02/08/07 16:47:41  afs at JBTEST


     Kerberos 4 ticket cache: /tmp/tkt26560
     klist: You have no tickets cached
     jblaine >

I was wrong too, in saying that KRB5CCNAME was not set.
Apparently the PAM module sets it:

     jblaine > echo $KRB5CCNAME
     FILE:/tmp/krb5cc_26560_m_aGLY
     jblaine >

     jblaine > truss -f -o /tmp/out /export/home/bin/imtest -m gssapi -k 
1 -u jblaine -a jblaine
     ...
     jblaine > grep /tmp/krb /tmp/out
     25918:  open("/tmp/krb5cc_26560_m_aGLY", O_RDONLY)      = 5
     25918:  open("/tmp/krb5cc_26560_m_aGLY", O_RDONLY)      = 5
     25918:  open("/tmp/krb5cc_26560_m_aGLY", O_RDONLY)      = 5
     jblaine >

I don't know if this says anything, but:

cyrus-sasl-2.1.22 > grep implementation conf.log
checking GSSAPI... with implementation mit
checking GSSAPI... with implementation mit
cyrus-sasl-2.1.22 >

>> 25789:  open("/tmp/krb5cc_26560_VKaqJX", O_RDONLY)      = 5
>> 25851:  open("/export/k5/etc/krb5.conf", O_RDONLY)      = 5
> 
> I can't help noticing that the process IDs don't match up.  Are these
> both from imtest?

Yes, just different runs of it under the same shell as I was
composing my message.


More information about the Cyrus-sasl mailing list