Is the ldap server configured for sasl? it would seem that the osx
client tries with sasl and only sasl when that does not work it unbinds
and does not try simple bind, it may see that the ldap server is showing
sasl as a available authentication method but it is not really
available, can you exec login into it? also did you reboot the mac box
after configuring the ldap login?
On Wed, 2010-05-19 at 12:45 +0200, Roland Schwingel wrote:
With Mac OS X 10.4 I got a problem when user wants to log in into an
account hosted in 389ds.
I presumably tracked the problem down to a SASL auth problem.
Using wireshark I recorded the traffic between my mac os x 10.4
machine and my 389ds server.
On logon the mac tries a bind without binddn but with SASL auth
Mac -> 389DS: bindrequest with CRAM-MD5 to get credentials
389DS -> Mac: bindresponse with md5 credentials (eg.
Mac -> 389DS: bindrequest CRAM-MD5 with user and hashed password (eg.
389DS -> MAC: bindresponse invalidcredentials ("SASL(-13): user not
found: no secret in database")
Mac says sorry no logon...
With Mac OS X 10.5/10.6 it works. It also tries the CRAM-MD5 SASL
auth. But when it failes it alternatively tries a bind with a binddn
(eg. "uid=roland,ou=people,dc=domain") which is successful.
Unfortunately I have a bigger amount of mac os x 10.4 machines which I
cannot migrate to 10.5 oder later so I need to support this. I yet did
not find a way to convince mac os x 10.4 to use a binddn for auth.
Any clue what is wrong here? Is this a SASL uid mapping problem or is
it because the user passwords are stored SSHA hashed? I already tried
to change the stored password from SSHA to MD5, but it does not help
SASL auth fails with the same error message. Or is this a hash
Thanks in advance,
389 users mailing list