https://bugs.openldap.org/show_bug.cgi?id=9671

--- Comment #1 from Quanah Gibson-Mount quanah@openldap.org --- This is noted in the upgrade appendix of the admin guide for going from 2.4 to 2.5. Sites will need to adjust their procedures to correctly follow draft 10 for ppolicy.

https://bugs.openldap.org/show_bug.cgi?id=9671

--- Comment #2 from Michael Ströder michael@stroeder.com --- (In reply to Quanah Gibson-Mount from comment #1)

Sites will need to adjust their procedures to correctly follow draft 10 for ppolicy.

So what's the correct process. Using Relax Rules control. Seriously?

Especially this sucks given that access control for using controls does not really exist. In Æ-DIR I definitely don't want to grant manage privileges to admins doing normal data maintenance.

https://bugs.openldap.org/show_bug.cgi?id=9671

--- Comment #4 from Michael Ströder michael@stroeder.com --- (In reply to Ondřej Kuzník from comment #3)

On Tue, Sep 07, 2021 at 08:30:27PM +0000, openldap-its@openldap.org wrote: then we should revisit the Behera draft and check where it makes sense for attribute to be marked NO-USER-MODIFICATION.

My attempt to revive ietf-ldapext WG was not successful. So this is not an option.

I've already had to make changes to the local version where things were omitted: https://git.openldap.org/openldap/openldap/-/commit/ 2b007d01dbd924cf11f88c2f8dbba26b5ba8b593

Hmm, not sure whether that leads to more interoperability.

Sounds like adding manage permissions on the attribute (and maybe the "entry" attribute) could be a targeted way of allowing this operation?

I strongly dislike having to use the Relax Rules control to let the admin change pwdPolicySubentry. IMO this control must only be used in exceptional administrative use-cases. I have a very strong opinion on this.

In my local OpenLDAP 2.5.x builds I now simply remove NO-USER-MODIFICATION.

Ideally I'd prefer not having to deal with pwdPolicySubentry at all. But until ITS#9343 is implemented NO-USER-MODIFICATION should be removed.

Another solution would be to have a separate attribute fooPasswordPolicy (or whatever name you'd prefer) for overriding per entry the computed pwdPolicySubentry. It also allows to always compute the effective pwdPolicySubentry including applying defaults. This is the approach at least one other LDAP server implements.

https://bugs.openldap.org/show_bug.cgi?id=9671

--- Comment #6 from Ondřej Kuzník ondra@mistotebe.net --- On Wed, Sep 08, 2021 at 09:52:49AM +0000, openldap-its@openldap.org wrote:

--- Comment #4 from Michael Ströder michael@stroeder.com --- (In reply to Ondřej Kuzník from comment #3)

...

I've already had to make changes to the local version where things were omitted: https://git.openldap.org/openldap/openldap/-/commit/ 2b007d01dbd924cf11f88c2f8dbba26b5ba8b593

Hmm, not sure whether that leads to more interoperability.

...

Sounds like adding manage permissions on the attribute (and maybe the "entry" attribute) could be a targeted way of allowing this operation?

I strongly dislike having to use the Relax Rules control to let the admin change pwdPolicySubentry. IMO this control must only be used in exceptional administrative use-cases. I have a very strong opinion on this.

In my local OpenLDAP 2.5.x builds I now simply remove NO-USER-MODIFICATION.

Ideally I'd prefer not having to deal with pwdPolicySubentry at all. But until ITS#9343 is implemented NO-USER-MODIFICATION should be removed.

Another solution would be to have a separate attribute fooPasswordPolicy (or whatever name you'd prefer) for overriding per entry the computed pwdPolicySubentry. It also allows to always compute the effective pwdPolicySubentry including applying defaults. This is the approach at least one other LDAP server implements.

That sounds like something we might be able to pursue as it's a viable reading of the draft. It would need a database reload with the attribute renamed so not something I can see us doing before 2.7 (it's too late for 2.6 now), we could do this alongside ITS#9343.

That means we still have to decide whether the pwdPolicySubentry status should be reverted back and in which release.

Regards,

https://bugs.openldap.org/show_bug.cgi?id=9671

--- Comment #8 from Michael Ströder michael@stroeder.com --- So what's the conclusion here? This should be fixed soon somehow because the issue make using slapo-ppolicy with different policy entries almost unusable.

https://bugs.openldap.org/show_bug.cgi?id=9671

--- Comment #9 from Ondřej Kuzník ondra@mistotebe.net --- So looking at the attributes that have "NO-USER-MODIFICATION USAGE directoryOperation" on right now:

- pwdChangedTime: pretty sure that one should stay - pwdAccountLockedTime: this is how accounts are locked, so I think we have to allow some modification as locking someone's account is a common use case - pwdFailureTime: managed by ppolicy, should stay - pwdHistory: managed by ppolicy, should stay - pwdGraceUseTime: managed by ppolicy, should stay - pwdPolicySubentry: discussed already, will remove it until ITS#9343 when it (or something along those lines) gets added again - pwdStartTime/pwdEndTime: are administrator managed, I suggest we remove the flags - pwdLastSuccess: managed by core, should stay - pwdAccountTmpLockoutEnd: internal to ppolicy (not part of draft), should stay as is

Comments/dissenting arguments welcome.

https://bugs.openldap.org/show_bug.cgi?id=9671

Quanah Gibson-Mount quanah@openldap.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED

--- Comment #11 from Quanah Gibson-Mount quanah@openldap.org --- head:

• 77dfb204 by Ondřej Kuzník at 2021-09-16T16:18:17+00:00 ITS#9671 Revert some NO-USER-MODIFICATION flags in ppolicy

RE26:

• d69a69cd by Ondřej Kuzník at 2021-09-20T19:07:44+00:00 ITS#9671 Revert some NO-USER-MODIFICATION flags in ppolicy

RE25:

• aecc92d9 by Ondřej Kuzník at 2021-09-20T19:07:52+00:00 ITS#9671 Revert some NO-USER-MODIFICATION flags in ppolicy