Replication errors with slurpd and ppolicy

["Michael Steinmann" <msl@calivia.com>]

I'm currently using ppolicy in a replicated 2.3.30 environment. Most
things wrt ppolicy work extremely well but I'm having issues with slurpd
and ppolicy's internal attributes.

Due to firewall restrictions I'm currently forced to use both syncrepl and
slurpd for replication. Problem with slurpd is, that when a user changes
her password the pwdHistory attribute gets replicated with an add/delete
MOD. All attributes get replicated OK but I still get errors both on the
master and on the slave.

the master complains in .rej file with
ERROR: No such attribute: modify/delete: pwdHistory: no such value

the slave logs the following to syslog:
Jan 12 11:09:58 slave slapd[11335]: conn=1 op=10 MOD
dn="cn=ststm,ou=people,dc=example.com"
Jan 12 11:09:58 slave slapd[11335]: conn=1 op=10 MOD attr=userPassword
pwdChangedTime pwdHistory pwdHistory entryCSN modifiersName
modifyTimestamp
Jan 12 11:09:58 slave slapd[11335]: conn=2 op=10 MOD
dn="cn=ststm,ou=people,dc=example.com"
Jan 12 11:09:58 slave slapd[11335]: conn=2 op=10 MOD attr=userPassword
pwdChangedTime pwdHistory pwdHistory entryCSN modifiersName
modifyTimestamp
Jan 12 11:09:58 slave slapd[11335]: conn=2 op=10 RESULT tag=103 err=16
text=modify/delete: pwdHistory: no such value
Jan 12 11:09:58 slave slapd[11335]: conn=1 op=10 RESULT tag=103 err=0 text=


To me this looks like the ppolicy overlay and slurpd are both trying to
update the pwdHistory attribute at the same time but ppolicy kicks in
faster and thus slurpd cannot see the old value and fails.

My issue now is, that even though replication works OK (after replication
all attrs are identical on master and slave, pwdHistiory is in sync) the
logs are full of errors and the .rej is filling up.

I'aware that the restriction of not being able to define what exactly gets
replicated with slurpd is one of the reasons to phase it out, but maybe
someone has already come up with a solution. Using 2.4 is also not an
option (for now).

--
mike