> On 19 Feb 2019, at 00:54, Mark Reynolds <mreyno...@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:874fcd9af69d9eb8 >> 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 <wbr...@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.you...@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 >> > 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 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 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
