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(a)gmail.com>
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(a)suse.de> a écrit :
> On 27 Feb 2019, at 19:25, wodel youchi <wodel.youchi(a)gmail.com> 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...
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(a)suse.de> a écrit :
>
>
> > On 26 Feb 2019, at 00:23, wodel youchi <wodel.youchi(a)gmail.com> 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