Hi William,
Thank you for looking into the issue. I appreciate the input. Vincent
sent along a script that should
help with modifying the current php files.
I appreciate your time and pointers on how to get things working. (Did I
mention I hate PHP? ;-) )
If I manage to get the script updated and working, would you like me to
send it along?
Cheers,
On 2/22/16 6:25 PM, William Brown wrote:
Ignore the blank message. Email fail.
On Mon, 2016-02-22 at 16:25 -0700, Janet Houser wrote:
Thanks William,
Hmmm.... then I'm puzzled why things are failing.
For a little more detail as to what's going on....
I was asked to install squirrelmail on a system so user's could read
their mail. I installed
the change_ldappasswd and everything appears working except for actually
changing the
password.
The system connects to my 389-ds server and a successful anonymous bind
occurs. It
reads my password properly because if I enter it wrong, it will tell me
so. But when I try to
change the password, I get an error saying it couldn't retrieve my old
password from the LDAP
server.
From an old post
(http://comments.gmane.org/gmane.mail.squirrelmail.user/28454) it claims
that this error means that the php script couldn't find the password
field in the search results.
I'm going off the assumption that because I don't see the userpassword
SSHA field when I do
a ldapsearch, this means it can't either, so it fails.
Okay, I'm thinking this is a pretty old script. See, what's trying to do is
likely to read the userPassword field into the PHP, then it will hash and strcmp
on the php side, if it's the same, it says "yeah, you are who you claim to be"
then it writes direct to the userPassword field (which we block in 389 anyway)
I'm hacking at the php script to put in print/echo statements to try to
pinpoint the problem, but
I'm thinking that it's doing a second bind to the LDAP server looking
for this field.
I was hoping to try to see if this was the case by making the field
available in a ldapsearch.
I'll turn my attention back to the php script since I'd rather not
compromise security on the
LDAP server.
Yeah, that's the risk here.
I think the best bet might be to re-write the script or look for an alternative.
You should probably be following this pattern:
ask the user for the password and username
anonymously search for the user via the username and get the dn.
Once you have the dn, do an ldap bind for dn with password.
If that FAILS returns errors about wrong passwords.
If that succeeds, you now have a connection bound as the user.
You can issue an ldap password change extended operation. There will be a php
library that does this already for you.
Once that succeeds, the new password is in place.
The reason for this:
First, you don't compromise the security of the userPassword attribute.
389 retains control of the hashing algo of the user, and it can apply password
policies to the account.
You can simulate this on a command line, with the tool:
ldappasswd
This conducts the steps above.
I hope that this helps you.
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
