Ondřej, thanks for explaining. Maybe you misunderstood the final part of my message: I wanted to point out that a "normal" (=member) attribute seemed to work just fine, while an attribute provided by an overlay (i.e. policy) may not work as expected. Is there some ordering requirement (refint, policy overlays) involved here, maybe? And yes, I've configured refint the same way on all nodes.
Mit freundlichen Grüßen Ulrich Windl > -----Original Message----- > From: Ondřej Kuzník <on...@mistotebe.net> > Sent: Tuesday, April 29, 2025 12:49 PM > To: Windl, Ulrich <u.wi...@ukr.de> > Cc: openldap-technical@openldap.org > Subject: [EXT] Re: using refint overlay for pwdPolicySubentry > > 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
