(ITS#8927) slapo-ppolicy is destructive to delta-sync replication

[quanah@openldap.org]

Full_Name: Quanah Gibson-Mount
Version: 2.4.46
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)


While investigating a report of an issue with slapo-ppolicy in an MMR
environment, I've found that ppolicy is destructive in a delta-sync replicated
environment.

The root cause of course is that there is no guidance on how to handle how
replication works with ppolicy, a deficiency that must be addressed before any
final draft is completed.

Reproduction case:

a) Set up a delta-sync replicated environment with slapo-ppolicy enabled and a
default policy of:

pwdAttribute: userPassword
pwdLockout: TRUE
pwdLockoutDuration: 1800
pwdMaxFailure: 100
pwdFailureCountInterval: 300

b) Bind as a user to master1 with an invalid password

c) perform an ldap v3 password modify against master1 as an administrative user
and reset the password for the user in step b

When the second action is performed (c), all consumers will go into REFRESH
mode:

Oct 11 11:44:37 anvil2 slapd[5791]: syncrepl_null_callback : error code 0x10
Oct 11 11:44:37 anvil2 slapd[5791]: slap_graduate_commit_csn: removing
0x7faf10106000 20181011184437.093014Z#000000#001#000000
Oct 11 11:44:37 anvil2 slapd[5791]: syncrepl_message_to_op: rid=001 be_modify
uid=user1,ou=user,dc=example,dc=com (16)
Oct 11 11:44:37 anvil2 slapd[5791]: do_syncrep2: rid=001 delta-sync lost sync on
(reqStart=20181011184437.000001Z,cn=accesslog), switching to REFRESH


As noted in ITS#8125, going into REFRESH mode can cause data loss.