*solved*: saslauthd -a ldap ( possible BO / bug with long userpassword strings ? )


Subject: *solved*: saslauthd -a ldap ( possible BO / bug with long userpassword strings ? )
From: Jose Miguel Varet (varet at alvirhosting dot com)
Date: Wed Apr 16 2003 - 17:58:01 EDT


You bet, Igor, you've got it. Setting auth_method to "bind" instead of
"custom" does the trick : after restarting saslauthd, now I can authenticate
via saslauthd even with {crypt} long hashes in userPassword attribute. The
"size read error" no longer happens.

As you said, ldd'ing saslauthd looks like it's linked against those rogue
openSSL dinamyc libraries which have a 56bit-only version of crypt().
Anyway, this is irrelevant now, since I've really got no need of using
"custom" auth_method , if "bind" is to accept my md5 {crypt} hashes.
Now everything works perfectly.

> Yup. Perhaps my docs are not clear so I welcome any help. Openldap also
> uses userPassword for authentication.

hmm...not at all. sasl's docs are, at the very least, sufficient. Truth is,
I often read ppl complaining about how "obscure" and "undocumented" the
whole sasl+ldap+tls thingie is, etc... hey, it's just RTFM and a little of
experimentation. I think you are doing a great - for many of us, unpayable -
work.

Thanks for your time,

            Jose,

----- Original Message -----
From: "Igor Brezac" <igor at ypass dot net>
To: "Jose Miguel Varet" <varet at alvirhosting dot com>
Cc: <cyrus-sasl at lists dot andrew dot cmu dot edu>
Sent: Wednesday, April 16, 2003 8:57 PM
Subject: Re: saslauthd -a ldap ( possible BO / bug with long userpassword
strings ? )

>
> On Wed, 16 Apr 2003, Jose Miguel Varet wrote:
>
> > >Unfortunately, openssl 0.9.6b is the problem. Read (section Note about
> > >OpenSSL and crypt()), http://www.openldap.org/faq/data/cache/185.html.
> > >This applies to saslauthd/ldap build or any other app that uses crypt()
> > >and openssl.
> >
> >
> > damn, this openssl issue seems to be the root of the problem, good
catching.
> >
> > As for "auth_method : custom", from saslauthd/LDAP_SASLAUTHD doc file
:
> >
> > "
> > ldap_auth_method: <bind> <bind|custom|fastbind>
> > Specify an authentication method.
> >
> > The bind method uses the LDAP simple bind facility to verify the
> > password. This is the default.
> >
> > The custom method uses userPassword attribute to verify the
> > password.
> > Currently, {CRYPT} hash is supported.
> > "
> >
> > since I use openLdap's userpassword attribute in order to store user
> > passwords, I supposed this was not "simple bind". Besides, I need the
> > {crypt} hash, since I'm migrating shadow passwords ( which are md5-based
> > {crypt} ) directly to the userpassword attribute.
> > Frankly, I've not tried the "auth_method: bind" . By reading this doc, I
> > always thought that "auth_method : custom" was the way to go when using
> > userpassword attribute . Perhaps I'm wrong here?
>
> Yup. Perhaps my docs are not clear so I welcome any help. Openldap also
> uses userPassword for authentication.
>
> -Igor
>
>
> >
> > Greets,
> >
> > Jose,
> >
> >
> > ----- Original Message -----
> > From: "Igor Brezac" <igor at ipass dot net>
> > To: "Jose Miguel Varet" <varet at alvirhosting dot com>
> > Cc: <cyrus-sasl at lists dot andrew dot cmu dot edu>
> > Sent: Wednesday, April 16, 2003 6:55 PM
> > Subject: Re: saslauthd -a ldap ( possible BO / bug with long
userpassword
> > strings ? )
> >
> >
> > >
> > > On Wed, 16 Apr 2003, Jose Miguel Varet wrote:
> > >
> > > > Exactly, Mr. Chu is right. Old crypt() implementations hashed the
> > passwords
> > > > in 13 characters, but new crypt()'s include a MD5-based hash, wich
looks
> > > > like as long as that one I've provided as an example.
> > > >
> > > > Igor, I just saw your last mail : my OS is Linux 2.4.20 , an
heavily
> > > > patched RedHat 7.3 .
> > > > /usr/local/etc/saslauthd.conf , effectively, must have "custom"
> > >
> > > Why?
> > >
> > > > auth_method. Mine looks like :
> > > >
> > > > --------------------------
> > > > ldap_servers: ldap://ldap.testdomain.com
> > > > ldap_search_base: dc=testdomain,dc=com
> > > > ldap_auth_method: custom
> > >
> > > change this to (this should work unless your openldap uses wrong
crypt()):
> > >
> > > ldap_auth_method: bind
> > >
> > > > ldap_bind_dn: cn=Manager,dc=testdomain,dc=com
> > > > ldap_bind_pw: manager_secret
> > > > --------------------------
> > > >
> > > > if it's of interest, my openssl version isn't a self-compiled one (
> > > > everything else it's ) , but a just-rpm-it package , openSSL version
> > > > 0.9.6b-18
> > > > I'm aware that this isn't the latest version, and that it has
several
> > > > security issues ( timing RSA attack, etc. ) but since this is an
> > internal
> > > > test machine protected from the exterior, I didn't bothered
> > > > upgrading/compiling to the latest openSSL.
> > >
> > > Unfortunately, openssl 0.9.6b is the problem. Read (section Note
about
> > > OpenSSL and crypt()), http://www.openldap.org/faq/data/cache/185.html.
> > > This applies to saslauthd/ldap build or any other app that uses
crypt()
> > > and openssl.
> > >
> > > > as you say, we know that crypt() isn't the problem , since
saslauthd -->
> > > > pam --> ldap with md5-crypt will woek perfectly. It's direct path ,
> > > > saslauthd --> ldap, wich will do the "read size error". This will
not
> > happen
> > > > when the password is a *short* string.
> > > >
> > > > Pity, I do not have access to a old-style 13-char crypt() password
right
> > > > now, since all of my servers use the new long-md5 crypt function. If
I
> > had
> > > > one of these, I'd bet my left hand, that saslauthd ---> ldap via
{crypt}
> > > > would work OK, since the userpassword LDAP hash would be a shorter
> > string .
> > > > But again, this is only pure speculation on my hand... developers
have
> > the
> > > > last word, of course.
> > >
> > > If you have to use 'ldap_auth_method: custom', you need to fix
openssl.
> > > Openssl 0.9.7x is fine. Or build cyrus-sasl with --without-openssl.
> > >
> > > --
> > > Igor
> > >
> >
> >
>
> --
> Igor
>







Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD