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,
Hi!
Sorry for the length delay. I tested again: * I copied a policy and assigned that copy to a user * then I renamed that copied pppolicy to a new name * searching the server I see that the pwdPolicySubentry attribute is updated
The confusing part is that I find the rename in accesslog, but not the attribute change. Of course, the rename triggered an attribute change on the other replicated node as well, but I would find it more consistent if the change done by refint were reflected in the accesslog (and be replicated that way).
Maybe it's my fault to use the accesslog to see all changes applied to the local database...
Kind regards, Ulrich Windl
-----Original Message----- From: Ondřej Kuzník ondra@mistotebe.net Sent: Friday, May 9, 2025 12:34 PM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org Subject: [EXT] Re: Re: Re: Re: Re: using refint overlay for pwdPolicySubentry
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,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Mon, Jun 02, 2025 at 09:58:14AM +0000, Windl, Ulrich wrote:
Hi!
Sorry for the length delay. I tested again:
- I copied a policy and assigned that copy to a user
- then I renamed that copied pppolicy to a new name
- searching the server I see that the pwdPolicySubentry attribute is updated
The confusing part is that I find the rename in accesslog, but not the attribute change. Of course, the rename triggered an attribute change on the other replicated node as well, but I would find it more consistent if the change done by refint were reflected in the accesslog (and be replicated that way).
Maybe it's my fault to use the accesslog to see all changes applied to the local database...
Hi Ulrich, as documented, refint-initiated operations are not meant to be replicated, you are supposed to configure refint on each replica. That includes they cannot be logged in accesslog either.
Regards,
-----Original Message----- From: Ondřej Kuzník ondra@mistotebe.net Sent: Monday, June 9, 2025 11:52 AM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org Subject: [EXT] Re: Re: Re: Re: Re: Re: using refint overlay for pwdPolicySubentry
On Mon, Jun 02, 2025 at 09:58:14AM +0000, Windl, Ulrich wrote:
Hi!
Sorry for the length delay. I tested again:
- I copied a policy and assigned that copy to a user
- then I renamed that copied pppolicy to a new name
- searching the server I see that the pwdPolicySubentry attribute is updated
The confusing part is that I find the rename in accesslog, but not the attribute change. Of course, the rename triggered an attribute change on the other replicated node as well, but I would find it more consistent if the change done by refint were reflected in the accesslog (and be replicated that way).
Maybe it's my fault to use the accesslog to see all changes applied to the local database...
Hi Ulrich, as documented, refint-initiated operations are not meant to be replicated, you are supposed to configure refint on each replica. That includes they cannot be logged in accesslog either.
[Windl, Ulrich] Well, I think they *could* be recorded there, causing some redundancy on the consumer if it also uses refint. What will "plain old LDAP sync" see from the provider then? The requirement that all consumers need to use refint as well seems to break LDAP sync IMHO.
Kind regards, Ulrich
On Tue, Jun 10, 2025 at 10:53:07AM +0000, Windl, Ulrich wrote:
Hi Ulrich, as documented, refint-initiated operations are not meant to be replicated, you are supposed to configure refint on each replica. That includes they cannot be logged in accesslog either.
Well, I think they *could* be recorded there, causing some redundancy on the consumer if it also uses refint. What will "plain old LDAP sync" see from the provider then?
Hi Ulrich, they will not see "fallout" notifications at all, again because they are supposed to process them internally. Note that refint is inherently race-prone already (identifying what updates are needed and running them is done in a separate task *after* the modification is done).
And no, they cannot be recorded in the accesslog, again because they are marked internal.
The requirement that all consumers need to use refint as well seems to break LDAP sync IMHO.
Due to LDAP semantics, any operations that affect more than one entry have the potential to break syncrepl, especially when more than 1 server accepts new modifications. Things like refint are only "safe" if there is only one such server at any point.
Regards,
openldap-technical@openldap.org
-
Ondřej Kuzník -
Windl, Ulrich