2010/7/4 Dan White <dwhite@xxxxxxx>
Cyrus SASL requires that shared secrets be stored within an auxprop store,
such as sasldb. Regardless of what your sasl_pwcheck_method configuration
is, sasl will always use your auxprop plugin(s) to service the DIGEST-MD5
plugin. To use DIGEST-MD5, you could use saslpasswd2 to store user
credentials within /etc/sasldb2.
saslauthd, and pam, cannot perform the required handshaking that DIGEST-MD5
requires, since the neither have knowledge of what the shared secret
(password) is.
Thanks for the explanation. When I think about it, it makes sense
that MD5 cannot work when it has to pass it on to another
auth service.
that MD5 cannot work when it has to pass it on to another
auth service.
More than likely you were dealing with clients that failed the DIGEST-MD5
authentication and then fell back to PLAIN or pre-sasl login.
If 'allowplaintext' is disabled in your imapd.conf, then PLAIN, LOGIN, and
pre-sasl login can only be achieved in the presence of TLS or some other
encryption. 'allowplaintext: 0' will prevent a clear text password from
being sniffed over the wire.
Yes. I don't know why one type of connection tries the next method
while non-TLS only did CRAM-MD5 and then failed. I'll fix it to not
reference the MD5 mech types.
In our case the webmail and cyrus are on the same subnet used only
in the data centre, so we are not concerned with access of data
over the wire. With a few thousand people accessing webmail,
I would be more concerned about the load of encrypting all that traffic
between Cyrus and Horde. We do use TLS on the Horde login screen.
--Donald
---- 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
