https://bugs.openldap.org/show_bug.cgi?id=9953
Issue ID: 9953 Summary: Push replication issue for the pwdHistory attribute Product: OpenLDAP Version: 2.4.57 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: dh@dotlan.net Target Milestone: ---
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