Okay. At this point I need to duplicate the configuration to diagnose the issue further, but I don’t have much time to do so. An alternate, can you use a read only replica with referral’s enabled instead? > On 1 Mar 2019, at 00:13, wodel youchi <wodel.youchi@xxxxxxxxx> wrote: > > Hi, > > I did a test using ldappasswd, and it didn't work, I didn't get any error message from the CLI, and the $? variable returned 0, but the password has not been changed. > After issuing the command I tried an ldapsearch with the Adam user using the new-password and it didn't work "Invalid credentials", but using the old password the ldapsearch worked. > > 4) Modify userPassword from the slave using ldappasswd > ldappasswd -D "uid=lnadmin,ou=special users,dc=example,dc=com" -W -p 389 -h idm02.example.com -x -ZZ -S "uid=adam,ou=people,dc=example,dc=com" > New password: > Re-enter new password: > Enter LDAP Password: > > Result : echo $? returns 0 but the userPassword is not changed > ldapsearch -h 127.0.0.1 -D "uid=adam,ou=people,dc=example,dc=com" -b "ou=people,dc=example,dc=com" -x -w newpass > ldap_bind: Invalid credentials (49) > > Log from the slave : > Access : > [25/Feb/2019:15:08:09.356356670 +0100] conn=61 fd=67 slot=67 connection from 192.168.40.102 to 192.168.40.102 > [25/Feb/2019:15:08:09.356588390 +0100] conn=61 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin" > [25/Feb/2019:15:08:09.356724270 +0100] conn=61 op=0 RESULT err=0 tag=120 nentries=0 etime=0.0000286023 > [25/Feb/2019:15:08:09.371819345 +0100] conn=61 TLS1.2 256-bit AES-GCM > [25/Feb/2019:15:08:13.222914479 +0100] conn=61 op=2 BIND dn="uid=lnadmin,ou=special users,dc=example,dc=com" method=128 version=3 > [25/Feb/2019:15:08:13.225541735 +0100] conn=61 op=2 RESULT err=0 tag=97 nentries=0 etime=0.0002835224 dn="uid=lnadmin,ou=special users,dc=example,dc=com" > [25/Feb/2019:15:08:13.225980566 +0100] conn=61 op=3 EXT oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_plugin" > [25/Feb/2019:15:08:13.235729939 +0100] conn=61 op=3 RESULT err=0 tag=120 nentries=0 etime=0.0009925134 > [25/Feb/2019:15:08:13.236534952 +0100] conn=61 op=4 UNBIND > [25/Feb/2019:15:08:13.236573244 +0100] conn=61 op=4 fd=67 closed - U1 > > Log from the master: > Access : > [25/Feb/2019:15:08:45.318668395 +0100] conn=31 fd=87 slot=87 SSL connection from 192.168.40.102 to 192.168.40.101 > [25/Feb/2019:15:08:45.323871405 +0100] conn=31 TLS1.2 256-bit AES-GCM > [25/Feb/2019:15:08:45.324437562 +0100] conn=31 op=0 BIND dn="uid=lnadmin,ou=special users,dc=example,dc=com" method=128 version=3 > [25/Feb/2019:15:08:45.324636529 +0100] conn=31 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0005924433 dn="uid=lnadmin,ou=special users,dc=example,dc=com" > > > Regards. > > Le jeu. 28 févr. 2019 à 01:48, William Brown <wbrown@xxxxxxx> a écrit : > > > > On 27 Feb 2019, at 19:25, wodel youchi <wodel.youchi@xxxxxxxxx> wrote: > > > > Hi, > > > > What do you mean by : enable password-migration mode? can you elaborate, where do I have to enable it? on the master on the slave? > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/core_server_configuration_reference#nsslapd-allow-hashed-passwords > > This is the setting I am referring to. > > > > > In my previous post I did test changing the password using both clear an pre-hashed password, and it didn't work. > > > > 2) Modify userPassword from the slave using clear text password > > ldapmodify -h localhost -p 389 -D "uid=lnadmin,ou=special users,dc=example,dc=com" -w pass -x <<EOF > > dn: uid=adam,ou=people,dc=example,dc=com > > changetype: modify > > replace: userPassword > > userPassword: password > > EOF > > modifying entry "uid=adam,ou=people,dc=example,dc=com" > > ldap_modify: Constraint violation (19) > > additional info: database configuration error - please contact the system administrator > > > > > > 3) Modify userPassword from the slave using encrypted password > > ldapmodify -h localhost -p 389 -D "uid=lnadmin,ou=special users,dc=example,dc=com" -w wolverine -x <<EOF > > dn: uid=adam,ou=people,dc=example,dc=com > > changetype: modify > > replace: userPassword > > userPassword: {SSHA}gvg6KehxZNYcLnLrAJrI0TzWpQzXH0oe > > EOF > > modifying entry "uid=adam,ou=people,dc=example,dc=com" > > ldap_modify: Constraint violation (19) > > additional info: invalid password syntax - passwords with storage scheme are not allowed > > > > Passwords have some special handling. Does a ldappasswd extended operation on the replica work? > > > > > > Regards. > > > > Le mer. 27 févr. 2019 à 00:44, William Brown <wbrown@xxxxxxx> a écrit : > > > > > > > On 26 Feb 2019, at 00:23, wodel youchi <wodel.youchi@xxxxxxxxx> wrote: > > > > > > 3) Modify userPassword from the slave using encrypted password > > > ldapmodify -h localhost -p 389 -D "uid=lnadmin,ou=special users,dc=example,dc=com" -w wolverine -x <<EOF > > > dn: uid=adam,ou=people,dc=example,dc=com > > > changetype: modify > > > replace: userPassword > > > userPassword: {SSHA}gvg6KehxZNYcLnLrAJrI0TzWpQzXH0oe > > > EOF > > > modifying entry "uid=adam,ou=people,dc=example,dc=com" > > > ldap_modify: Constraint violation (19) > > > additional info: invalid password syntax - passwords with storage scheme are not allowed > > > > > > IIRC you aren’t able to set a password into the field that is pre-hashed. You either need to enable password-migration mode, or you should supply the plaintext password and the server hashes it for you. Does that fix the issue? > > > > — > > Sincerely, > > > > William Brown > > Software Engineer, 389 Directory Server > > SUSE Labs > > > > — > Sincerely, > > William Brown > Software Engineer, 389 Directory Server > SUSE Labs > — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
