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:
dn: olcOverlay={4}refint,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcRefintAttribute: member olcRefintAttribute: pwdPolicySubentry olcOverlay: {4}refint
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?
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.
Kind regards, Ulrich Windl
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,
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 ondra@mistotebe.net Sent: Tuesday, April 29, 2025 12:49 PM To: Windl, Ulrich u.windl@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
On Mon, May 05, 2025 at 07:46:34AM +0000, Windl, Ulrich wrote:
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.
Hi Ulrich, only data stored in the database can be managed by refint, it won't update virtual attributes, much less actual configuration. It is your responsibility as administrator to keep your configuration consistent and correct.
Regards,
Hi!
Oh well, the typical (data) administrator is using some frontend that just shows objects' attributes, and it may not be quite obvious which ones are "virtual": After all they (e.g. pwdPolicySubentry) are stored permanently in the database (and they are synced, fortunately).
Kind regards, Ulrich Windl
-----Original Message----- From: Ondřej Kuzník ondra@mistotebe.net Sent: Tuesday, May 6, 2025 11:54 AM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org Subject: [EXT] Re: Re: using refint overlay for pwdPolicySubentry
On Mon, May 05, 2025 at 07:46:34AM +0000, Windl, Ulrich wrote:
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.
Hi Ulrich, only data stored in the database can be managed by refint, it won't update virtual attributes, much less actual configuration. It is your responsibility as administrator to keep your configuration consistent and correct.
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Tue, May 06, 2025 at 12:26:52PM +0000, Windl, Ulrich wrote:
Hi!
Oh well, the typical (data) administrator is using some frontend that just shows objects' attributes, and it may not be quite obvious which ones are "virtual": After all they (e.g. pwdPolicySubentry) are stored permanently in the database (and they are synced, fortunately).
Hi, if they are this likely to shoot themselves in the foot, it is prudent of you as the system administrator to set up internal documentation and/or access control so that they are not going to.
I'm afraid that's the only advice I can give you, it is impossible for the code to anticipate every eventuality.
Regards,
Hi!
I don't know who said "Ease of use, not ease of implementation is the design goal", but If one DN is used as a value for some attribute, and there's a "referential integrity module" to update such attributes if the underlying DN changes, it's hard to explain why it would work for some cases, but not for others. And to make things worse: It just fails silently.
Kind regards, Ulrich Windl
-----Original Message----- From: Ondřej Kuzník ondra@mistotebe.net Sent: Tuesday, May 6, 2025 3:12 PM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org Subject: [EXT] Re: Re: Re: using refint overlay for pwdPolicySubentry
On Tue, May 06, 2025 at 12:26:52PM +0000, Windl, Ulrich wrote:
Hi!
Oh well, the typical (data) administrator is using some frontend that just shows objects' attributes, and it may not be quite obvious which ones are "virtual": After all they (e.g. pwdPolicySubentry) are stored permanently in the database (and they are synced, fortunately).
Hi, if they are this likely to shoot themselves in the foot, it is prudent of you as the system administrator to set up internal documentation and/or access control so that they are not going to.
I'm afraid that's the only advice I can give you, it is impossible for the code to anticipate every eventuality.
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Thu, May 08, 2025 at 05:40:07AM +0000, Windl, Ulrich wrote:
Hi!
I don't know who said "Ease of use, not ease of implementation is the design goal", but If one DN is used as a value for some attribute, and there's a "referential integrity module" to update such attributes if the underlying DN changes, it's hard to explain why it would work for some cases, but not for others. And to make things worse: It just fails silently.
Ok, let's play devil's advocate and assume someone configured OpenLDAP with slapd.conf: how do you propose refint goes about adjusting that configuration for you? Does it write a new configuration file, do ACLs/limit stanzas get rewritten as well on renames? How about regex based ACLs/limits?
Maybe you can help us design this functionality to improve the ease of use, maybe you have suggestions how the documentation can be improved to make sure people appreciate the limitations at the appropriate time and decide how well it covers their use case.
After all this is still a community based project and without the wisdom and contributions of the community it will not advance.
Thanks,
I fail to see where slapd.conf comes into play with handling of pwdPolicySubentry: Both the policies and the users are defined in a different (MDB) database. Only the default policy may be stored in the config database directly, and I did not talk about that.
Kind regards, Ulrich Windl
-----Original Message----- From: Ondřej Kuzník ondra@mistotebe.net Sent: Thursday, May 8, 2025 10:58 AM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org Subject: [EXT] Re: Re: Re: Re: using refint overlay for pwdPolicySubentry
On Thu, May 08, 2025 at 05:40:07AM +0000, Windl, Ulrich wrote:
Hi!
I don't know who said "Ease of use, not ease of implementation is the design goal", but If one DN is used as a value for some attribute, and there's a "referential integrity module" to update such attributes if the underlying DN changes, it's hard to explain why it would work for some cases, but not for others. And to make things worse: It just fails silently.
Ok, let's play devil's advocate and assume someone configured OpenLDAP with slapd.conf: how do you propose refint goes about adjusting that configuration for you? Does it write a new configuration file, do ACLs/limit stanzas get rewritten as well on renames? How about regex based ACLs/limits?
Maybe you can help us design this functionality to improve the ease of use, maybe you have suggestions how the documentation can be improved to make sure people appreciate the limitations at the appropriate time and decide how well it covers their use case.
After all this is still a community based project and without the wisdom and contributions of the community it will not advance.
Thanks,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Fri, May 09, 2025 at 10:00:08AM +0000, Windl, Ulrich wrote:
I fail to see where slapd.conf comes into play with handling of pwdPolicySubentry: Both the policies and the users are defined in a different (MDB) database. Only the default policy may be stored in the config database directly, and I did not talk about that.
Yes, and as I indicated before, in my testing, everything but a default policy was being adjusted by refint just fine. The reason default policy was not is because it is set in the configuration and what we've moved onto.
If you can reproduce a set up where a pwdPolicySubentry is stored on the account's entry, refint is properly configured and a rename of the corresponding policy entry does not trigger an update of the account contrary to refint documentation, please post it here or better, file an issue.
Thanks,
openldap-technical@openldap.org
-
Ondřej Kuzník -
Windl, Ulrich