|
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 :
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...
- [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.
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
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
|
