Thanks for your reply!
> I rebooted also my mac. My mac no longer issues a CRAM-MD5 SASL
> that is the good news, but it does not switch over to a simple bind
> 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
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
for user attributes (including userPassword), but no bind for
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
to not deliver the userPassword in searches with anonymous bind but it did
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
> Maybe I haven't found it but an option to enable/disable
> 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
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
to something different than cleartext? Or am I wrong?
Hmm... Or would it work (at least if the password is stored in md5 not
if the same salt is used in the sasl md5 challenge supplied to the client?
client uses this supplied salt for hashing the password, the sent result
be comparable with the stored md5 hashed password using that same salt. So
MD5 auth would be possible than. Maybe I am wrong and it is already much
for me to think about these things today ... ;-)