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