Thanks to all who replied. I did not realize or remember that the output of ldapsearch was base64 encoded for userPassword. Decoding gives me the string I expect, so it is set correctly in the database. Since testsaslauthd works, I just need to get ldap to reference the saslauthd, which is still failing.
Regards, Chuck
On 09/03/2015 11:12 AM, Peter Heinemann wrote:
Note that the key as to whether it's base64 encoded is the double colon --
userPassword:: ijlkci0ij297clkjljk
In addition to Dan's technique, in a Linux (and perhaps other nixes) shell you can:
echo " ijlkci0ij297clkjljk " | base 64 -d ________________________________________ From: openldap-technical [openldap-technical-bounces@openldap.org] on behalf of Dan White [dwhite@cafedemocracy.org] Sent: Thursday, September 03, 2015 2:07 PM To: Chuck Theobald Cc: openldap-technical@openldap.org Subject: Re: Change userPassword
On 09/03/15 10:54 -0700, Chuck Theobald wrote:
I am finding it impossible to set user passwords to the form {SASL}name@ad.domain.my
ldapmodify can delete userPassword, and can add it again but ends of setting it to a hash despite trying password-hash {CLEARTEXT} and password-hash {SASL} in slapd.conf. And no, I am not using slapd.d.
By hash, I assume you mean base64 encoding, which is how ldapsearch displays contents of userPassword when retrieved. uudecode the contents to see the actual data.
Here's a simple perl script I use:
#!/usr/bin/perl
use MIME::Base64;
print decode_base64($ARGV[0]); print "\n";
If you are actually retrieving a crypt(3) style hash, verify you are not running ldapmodify with an extention (-E) and that you are not doing something strange with an overlay.
password-hash should only come into play when performing an ldap password extended operation, such as with ldappasswd.
Every post I find taunts me with things like "oh, set the userpassword to {SASL}blah@blah.com and it will Just Work". This simple step eludes me. I am seriously missing some thing quit easy.
-- Dan White