On Wed, May 24, 2006 at 10:16:05PM -0300, Andreas Hasenack wrote: > On Tuesday 23 May 2006 19:50, Huaqing Zheng wrote: > > I'm having some problems with clients linked against Cyrus SASL > > 2.1.22. Running imtest linked against 2.1.22 against an cyrus-imapd > > server (also linked against 2.1.22) with GSSAPI authentication shows: > > > > C: A01 AUTHENTICATE GSSAPI BLAHBLAHBLAH > > S: + BLAHBLAHBLAH > > Authentication failed. generic failure > > Security strength factor: 0 > > I just found out I'm having the same exact problem, but not will all clients: > just cyrus' own clients such as imtest. > > > and this in the imap logs: > > May 23 15:48:01 pobox09 imap[26261]: badlogin: pobox09.stanford.edu > > [171.67.22.15] GSSAPI [SASL(0): successful result: security flags do > > not match required] > > > > Same happens with Kerberos 4. PLAIN and LOGIN both work fine, which > > indicates that saslauthd is running fine against GSSAPI. Note that > > running the 2.1.22 client against a 2.1.21 server gives the same thing > > whereas running the 2.1.21 client against the 2.1.22 server is working > > fine. > > I tried gssapi, digest-md5 and cram-md5, none work. Login (both imap login > and sasl login) and plain do work. Here a sample session with the "base64 decoding error": $ imtest -m digest-md5 localhost S: * OK pandora.conectiva Cyrus IMAP4 v2.2.12-Mandriva-RPM-2.2.12-22mdk 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 STARTTLS AUTH=GSSAPI AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR LISTEXT LIST-SUBSCRIBED X-NETSCAPE S: C01 OK Completed C: A01 AUTHENTICATE DIGEST-MD5 S: + bm9uY2U9IkVZMEI5anR4NlNsc0tQSGhHTGovNmI4WW1qQ3BadDZCL1RGUXAva21kUEU9IixyZWFsbT0icGFuZG9yYS5jb25lY3RpdmEiLHFvcD0iYXV0aCxhdXRoLWludCxhdXRoLWNvbmYiLGNpcGhlcj0icmM0LTQwLHJjNC01NixyYzQsZGVzLDNkZXMiLG1heGJ1Zj00MDk2LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz base64 decoding error Authentication failed. generic failure Security strength factor: 0 C: Q01 LOGOUT Connection closed. At first glance, this base64 strings seems valid: $ ./b64.py -d bm9uY2U9IkVZMEI5anR4NlNsc0tQSGhHTGovNmI4WW1qQ3BadDZCL1RGUXAva21kUEU9IixyZWFsbT0icGFuZG9yYS5jb25lY3RpdmEiLHFvcD0iYXV0aCxhdXRoLWludCxhdXRoLWNvbmYiLGNpcGhlcj0icmM0LTQwLHJjNC01NixyYzQsZGVzLDNkZXMiLG1heGJ1Zj00MDk2LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz nonce="EY0B9jtx6SlsKPHhGLj/6b8YmjCpZt6B/TFQp/kmdPE=",realm="pandora.conectiva",qop="auth,auth-int,auth-conf",cipher="rc4-40,rc4-56,rc4,des,3des",maxbuf=4096,charset=utf-8,algorithm=md5-sess But openssl's base64 can't decode the string, so perhaps there is something wrong: $ echo -n bm9uY2U9IkVZMEI5anR4NlNsc0tQSGhHTGovNmI4WW1qQ3BadDZCL1RGUXAva21kUEU9IixyZWFsbT0icGFuZG9yYS5jb25lY3RpdmEiLHFvcD0iYXV0aCxhdXRoLWludCxhdXRoLWNvbmYiLGNpcGhlcj0icmM0LTQwLHJjNC01NixyYzQsZGVzLDNkZXMiLG1heGJ1Zj00MDk2LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz | openssl base64 -d $ If I query this same server from another machine with previous sasl, it works. I'll try now downgrading sasl.
