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, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
