Hello,
I'm using a master ldap instance with a push replication instance to external slaves using the ldap backend on Debian 11 (2.4.57) and I came across some replication issues that forces me to drop the slave dbs and do a manually fullsync everything this error occurs.
The problem ===========
I know that replication and maintaining a password policy is a complicated task, especially since the ppolicy overlay must be loaded and active in every instance (master, push instance, slave). This problem leads to interesting challanges.
First, I encountered a problem where pwdChangedTime would be duplicate because the ppolicy overlay of the push instance and the back_ldap/slave instance would like to set it (which leads to a duplicate attribute error). To fix problem I backported the patch [1] to my local version of the slapd packages. After this problem was fixed, I've encountered the next problematic attribute: "pwdHistory". I've play around with some syncrepl settings, but in the end, it seems to be a similar issue. It looks likes the pwdHistory attribute is not yet present on the slave and both instances (push and slave) try to add the pwdHistory Attributes which leads to a problem where both entries collied (pwdHistory: value #0 already exists). For whatever reason pwdHistory doesn't show up as modified field on the slave in the MOD request. But anyways. Something seems to be wrong, and it could a similar replication issue compared with pwdChangedTime
I've lookup into the change history of the ppolicy.c file in the 2.5 and 2.6 branch but couldn't find a newer commit that would address this issue.
Does anyone has encountered a similar issue? I've not played around with the 2.5 or 2.6 version, but looking at the code, I've either not seen a fix or the problem might still exist, hopefully I am wrong. Any suggestions?
-- best regards Daniel Hoffend
[1] https://github.com/openldap/openldap/commit/7a34f46d1cabe8e80937d5167b621528...
Setup =====
Host Master - Debian 11 slapd 2.4.57+dfsg-3 - slapd master instance with cn=config - push replikation instance with simple config (syncrepl from localhost, write to backend ldap)
Host Slave - Debian 11 slapd 2.4.57+dfsg-3 - Readonly slave
On all 3 instances ppolicy is enabled otherwise the operational attributes would be not known/available and sync of locked accounts or per account selected password policy assignment wouldn't work.
PUSH Replication Instance =========================
database ldap [...] overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=example,dc=org"
syncrepl rid=__RID__ provider=ldap://localhost:389/ binddn="cn=replication,ou=system,dc=example,dc=org" bindmethod=simple credentials="secret" searchbase="dc=example,dc=org" type=refreshAndPersist schemachecking=off retry="5 12 60 +"
attrs="*,memberOf,pwdPolicySubentry,pwdChangedTime,pwdAccountLockedTime,pwdHistory,creatorsName,createTimestamp,modifiersName,modifyTimestamp"
---
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_message_to_entry: rid=016 DN: uid=user1,ou=accounts,dc=example,dc=org, UUID: db720f56-df0d-103c-8635-9543ccd6e97d Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid a0a89700 Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_search (0) Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 uid=user1,ou=accounts,dc=example,dc=org Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_null_callback : error code 0x14 Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify uid=user1,ou=accounts,dc=example,dc=org (20) Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify failed (20) Nov 3 00:00:45 ldapmaster slapd[2308611]: do_syncrepl: rid=016 rc 20 retrying
SLAVE LDAP Server =================
database mdb [...] overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=example,dc=org"
---
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SRCH base="uid=user1,ou=accounts,dc=example,dc=org" scope=0 deref=0 filter="(objectClass=*)" Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SEARCH RESULT tag=101 err=0 nentries=1 text= Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD dn="uid=user1,ou=accounts,dc=example,dc=org" Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD attr=structuralObjectClass creatorsName createTimestamp userPassword pwdChangedTime memberOf entryCSN modifiersName modifyTimestamp Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 RESULT tag=103 err=20 text=modify/add: pwdHistory: value #0 already exists
--On Tuesday, November 8, 2022 9:15 PM +0100 Daniel Hoffend dh@dotlan.net wrote:
Hello,
I'm using a master ldap instance with a push replication instance to external slaves using the ldap backend on Debian 11 (2.4.57) and I came across some replication issues that forces me to drop the slave dbs and do a manually fullsync everything this error occurs.
Hi Daniel,
I discussed this issue with one of the developers, they suggest opening an ITS and noting that that operation should be treated as replication traffic but right now we only check for connection level syncrepl not push (which is only identified by being initiated by updatedn, if that's configured)
If you're not comfortable opening up an ITS, let me know and I can do it on your behalf.
Regards, Quanah
Hello Quanah
Thanks for your response. I’ve opened an issue in Bugzilla with the ID 9935.
I’ll add your notes to the issue as well.
On 11/17/22 20:26, Daniel Hoffend wrote:
Thanks for your response. I’ve opened an issue in Bugzilla with the ID 9935.
As a work-around you could exclude pwdHistory attribute from the push replication to read-only replicas because it's used only on writeable replicas.
Ciao, Michael.
The syncrepl overlay reads from the provider and writes its changes to the back_ldap backend. The ppolicy overlay affects everything what is beeing written to the backend and I haven't found anything that could control or exclude the attributes written to the backend.
If i disable the ppolicy on the push instance, everyything because of unknown attributes, so that's not an option either.
What's more confusing, is the fact that the MOD operation logged on the slave (push replication receiver) that no pwdHistory atttribute is beeing pushed but the error still occurs. (See log messages in my initial mail).
thanks for you suggestions, Daniel
Am 17.11.2022 um 20:56 schrieb Michael Ströder:
On 11/17/22 20:26, Daniel Hoffend wrote:
Thanks for your response. I’ve opened an issue in Bugzilla with the ID 9935.
As a work-around you could exclude pwdHistory attribute from the push replication to read-only replicas because it's used only on writeable replicas.
Ciao, Michael.
openldap-technical@openldap.org