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: b...@openldap.org
Reporter: d...@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/7a34f46d1cabe8e80937d5167b621528b831da11#diff-e9bcd50c0aef5c89f0bd966cea23de856227501f29714018ed76cc1dfbfc06ffR2311-R2312
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
--
You are receiving this mail because:
You are on the CC list for the issue.
