FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 05-19-2010, 11:19 AM
Roland Schwingel
 
Default SASL auth problem on bind with Mac OS X 10.4

Hi...



Sorry to follow up on my own post but
I figured it out.



> 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 comparison problem?



It is indeed the hash problem.

When I switch my password storing to
cleartext (BRR!) mac os x 10.4 can log in.

But this is nothing I want to have.
Is it true that Apple's OpenDirectory Servers are also storing

their passwords in cleartext? Can someone
with access to an OpenDirectory Server

verify this?



I don't want to store clear text passwords...


Has anyone else 389ds running with Mac
OS X 10.4 clients and managed to use it without

cleartext passwords?



Thanks,



Roland

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-19-2010, 11:32 AM
Per Qvindesland
 
Default SASL auth problem on bind with Mac OS X 10.4

Hi

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?

Per
On Wed, 2010-05-19 at 12:45 +0200, Roland Schwingel wrote:
>
> Hi...
>
> 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
> (mechanism CRAM-MD5).
>
> Mac -> 389DS: bindrequest with CRAM-MD5 to get credentials
> 389DS -> Mac: bindresponse with md5 credentials (eg.
> "<3051212195.15971967@host.domain>")
> Mac -> 389DS: bindrequest CRAM-MD5 with user and hashed password (eg.
> "roland b98c....")
> 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
> comparison problem?
>
> Thanks in advance,
>
> Roland
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-19-2010, 11:41 AM
Roland Schwingel
 
Default SASL auth problem on bind with Mac OS X 10.4

Hi Per,



Thanks for your reply.



389-users-bounces@lists.fedoraproject.org wrote on
19.05.2010 13:32:36:

> Is the ldap server configured for sasl?

Yes.



> 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?

This is what I try to figure out right now. I am just
searching where

to switch of some SASL methods (or SASL at all) in
389ds. Do you know

where this can be done. Haven't found anything yet
(beside of the ./configure

switches). I am searching something which does not
require a recompile.



> also did you reboot the mac box

> after configuring the ldap login?

Sure. But it was reproducable without reboot. If my password was

stored cleartext I could log in. If I changed it back
to SSHA or MD5

login was no longer possible.



Roland

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-19-2010, 11:42 AM
Per Qvindesland
 
Default SASL auth problem on bind with Mac OS X 10.4

Hi

Sorry I did not see that you had already answered your own mail

I believe that it supports Shadow Hash and Password Server since version
10.2

Per
On Wed, 2010-05-19 at 13:19 +0200, Roland Schwingel wrote:
> OpenDirectory

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-19-2010, 12:51 PM
Roland Schwingel
 
Default SASL auth problem on bind with Mac OS X 10.4

Hi....



> 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?

As I found no other way to test it I moved away my
libcrammd5.so on my

389ds box and restarted dirsrv. CRAM-MD5 was no longer
in the list of

supported methods.



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.




Anyway:

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.



Roland

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-19-2010, 04:36 PM
Rich Megginson
 
Default SASL auth problem on bind with Mac OS X 10.4

Roland Schwingel wrote:
>
> Hi....
>
> > 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?
> As I found no other way to test it I moved away my libcrammd5.so on my
> 389ds box and restarted dirsrv. CRAM-MD5 was no longer in the list of
> supported methods.
>
> 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?

Note that Digest-MD5 requires that the directory server store the
password in clear text. This is because the directory server must use
the clear text password to generate the challenge for the client. This
prevents any clear text passwords from being sent across the wire, as is
done with a regular simple DN and password BIND operation.
>
>
> Anyway:
> 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
>
> Roland
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-19-2010, 08:29 PM
Roland Schwingel
 
Default SASL auth problem on bind with Mac OS X 10.4

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.



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.



> > 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?

So they could automatically be disabled by dirsrv
if the password policy is set

to something different than cleartext? Or am I wrong?



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 ... ;-)



Roland

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-19-2010, 08:50 PM
Rich Megginson
 
Default SASL auth problem on bind with Mac OS X 10.4

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

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 03:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org