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