Re: supportedSaslMechanisms during ADD

On 13 Oct 2014, at 17:12, VANOLE, MICHAEL J <[email protected]> wrote:

> Thanks Dieter,
>=20
> Our ldap is compiled with sasl, but I don't think I asked the question =
correctly.
>=20
> Sun One must be doing the MD5 (or whatever) encryption locally and =
applying the userPassword that way. I just have to specify what I want =
via the supportedSaslMechanisms attribute. Openldap does not like this.

Ah, I think you're talking about password hashing (see RFC 2307 5.3), =
*not* SASL. Password hashing is generally incompatible with SASL. It =
just so happens that you are using MD5 to hash your password, and you =
found a SASL mechanism also with MD5 in the name...

NB the unsalted version of MD5 is really insecure and you should not use =
it for passwords. Google for "rainbow tables".

> 2. This excellent help: =
http://blog.gauner.org/blog/2010/12/19/handling-salted-passwords-in-perl/ =
using the ldap_md5 subroutine (I'm sure the others work just as well)
> 	$userpass =3D "{MD5}" . pad_base64( =
Digest::MD5::md5_base64($clearpass) );
>=20
> Then pass then as shown below. Both work great, though I'm sure there =
is something to be cautious about.

Yes there is definitely an issue with doing that. The server may not =
allow the client to pre-encode the password, and it may *require* that =
you send it the plaintext password in the add/modify operation so that =
it can do some password validation (quality checking) on the value. That =
cannot be performed if the client has pre-encoded the password.

Anyway, this is mostly not related to Net::LDAP - you need to talk to =
the OpenLDAP folks to see if they will help you.

Chris=