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 http://idm01.example.com) and one slave server (idm02.example.com http://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 http://idm01.example.com to test that change pass works correctly. + External authentication was modified to use idm02.example.com http://idm02.example.com to test chain modification.

Result :

• Could not change user password using chain modification from idm02.example.com http://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 +0000] - 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 +0000] - ERR - chaining
        database - cb_get_connection - Can't bind to server
        <idm01.example.com <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 +0000] - 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 http://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 http://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 http://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 +0000] - 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.

• From Zimbra mail server o 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:874fc... Code:service.PERM_DENIED

Did I respect the procedure? i didn't find anything about chain modification on RedHat documentation, did I miss anything?

This is a not a fully documented/supported procedure.  However, I know a lot of people use it successfully.  I think the main problem you are having is the password stored for the replication manager (I'm assuming this is where the error "passwords with storage scheme are not allowed" is coming from).  Or, it's the "user" password change that has a prehashed password.  Again this would be client incorrectly trying to do this.  So who/what is making the password change? If you use ldapmodify and set a password yourself does it work, does it chain-on-update successfully?

Mark

Regards.

Le lun. 18 févr. 2019 à 00:58, William Brown <wbrown@suse.de mailto:wbrown@suse.de> a écrit :

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 <wodel.youchi@gmail.com
<mailto:wodel.youchi@gmail.com>> 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
<mailto:389-users@lists.fedoraproject.org>
> To unsubscribe send an email to
389-users-leave@lists.fedoraproject.org
<mailto:389-users-leave@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
<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to
389-users-leave@lists.fedoraproject.org
<mailto:389-users-leave@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 mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....

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 dn: uid=user,ou=people,dc=example,dc=com changetype: modify replace: sn sn: Jensen

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.0000641275 [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.0000630283 [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.0000245044 [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=5c73f3f6000000010000 [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 <<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

*Result* : Error

*Log from the slave :* *Access* : [25/Feb/2019:15:00:05.454617576 +0100] conn=56 fd=67 slot=67 connection from ::1 to ::1 [25/Feb/2019:15:00:05.454793777 +0100] conn=56 op=0 BIND dn="uid=lnadmin,ou=special users,dc=example,dc=com" method=128 version=3 [25/Feb/2019:15:00:05.455743631 +0100] conn=56 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0001039755 dn="uid=lnadmin,ou=special users,dc=example,dc=com" [25/Feb/2019:15:00:05.456268843 +0100] conn=56 op=1 MOD dn="uid=adam,ou=people,dc=example,dc=com" [25/Feb/2019:15:00:05.470513293 +0100] conn=56 op=1 RESULT err=19 tag=103 nentries=0 etime=0.0014585377 [25/Feb/2019:15:00:05.470685336 +0100] conn=56 op=2 UNBIND [25/Feb/2019:15:00:05.470698929 +0100] conn=56 op=2 fd=67 closed - U1

*Log from the master:* *Access*: [25/Feb/2019:15:00:05.690740190 +0100] conn=11 op=5 BIND dn="uid=lnadmin,ou=special users,dc=example,dc=com" method=128 version=3 [25/Feb/2019:15:00:05.690918353 +0100] conn=11 op=5 RESULT err=0 tag=97 nentries=0 etime=0.0000266930 dn="uid=lnadmin,ou=special users,dc=example,dc=com" [25/Feb/2019:15:00:05.698224736 +0100] conn=30 fd=86 slot=86 SSL connection from 192.168.40.102 to 192.168.40.101 [25/Feb/2019:15:00:05.703258058 +0100] conn=30 TLS1.2 256-bit AES-GCM [25/Feb/2019:15:00:05.703629324 +0100] conn=30 op=0 BIND dn="cn=replication manager,cn=config" method=128 version=3 [25/Feb/2019:15:00:05.703804399 +0100] conn=30 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0005535704 dn="cn=replication manager,cn=config" [25/Feb/2019:15:00:05.705870103 +0100] conn=30 op=1 RESULT err=19 tag=103 nentries=0 etime=0.0001493925 [25/Feb/2019:15:00:05.705878415 +0100] conn=30 op=1 MOD dn="uid=adam,ou=people,dc=example,dc=com" authzid="uid=lnadmin,ou=special users,dc=example,dc=com", invalid password syntax

*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

*Result* : Error *Log from the slave :* *Access*: [25/Feb/2019:15:06:15.301550287 +0100] conn=60 fd=67 slot=67 connection from ::1 to ::1 [25/Feb/2019:15:06:15.301676473 +0100] conn=60 op=0 BIND dn="uid=lnadmin,ou=special users,dc=example,dc=com" method=128 version=3 [25/Feb/2019:15:06:15.302595184 +0100] conn=60 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0000958183 dn="uid=lnadmin,ou=special users,dc=example,dc=com" [25/Feb/2019:15:06:15.303150642 +0100] conn=60 op=1 RESULT err=19 tag=103 nentries=0 etime=0.0000360791 [25/Feb/2019:15:06:15.303157302 +0100] conn=60 op=1 MOD dn="uid=adam,ou=people,dc=example,dc=com", invalid password syntax [25/Feb/2019:15:06:15.303264055 +0100] conn=60 op=2 UNBIND [25/Feb/2019:15:06:15.303272482 +0100] conn=60 op=2 fd=67 closed - U1

*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 lun. 18 févr. 2019 à 23:58, William Brown wbrown@suse.de a écrit :

...

On 19 Feb 2019, at 00:54, Mark Reynolds mreynolds@redhat.com 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 +0000] - 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 +0000] - ERR -

chaining database - cb_get_connection - Can't bind to server < 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 +0000] - 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 +0000] - 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

[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:874fc...

...

...

Code:service.PERM_DENIED

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

documentation, did I miss anything?

...

This is a not a fully documented/supported procedure. However, I know a

lot of people use it successfully. I think the main problem you are having is the password stored for the replication manager (I'm assuming this is where the error "passwords with storage scheme are not allowed" is coming from). Or, it's the "user" password change that has a prehashed password. Again this would be client incorrectly trying to do this. So who/what is making the password change? If you use ldapmodify and set a password yourself does it work, does it chain-on-update successfully?

...

Mark

...

Regards.

Le lun. 18 févr. 2019 à 00:58, William Brown wbrown@suse.de a écrit : 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 wodel.youchi@gmail.com

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.htm...

...

...

...

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-leave@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....

...

...

— 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-leave@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....

...

...

---

389-users mailing list -- 389-users@lists.fedoraproject.org

To unsubscribe send an email to 389-users-leave@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....

...

---

389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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....

— Sincerely,

William Brown Software Engineer, 389 Directory Server SUSE Labs

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 <<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

Regards.

Le mer. 27 févr. 2019 à 00:44, William Brown wbrown@suse.de a écrit :

...

On 26 Feb 2019, at 00:23, wodel youchi wodel.youchi@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

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 http://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@suse.de a écrit :

...

On 27 Feb 2019, at 19:25, wodel youchi wodel.youchi@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/ht...

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@suse.de a écrit :

...

On 26 Feb 2019, at 00:23, wodel youchi wodel.youchi@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