Hi Rich...

Thanks for your reply!

> > I rebooted also my mac. My mac no longer issues a CRAM-MD5 SASL bind
> > that is the good news, but it does not switch over to a simple bind using
> > a binddn. It just does no bind anymore. What a mess.
> So the mac finds that CRAM-MD5 is not available, and does nothing at all?
Mac OS X 10.4 behaves that way. At least as far as I can tell from my
wireshark sniffing and the 389ds access log file. It just does some searches
for user attributes (including userPassword), but no bind for authorization
as user just an anonymous bind ahead of all this which does not retrieve
the password due to the anonymous aci entry of 389ds. I removed the restriction
to not deliver the userPassword in searches with anonymous bind but it did not
help either.

I consider this to be a bug in 10.4. With Mac OS X 10.5 and 10.6 this
has changed. There it tries the SASL auth first (if available) and if
it fails (or it is not available) it is doing a simple bind which then
succeeds.

> > Maybe I haven't found it but an option to enable/disable certain SASL
> > methods within 389ds would IMHO be good to have for other situations
> > where you can come into these needs.
> It's on the Roadmap - http://directory.fedoraproject.org/wiki/Roadmap
Nice to read... Thanks.... :-)

But generally speaking - with thinking while typing:
If the password policy is set to something else than cleartext
SASL MD5 methods do not make sense at all. An auth using these methods will not succeed. Right?
So they could automatically be disabled by dirsrv if the password policy is set
to something different than cleartext? Or am I wrong?

Hmm... Or would it work (at least if the password is stored in md5 not s(sha))
if the same salt is used in the sasl md5 challenge supplied to the client? If the
client uses this supplied salt for hashing the password, the sent result should
be comparable with the stored md5 hashed password using that same salt. So a SASL
MD5 auth would be possible than. Maybe I am wrong and it is already much too late
for me to think about these things today ... ;-)

Roland