Roland Schwingel wrote: > > 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. If it is searching for the userPassword attribute, then it must be doing something like linux pam_ldap does when you have pam_password md5 or something like that - it is attempting to do the password comparison locally rather than sending the cleartext password to the server and letting the server perform the BIND. I am not at all familiar with Mac auth config, but it is possible that * there is some mac auth config setting that you tell it to perform the bind on the server * mac might not want to perform a simple bind over an unencrypted channel - that is, you may have to configure tls/ssl on the DS side and on the mac side before it will allow you to perform a simple password auth, without sending the clear text password over the wire > > 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. Weird. > > > > 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? Right. > > So they could automatically be disabled by dirsrv if the password > policy is set > to something different than cleartext? Or am I wrong? You are correct. But technically, all LDAPv3 servers are supposed to support Digest-MD5. > > 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 ... ;-) It's possible, but the sasl digest/challenge stuff is handled internally by the cyrus sasl code (on the DS side, anyway) - not sure how that would work. > > Roland > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
