subject:"\[389\-users\] Re\: Update userpassword from consummer"

[389-users] Re: Update userpassword from consummer

2019-02-28 Thread William Brown

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  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.286023
> [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  a écrit :
> 
> 
> > On 27 Feb 2019, at 19:25, wodel youchi  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  < > 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  < > 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  a écrit :
> > 
> > 
> > > On 26 Feb 2019, at 00:23, wodel youchi  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  < > > dn:

[389-users] Re: Update userpassword from consummer

2019-02-28 Thread wodel youchi

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.286023
[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  a écrit :

>
>
> > On 27 Feb 2019, at 19:25, wodel youchi  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  < > 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  < > 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  a écrit :
> >
> >
> > > On 26 Feb 2019, at 00:23, wodel youchi  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  < > > 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
>

[389-users] Re: Update userpassword from consummer

2019-02-27 Thread William Brown



> On 27 Feb 2019, at 19:25, wodel youchi  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  < 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  < 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  a écrit :
> 
> 
> > On 26 Feb 2019, at 00:23, wodel youchi  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  < > 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
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

[389-users] Re: Update userpassword from consummer

2019-02-27 Thread wodel youchi

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?

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  < a écrit :

>
>
> > On 26 Feb 2019, at 00:23, wodel youchi  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  < > 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
>
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

[389-users] Re: Update userpassword from consummer

2019-02-26 Thread William Brown



> On 26 Feb 2019, at 00:23, wodel youchi  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  < 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
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

[389-users] Re: Update userpassword from consummer

2019-02-25 Thread wodel youchi

Hi,
I redid the configuration from scratch, and I've created a new user
(uid=lnadmin,ou=special users,dc=example,dc=com) and I gave him
administrative rights.
This new user belongs to the chained area.

I did some tests with this account to modify users attributes including the
userPassword attribute from the master server, and it works perfectly.

on the other hand, on the slave, modifying other attributes other than
userPassword works and the update is chained.
But modifying userPassword didn't work, and here are the results :

*1) Modify givenname from the slave*
ldapmodify -h localhost -p 389  -D "uid=lnadmin,ou=special
users,dc=example,dc=com" -w pass -x  < EOF
modifying entry "uid=adam,ou=people,dc=example,dc=com"

*Result* : the modification is done and chained to the master, but I get an
error shown in the error log on the slave (see below in bold-red)

*Log from the slave *:
*Access* :
[25/Feb/2019:14:56:06.577269198 +0100] conn=54 fd=67 slot=67 connection
from ::1 to ::1
[25/Feb/2019:14:56:06.577393763 +0100] conn=54 op=0 BIND
dn="uid=lnadmin,ou=special users,dc=example,dc=com" method=128 version=3
[25/Feb/2019:14:56:06.578398778 +0100] conn=54 op=0 RESULT err=0 tag=97
nentries=0 etime=0.0001044129 dn="uid=lnadmin,ou=special
users,dc=example,dc=com"
[25/Feb/2019:14:56:06.578704548 +0100] conn=54 op=1 MOD
dn="uid=adam,ou=people,dc=example,dc=com"
[25/Feb/2019:14:56:06.677356989 +0100] conn=55 fd=68 slot=68 SSL connection
from 192.168.40.101 to 192.168.40.102
[25/Feb/2019:14:56:06.684970522 +0100] conn=55 TLS1.2 256-bit AES-GCM
[25/Feb/2019:14:56:06.685359430 +0100] conn=55 op=0 BIND dn="cn=replication
manager,cn=config" method=128 version=3
[25/Feb/2019:14:56:06.685504876 +0100] conn=55 op=0 RESULT err=0 tag=97
nentries=0 etime=0.0008085105 dn="cn=replication manager,cn=config"
[25/Feb/2019:14:56:06.685951988 +0100] conn=55 op=1 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[25/Feb/2019:14:56:06.686522468 +0100] conn=55 op=1 RESULT err=0 tag=101
nentries=1 etime=0.641275
[25/Feb/2019:14:56:06.686921120 +0100] conn=55 op=2 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[25/Feb/2019:14:56:06.687436239 +0100] conn=55 op=2 RESULT err=0 tag=101
nentries=1 etime=0.630283
[25/Feb/2019:14:56:06.687958906 +0100] conn=55 op=3 EXT
oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop"
[25/Feb/2019:14:56:06.688118224 +0100] conn=55 op=3 RESULT err=0 tag=120
nentries=0 etime=0.245044
[25/Feb/2019:14:56:06.689082577 +0100] conn=55 op=4 MOD
dn="uid=adam,ou=people,dc=example,dc=com"
[25/Feb/2019:14:56:06.695724845 +0100] conn=54 op=1 RESULT err=0 tag=103
nentries=0 etime=0.0117138489
[25/Feb/2019:14:56:06.696481191 +0100] conn=54 op=2 UNBIND
[25/Feb/2019:14:56:06.696496220 +0100] conn=54 op=2 fd=67 closed - U1
[25/Feb/2019:14:56:06.702453879 +0100] conn=55 op=4 RESULT err=0 tag=103
nentries=0 etime=0.0013403378 csn=5c73f3f60001
[25/Feb/2019:14:56:06.834935702 +0100] conn=55 op=5 EXT
oid="2.16.840.1.113730.3.5.5" name="replication-multimaster-extop"
[25/Feb/2019:14:56:06.844701440 +0100] conn=55 op=5 RESULT err=0 tag=120
nentries=0 etime=0.0010011286



*Error : [25/Feb/2019:14:56:06.659891340 +0100] - ERR -
managed-entries-plugin - mep_mod_post_op - Unable to fetch postop
entry.[25/Feb/2019:14:56:06.680435055 +0100] - ERR - chaining database -
chaining_back_modify - modify (uid=adam,ou=people,dc=example,dc=com): post
betxn failed, error (-1)*


*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  < a écrit :

>
>
> > On 19 Feb 2019, at 00:54, Mark Reynolds  wrote:
> >
> >
> >
> > On 2/18/19 7:46 AM, wodel youchi wrote:
> >> Hi,
> >>
> >> I did a test, but unfortunately it didn't work for me.
> >>
> >> This is my LAB:
> >>  • 389DS Servers :
> >>  • OS CentOS7 all updates
> >>  • 389DS version 1.3.8.4-22
> >>  • domain : dc=example,dc=com
> >>  • users on : uid=%u,ou=people,dc=example,dc=com
> >>  • One master server (idm01.example.com) and one slave
> server (idm02.example.com).
> >>  • Replication configured for userRoot database
> (dc=example,dc=com)
> >>  • Replication uses this user cn=replication
> manager,cn=config
> >>  • Password Policy is configured.
> >>  • Mail server Zimbra 8.8.11
> >>  • OS CentOS7 all updates
> >>  • Zimbra FOSS 8.8.11.
> >>  • External authentication configured  using LDAP server
> >>  • Installation of ADPassword connector to allow
> change password from Zimbra WebUI
> >>  • External authentication was configured first on
> idm01.example.com to test that change pass works correctly.
> >>  • External authentication was modified to use
> idm02.example.com to

[389-users] Re: Update userpassword from consummer

2019-02-18 Thread William Brown



> On 19 Feb 2019, at 00:54, Mark Reynolds  wrote:
> 
> 
> 
> On 2/18/19 7:46 AM, wodel youchi wrote:
>> Hi,
>> 
>> I did a test, but unfortunately it didn't work for me.
>> 
>> This is my LAB:
>>  • 389DS Servers :
>>  • OS CentOS7 all updates
>>  • 389DS version 1.3.8.4-22
>>  • domain : dc=example,dc=com
>>  • users on : uid=%u,ou=people,dc=example,dc=com
>>  • One master server (idm01.example.com) and one slave server 
>> (idm02.example.com).
>>  • Replication configured for userRoot database 
>> (dc=example,dc=com)
>>  • Replication uses this user cn=replication manager,cn=config
>>  • Password Policy is configured.
>>  • Mail server Zimbra 8.8.11
>>  • OS CentOS7 all updates
>>  • Zimbra FOSS 8.8.11.
>>  • External authentication configured  using LDAP server
>>  • Installation of ADPassword connector to allow change 
>> password from Zimbra WebUI
>>  • External authentication was configured first on 
>> idm01.example.com to test that change pass works correctly.
>>  • External authentication was modified to use 
>> idm02.example.com to test chain modification.
>> Result : 
>>  • Could not change user password using chain modification from 
>> idm02.example.com
>> 
>> Steps of configuration of chain modification :
>>  • On master 389DS server
>>  • Create a new ACI on dc=example,dc=com : (targetattr = 
>> "*")(version 3.0; acl "Proxied authorization for database links";
>>allow (proxy) (userdn = "ldap:///cn=Replication Manager,cn=config");)
>>  • Create cn=replication manager,cn=config on the master after 
>> getting this error from the slave's log : 
>>  • [17/Feb/2019:14:31:30.151680780 +] - ERR - 
>> slapi_ldap_bind - Error: could not bind id [cn=replication 
>> manager,cn=config] authentication mechanism [SIMPLE]: error 32 (No such 
>> object)
> This means cn=replication manger does not exist on the slave server, but 
> looks like you added it later…

This explanation is a good candidate to be added to the error message in the 
log itself ...

>>  • [17/Feb/2019:14:31:30.153315712 +] - ERR - 
>> chaining database - cb_get_connection - Can't bind to server 
>>  port <636>. (LDAP error 32 - No such object; Netscape 
>> Portable Runtime error 0 - no error)
>> [17/Feb/2019:14:31:30.154527249 +] - ERR - chaining database - 
>> chaining_back_modify - cb_get_connection failed (-11) Connect error
>>  • On slave 389DS server
>>  • Create the chain entry with ldapadd -x -W -D "cn=Directory 
>> Manager" -f chain.ldiff
>>  • dn: cn=chainbe1,cn=chaining 
>> database,cn=plugins,cn=config
>> objectclass: top
>> objectclass: extensibleObject
>> objectclass: nsBackendInstance
>> cn: chainbe1
>> nsslapd-suffix: dc=example,dc=com
>> nsfarmserverurl: ldaps://idm01.example.com:636
>> nsmultiplexorbinddn: cn=replication manager,cn=config
>> nsmultiplexorcredentials: reppassword
>> nsCheckLocalACI: on
>>  • Modify the existing : dn: cn="dc=example,dc=com",cn=mapping 
>> tree,cn=config or to be exact dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping 
>> tree,cn=config
>>  • The original Entry was :
>>  • dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping 
>> tree,cn=config
>> objectClass: top
>> objectClass: extensibleObject
>> objectClass: nsMappingTree
>> cn: dc=example,dc=com
>> cn: "dc=example,dc=com"
>> nsslapd-state: referral on update
>> nsslapd-backend: userRoot
>> nsslapd-referral: ldap://idm01.exemple.com:389/dc%3Dexample%2Cdc%3Dcom
>>  • The modified entry is :
>>  • dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping 
>> tree,cn=config
>> objectClass: top
>> objectClass: extensibleObject
>> objectClass: nsMappingTree
>> cn: dc=example,dc=com
>> cn: "dc=example,dc=com"
>> nsslapd-backend: userRoot
>> nsslapd-referral: ldap://idm01.exemple.com:389/dc%3Dexample%2Cdc%3Dcom
>> nsslapd-state: backend
>> nsslapd-distribution-plugin: 
>> /usr/lib64/dirsrv/plugins/libreplication-plugin.so
>> nsslapd-distribution-funct: repl_chain_on_update
>> Errors :
>>  • From 389DS slave server :
>>  • Erorr Log
>>  • [17/Feb/2019:14:44:24.514362428 +] - ERR - 
>> chaining database - chaining_back_modify - invalid password syntax - 
>> passwords with storage scheme are not allowed
> This means you, or some client, tried to add a password that was already 
> hashed - this is not allowed.  The password must be in clear text at the time 
> it is set - then the server will hash it using the configured password 
> storage scheme.

As is this :) 

>>  • From Zimbra mail server
>>  • mailbox log
>>  • 2019-02-17 14:31:30,243 WARN  
>>

[389-users] Re: Update userpassword from consummer

2019-02-18 Thread Mark Reynolds



On 2/18/19 7:46 AM, wodel youchi wrote:

Hi,

I did a test, but unfortunately it didn't work for me.

This is my LAB:

  * 389DS Servers :
  o OS CentOS7 all updates
  o 389DS version 1.3.8.4-22
  o domain : dc=example,dc=com
  o users on : uid=%u,ou=people,dc=example,dc=com
  o One master server (idm01.example.com
) and one slave server
(idm02.example.com ).
  o Replication configured for userRoot database (dc=example,dc=com)
  o Replication uses this user cn=replication manager,cn=config
  o Password Policy is configured.
  * Mail server Zimbra 8.8.11
  o OS CentOS7 all updates
  o Zimbra FOSS 8.8.11.
  o External authentication configured  using LDAP server
  + Installation of ADPassword connector to allow change
password from Zimbra WebUI
  + External authentication was configured first on
idm01.example.com  to test that
change pass works correctly.
  + External authentication was modified to use
idm02.example.com  to test chain
modification.

Result :

  * Could not change user password using chain modification from
idm02.example.com 


Steps of configuration of chain modification :

  * On master 389DS server
  o Create a new ACI on dc=example,dc=com : *(targetattr =
"*")(version 3.0; acl "Proxied authorization for database links";
   allow (proxy) (userdn = "ldap:///cn=Replication
Manager,cn=config");)*
  o Create cn=replication manager,cn=config on the master after
getting this error from the slave's log :
  + [17/Feb/2019:14:31:30.151680780 +] - ERR -
slapi_ldap_bind - Error: could not bind id [cn=replication
manager,cn=config] authentication mechanism [SIMPLE]:
error 32 (No such object)

This means cn=replication manger does not exist on the slave server, but 
looks like you added it later...


  + [17/Feb/2019:14:31:30.153315712 +] - ERR - chaining
database - cb_get_connection - Can't bind to server
http://idm01.example.com>> port <636>.
(LDAP error 32 - No such object; Netscape Portable Runtime
error 0 - no error)
[17/Feb/2019:14:31:30.154527249 +] - ERR - chaining
database - chaining_back_modify - cb_get_connection failed
(-11) Connect error
  * On slave 389DS server
  o Create the chain entry with ldapadd -x -W -D "cn=Directory
Manager" -f chain.ldiff
  + dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsBackendInstance
cn: *chainbe1 *
*nsslapd-suffix: dc=example,dc=com
nsfarmserverurl: ldaps://idm01.example.com:636

nsmultiplexorbinddn: cn=replication manager,cn=config*
nsmultiplexorcredentials: reppassword
nsCheckLocalACI: on
  o Modify the existing : *dn: cn="dc=example,dc=com",cn=mapping
tree,cn=config* or to be exact dn:
cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
  + The original Entry was :
  # dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: dc=example,dc=com
cn: "dc=example,dc=com"
*nsslapd-state: referral on update*
nsslapd-backend: userRoot
nsslapd-referral:
ldap://idm01.exemple.com:389/dc%3Dexample%2Cdc%3Dcom

  + The modified entry is :
  # dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: dc=example,dc=com
cn: "dc=example,dc=com"
nsslapd-backend: userRoot
nsslapd-referral:
ldap://idm01.exemple.com:389/dc%3Dexample%2Cdc%3Dcom

*nsslapd-state: backend
nsslapd-distribution-plugin:
/usr/lib64/dirsrv/plugins/libreplication-plugin.so
nsslapd-distribution-funct: repl_chain_on_update*

Errors :

  * From 389DS slave server :
  o Erorr Log
  + [17/Feb/2019:14:44:24.514362428 +] - ERR - chaining
database - chaining_back_modify - invalid password syntax
- passwords with storage scheme are not allowed

This means you, or some client, tried to add a

[389-users] Re: Update userpassword from consummer

2019-02-18 Thread wodel youchi

Hi,

I did a test, but unfortunately it didn't work for me.

This is my LAB:

   - 389DS Servers :
  - OS CentOS7 all updates
  - 389DS version 1.3.8.4-22
  - domain : dc=example,dc=com
  - users on : uid=%u,ou=people,dc=example,dc=com
  - One master server (idm01.example.com) and one slave server (
  idm02.example.com).
  - Replication configured for userRoot database (dc=example,dc=com)
  - Replication uses this user cn=replication manager,cn=config
  - Password Policy is configured.
   - Mail server Zimbra 8.8.11
  - OS CentOS7 all updates
  - Zimbra FOSS 8.8.11.
  - External authentication configured  using LDAP server
 - Installation of ADPassword connector to allow change password
 from Zimbra WebUI
 - External authentication was configured first on idm01.example.com
 to test that change pass works correctly.
 - External authentication was modified to use idm02.example.com to
 test chain modification.

Result :

   - Could not change user password using chain modification from
   idm02.example.com


Steps of configuration of chain modification :

   - On master 389DS server
  - Create a new ACI on dc=example,dc=com :
*(targetattr = "*")(version 3.0; acl "Proxied authorization for database
  links";   allow (proxy) (userdn = "ldap:///cn=Replication
  Manager,cn=config");)*
  - Create cn=replication manager,cn=config on the master after getting
  this error from the slave's log :
  - [17/Feb/2019:14:31:30.151680780 +] - ERR - slapi_ldap_bind -
 Error: could not bind id [cn=replication manager,cn=config]
authentication
 mechanism [SIMPLE]: error 32 (No such object)
 [17/Feb/2019:14:31:30.153315712 +] - ERR - chaining database -
 cb_get_connection - Can't bind to server  port
 <636>. (LDAP error 32 - No such object; Netscape Portable
Runtime error 0 -
 no error)
 [17/Feb/2019:14:31:30.154527249 +] - ERR - chaining database -
 chaining_back_modify - cb_get_connection failed (-11) Connect error
  - On slave 389DS server
  - Create the chain entry with ldapadd -x -W -D "cn=Directory Manager"
  -f chain.ldiff
  - dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config
 objectclass: top
 objectclass: extensibleObject
 objectclass: nsBackendInstance
 cn: *chainbe1 *


*nsslapd-suffix: dc=example,dc=com nsfarmserverurl:
 ldaps://idm01.example.com:636 
 nsmultiplexorbinddn: cn=replication manager,cn=config*
 nsmultiplexorcredentials: reppassword
 nsCheckLocalACI: on
  - Modify the existing : *dn: cn="dc=example,dc=com",cn=mapping
  tree,cn=config* or to be exact dn:
  cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
 - The original Entry was :
- dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: dc=example,dc=com
cn: "dc=example,dc=com"
*nsslapd-state: referral on update*
nsslapd-backend: userRoot
nsslapd-referral: ldap://
idm01.exemple.com:389/dc%3Dexample%2Cdc%3Dcom
- The modified entry is :
- dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: dc=example,dc=com
cn: "dc=example,dc=com"
nsslapd-backend: userRoot
nsslapd-referral: ldap://
idm01.exemple.com:389/dc%3Dexample%2Cdc%3Dcom


*nsslapd-state: backend nsslapd-distribution-plugin:
/usr/lib64/dirsrv/plugins/libreplication-plugin.so
nsslapd-distribution-funct: repl_chain_on_update*

Errors :

   - From 389DS slave server :
  - Erorr Log
 - [17/Feb/2019:14:44:24.514362428 +] - ERR - chaining database
 - chaining_back_modify - invalid password syntax - passwords
with storage
 scheme are not allowed
  - From Zimbra mail server
  - mailbox log
 - 2019-02-17 14:31:30,243 WARN  [qtp1286783232-42786:
 http://localhost:8080/service/soap/ChangePasswordRequest]
 [ua=zclient/8.8.11_GA_3772;soapId=2e1e97b2;] SoapEngine -
handler exception
 com.zimbra.common.service.ServiceException: permission denied:
 javax.naming.NamingException: [LDAP: error code 1 - database
configuration
 error - please contact the system administrator]; remaining name
 'uid=j.shepard,ou=People,dc=example,dc=com'
 ExceptionId:qtp1286783232-42786:
 
http://localhost:8080/service/soap/ChangePasswordRequest:1550413890243:874fcd9af69d9eb8
 Code:service.PERM_DENIED


Did I respect the procedure?
i didn't find anything about chain

[389-users] Re: Update userpassword from consummer

2019-02-17 Thread William Brown

I don’t see any reason why it wouldn’t still work today? It would be good if 
you were able to test a development deployment and let us know the results and 
processes taken? 

> On 17 Feb 2019, at 21:48, wodel youchi  wrote:
> 
> Hi,
> 
> We have a master 389DS Server, and several Slaves.
> 
> The slaves are in the front, and the clients can use them for search and 
> authentication.
> 
> We have also a mailing solution, and we want to allow users to modify their 
> passwords.
> 
> I've read this article : 
> https://directory.fedoraproject.org/docs/389ds/howto/howto-chainonupdate.html
> 
> I don't know it it's still supported.
> 
> The idea is to chain password modification via the slave to the master.
> 
> Regards.
> 
> Regards.
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

[389-users] Re: Update userpassword from consummer

[389-users] Re: Update userpassword from consummer

[389-users] Re: Update userpassword from consummer

[389-users] Re: Update userpassword from consummer

[389-users] Re: Update userpassword from consummer

[389-users] Re: Update userpassword from consummer

[389-users] Re: Update userpassword from consummer

[389-users] Re: Update userpassword from consummer

[389-users] Re: Update userpassword from consummer

[389-users] Re: Update userpassword from consummer

10 matches

Site Navigation

Mail list logo

Footer information