[389-users] SASL auth problem on bind with Mac OS X 10.4

[Rich Megginson]

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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users