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: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
<mailto: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
<mailto: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
<mailto:389-users@lists.fedoraproject.org>
> To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org
<mailto: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
<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org
<mailto: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
