Hi,
I've been looking through the archives for information, but I haven't stumbled on a solution to my problem.
I'm running ds-389 (389-ds-base-1.3.4.0) on a centos 7 box (CentOS Linux release 7.2.1511). I have a centos OS client configured using SSL/TLS which queries the LDAP server. Per a previous thread, I configured the memeberOf plugin and all seems to be working properly.
I have a php script that will run on the client and change the LDAP password for the user. The problem is, the script looks for the SSHA has of the password when an ldapsearch is issued.
However, when I issue a general ldapsearch (anonymously) I don't get the userpassword field. I read in your archives that I might have to be the "directory manager" user in order to see the hashed password. I've been playing around with the ldapsearch syntax, but I can't quite get it right.
Anyway, my question is, can I set a flag in 389-ds that will display the hashed userpassword? I think that will solve my problem with the php script returning an error that it can't retrieve the old password.
Thanks,
houser@nso.edu wrote:
Hi,
I've been looking through the archives for information, but I haven't stumbled on a solution to my problem.
I'm running ds-389 (389-ds-base-1.3.4.0) on a centos 7 box (CentOS Linux release 7.2.1511). I have a centos OS client configured using SSL/TLS which queries the LDAP server. Per a previous thread, I configured the memeberOf plugin and all seems to be working properly.
I have a php script that will run on the client and change the LDAP password for the user. The problem is, the script looks for the SSHA has of the password when an ldapsearch is issued.
However, when I issue a general ldapsearch (anonymously) I don't get the userpassword field. I read in your archives that I might have to be the "directory manager" user in order to see the hashed password. I've been playing around with the ldapsearch syntax, but I can't quite get it right.
Anyway, my question is, can I set a flag in 389-ds that will display the hashed userpassword? I think that will solve my problem with the php script returning an error that it can't retrieve the old password.
IMHO you should fix the script, not allow the hash to be read. You really want anonymous users to be able to get the password hash for every user in LDAP?
rob
Hi Rob,
I appreciate the comment, and that would be a concern, but user's don't have login access to the client system. The php script is written to allow a friendly remote interface for the nonlinux user to be able to change their password.
On 2/22/16 2:00 PM, Rob Crittenden wrote:
houser@nso.edu wrote:
Hi,
I've been looking through the archives for information, but I haven't stumbled on a solution to my problem.
I'm running ds-389 (389-ds-base-1.3.4.0) on a centos 7 box (CentOS Linux release 7.2.1511). I have a centos OS client configured using SSL/TLS which queries the LDAP server. Per a previous thread, I configured the memeberOf plugin and all seems to be working properly.
I have a php script that will run on the client and change the LDAP password for the user. The problem is, the script looks for the SSHA has of the password when an ldapsearch is issued.
However, when I issue a general ldapsearch (anonymously) I don't get the userpassword field. I read in your archives that I might have to be the "directory manager" user in order to see the hashed password. I've been playing around with the ldapsearch syntax, but I can't quite get it right.
Anyway, my question is, can I set a flag in 389-ds that will display the hashed userpassword? I think that will solve my problem with the php script returning an error that it can't retrieve the old password.
IMHO you should fix the script, not allow the hash to be read. You really want anonymous users to be able to get the password hash for every user in LDAP?
rob
389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
On Mon, 2016-02-22 at 14:25 -0700, Janet Houser wrote:
Hi Rob,
I appreciate the comment, and that would be a concern, but user's don't have login access to the client system. The php script is written to allow a friendly remote interface for the nonlinux user to be able to change their password.
There shouldn't be the need to read the password field before you change it. You should just need to bind, then issue the password change extended operation.
If *must* read the userPassword field, I strong advise that you do not make this for anonymous.
You should create a service account (simpleSecurityObject), and give only that dn an aci with read access to the hash.
I still *strongly* advise against this, as you should not need to your application to behave like this to change a password.
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.
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.
Thanks for the quick response. Did I mention I hate PHP?
On 2/22/16 4:05 PM, William Brown wrote:
On Mon, 2016-02-22 at 14:25 -0700, Janet Houser wrote:
Hi Rob,
I appreciate the comment, and that would be a concern, but user's don't have login access to the client system. The php script is written to allow a friendly remote interface for the nonlinux user to be able to change their password.
There shouldn't be the need to read the password field before you change it. You should just need to bind, then issue the password change extended operation.
If *must* read the userPassword field, I strong advise that you do not make this for anonymous.
You should create a service account (simpleSecurityObject), and give only that dn an aci with read access to the hash.
I still *strongly* advise against this, as you should not need to your application to behave like this to change a password.
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)%C2%A0%C2%A0it 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.
Hi,
Here is a script I used with 389 that worked fine for me a while back: http://ltb-project.org/wiki/documentation/self-service-password
Greetings, Vincent
On Tue, Feb 23, 2016 at 2:25 AM, William Brown wibrown@redhat.com 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.
-- Sincerely,
William Brown Software Engineer Red Hat, Brisbane
-- 389 users mailing list 389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
Hi Vincent,
Thanks for the link! It's much appreciated. I'm afraid my PHP skills leave a lot to be desired.... did I mention I hate PHP? ;-)
On 2/23/16 1:14 AM, Vincent Gerris wrote:
Hi,
Here is a script I used with 389 that worked fine for me a while back: http://ltb-project.org/wiki/documentation/self-service-password
Greetings, Vincent
On Tue, Feb 23, 2016 at 2:25 AM, William Brown <wibrown@redhat.com mailto:wibrown@redhat.com> 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)
That's my take on it too. It does the initial bind anonymously, but from the write statements it looks like it's finding the user properly, and the password. It looks to go through a second bind to change the password and it's looking for the hashed password. Since this isn't a field that's shown with an ldap search, it's failing.
I had tried to modify the script to not require the hashed password field, but my php skills are.... lacking..... Did I mention I hate PHP?
> > 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.
Thanks for the steps and pointers, it helps. I'll see if I can update the script. The link you sent should help me code the appropriate commands. Yeah... did i mention I hate PHP? :-)
Cheers,
-- Sincerely, William Brown Software Engineer Red Hat, Brisbane -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
Hi Janet,
You're welcome. When it comes to these things that many people use, an online search will help to find you what you need often.
Let us know how it works out.
Greetings, Vincent On 23 Feb 2016 14:54, "Janet Houser" houser@nso.edu wrote:
Hi Vincent,
Thanks for the link! It's much appreciated. I'm afraid my PHP skills leave a lot to be desired.... did I mention I hate PHP? ;-)
On 2/23/16 1:14 AM, Vincent Gerris wrote:
Hi,
Here is a script I used with 389 that worked fine for me a while back: http://ltb-project.org/wiki/documentation/self-service-password
Greetings, Vincent
On Tue, Feb 23, 2016 at 2:25 AM, William Brown wibrown@redhat.com 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)
That's my take on it too. It does the initial bind anonymously, but from the write statements it looks like it's finding the user properly, and the password. It looks to go through a second bind to change the password and it's looking for the hashed password. Since this isn't a field that's shown with an ldap search, it's failing.
I had tried to modify the script to not require the hashed password field, but my php skills are.... lacking..... Did I mention I hate PHP?
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.
Thanks for the steps and pointers, it helps. I'll see if I can update the script. The link you sent should help me code the appropriate commands. Yeah... did i mention I hate PHP? :-)
Cheers,
-- Sincerely,
William Brown Software Engineer Red Hat, Brisbane
-- 389 users mailing list 389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
-- 389 users mailing list 389-users@%(host_name)shttp://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
-- 389 users mailing list 389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
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.
On Tue, 2016-02-23 at 06:59 -0700, Janet Houser wrote:
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?
Sure, it would be good to have for any one in the future with a similar problem.
Hi,
I'm using ds-389 (Version 1.3.4.0; Build number 2015.343.1254) on a CentOS 7 Server (release 7.4.1708). A week ago I performed a "yum update" on my system and now I'm finding that I can't update (or set) user passwords using the "passwd" or "ldappasswd" commands when the "Password Syntax" (i.e. Check password syntax) policies are enabled.
I can authenticate fine to a server which is slaved into the ds-389 server, but issuing the command "passwd" gives the following error:
--$ passwd Changing password for user jdow. (current) LDAP Password: New password: Retype new password: password change failed: Constraint violation passwd: Authentication token manipulation error
Likewise, I use to be able to run the following command to update a user's password from a server:
ldappasswd -h themaster -p 389 -ZZ -D "cn=Directory Manager" -w AdminsPassword -s 'UserPassword' "uid=jdoe,ou=People,dc=mydomain,dc=edu"
This command now fails with the erro
Result: Constraint violation (19 Additional info: Failed to update password
I had a password policy enabled on my domain subtree but I removed it. I then went under "Configuration --> Data" and tried to configure a global password policy instead. Each result in the same errors shown above whenever I try to enable "Check password syntax".
There's not a great deal of info in /var/log/dirsrv, but in the access file I see the following when I run the ldappasswd command:
[14/May/2018:10:37:03.173038139 -0600] conn=104 fd=110 slot=110 connection from 172.18.194.60 to 172.18.194.4 [14/May/2018:10:37:03.173283856 -0600] conn=104 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin" [14/May/2018:10:37:03.173454544 -0600] conn=104 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [14/May/2018:10:37:03.267493753 -0600] conn=104 TLS1.2 256-bit AES [14/May/2018:10:37:03.267938436 -0600] conn=104 op=1 BIND dn="cn=Directory Manager" method=128 version=3 [14/May/2018:10:37:03.268224050 -0600] conn=104 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [14/May/2018:10:37:03.268672168 -0600] conn=104 op=2 EXT oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_plugin" [14/May/2018:10:37:03.269346086 -0600] conn=104 op=2 RESULT err=19 tag=120 nentries=0 etime=0 [14/May/2018:10:37:03.269832211 -0600] conn=104 op=3 UNBIND [14/May/2018:10:37:03.269850488 -0600] conn=104 op=3 fd=110 closed - U1
Which looks like it must be failing when the passwd_modify_plugin is run.
I noticed in /etc/dirsrv/slapd-myserver that there were new schema ldif files added during the yum update and I'm wondering if one is stepping on my password policy.
I'm going to try to remove them from the directory (and store them elsewhere) to see if the issue disappears, but I'd rather not use a hammer to fix a problem.
I'm grateful for any suggestions.
Thanks,
Sorry folks. I thought I was starting a new thread, not adding to the old one. I'll try to delete this.
389-users@lists.fedoraproject.org
-
houser＠nso.edu -
Janet Houser
-
Rob Crittenden -
Vincent Gerris -
William Brown