On Mon, Apr 28, 2025 at 01:06:53PM +0000, Windl, Ulrich wrote:
Hi!
Some time ago U had replaced a password policy, and it was quite sme work to replace all occurrences. So I thought reint cul help. I configured:
And I did apply a test rename of the policy used by many users. I got no error from the modify, but slapd said many times: slapd[28826]: ppolicy_get: policy subentry cn=pp-default-2024-05x,...,dc=de missing or invalid at 'pwdPolicySubentry', no policy will be applied!
Shouldn't refint have fixed those entries, or is there something special about password policy? The other thing I had noticed was that the MMR consumer did not complain at all, and it even looks as if the update wasn't sent.
Did anybody try this before?
Hi Ulrich, it works just fine for me. Do not forget that: - the refint updates are queued up internally after the modification and processed in the background, are you sure you have waited long enough for the changes to finish? - refint documentation states that the internal updates are *not* replicated, instead every replica should have an identical refint configuration to apply them as needed - refint like other cross-entry integrity constraints (memberof) is really hard to make work consistently in a MMR environment unless you can guarantee that things are always routed to a *single* provider
When I checked for the member attribute by deleting a user, all members containing that user were removed, however. I see "modifiersName: cn=Referential Integrity Overlay", too. Same is true for a rename.
Yes, and this identity is configurable.
Regards,