1:15 p.m.
https://bugs.openldap.org/show_bug.cgi?id=9671
Issue ID: 9671
Summary: pwdPolicySubentry: no user modification allowed
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Without using Relax Rules control it is not possible to set attribute
pwdPolicySubentry anymore. This was possible with 2.4.x.
# ldapadd -Q -f aehost.ldif
adding new entry "host=foobar42.example.com,cn=test-hosts-1,cn=test,ou=ae-dir"
ldap_add: Constraint violation (19)
additional info: pwdPolicySubentry: no user modification allowed
This is a really serious regression for existing admin processes.
--
You are receiving this mail because:
You are on the CC list for the issue.
1:25 p.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
--- Comment #1 from Quanah Gibson-Mount <quanah(a)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.
--
You are receiving this mail because:
You are on the CC list for the issue.
1:25 p.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |needs_review
--
You are receiving this mail because:
You are on the CC list for the issue.
1:30 p.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
--- Comment #2 from Michael Ströder <michael(a)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.
--
You are receiving this mail because:
You are on the CC list for the issue.
1:32 a.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
--- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
On Tue, Sep 07, 2021 at 08:30:27PM +0000, openldap-its(a)openldap.org wrote:
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.
Hi Michael,
then we should revisit the Behera draft and check where it makes sense
for attribute to be marked NO-USER-MODIFICATION. I've already had to
make changes to the local version where things were omitted:
https://git.openldap.org/openldap/openldap/-/commit/2b007d01dbd924cf11f88...
If we can agree and produce a newer draft, we can consider making
changes in the ppolicy overlay. To the best of my knowledge, it is not
possible to mutate schema based on configuration so making this an admin
choice is not something we can do.
Sounds like adding manage permissions on the attribute (and maybe the
"entry" attribute) could be a targeted way of allowing this operation?
Regards,
--
You are receiving this mail because:
You are on the CC list for the issue.
2:52 a.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
--- Comment #4 from Michael Ströder <michael(a)stroeder.com> ---
(In reply to Ondřej Kuzník from comment #3)
On Tue, Sep 07, 2021 at 08:30:27PM +0000, openldap-its(a)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.
--
You are receiving this mail because:
You are on the CC list for the issue.
3:09 a.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
--- Comment #5 from Michael Ströder <michael(a)stroeder.com> ---
Additionally you should ask yourself:
Does adding NO-USER-MODIFICATION solve any real-world problem?
IMO the answer is clearly no.
Does adding NO-USER-MODIFICATION is an obstacle for real-world usage?
IMO the answer is clearly yes.
The change was only done to blindly obey to an I-D which is widely considered
broken anyway.
--
You are receiving this mail because:
You are on the CC list for the issue.
3:28 a.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
--- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
On Wed, Sep 08, 2021 at 09:52:49AM +0000, openldap-its(a)openldap.org wrote:
--- Comment #4 from Michael Ströder <michael(a)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,
--
You are receiving this mail because:
You are on the CC list for the issue.
3:33 a.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
--- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
On Wed, Sep 08, 2021 at 10:09:10AM +0000, openldap-its(a)openldap.org wrote:
Additionally you should ask yourself:
Does adding NO-USER-MODIFICATION solve any real-world problem?
IMO the answer is clearly no.
There is an argument that it signals to the requester "you are messing
with password policy internal state". For pwdHistory, that is definitely
the right way to go, for pwdPolicySubentry, maybe not just yet.
--
You are receiving this mail because:
You are on the CC list for the issue.
6:30 a.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
--- Comment #8 from Michael Ströder <michael(a)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.
--
You are receiving this mail because:
You are on the CC list for the issue.
8:56 a.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2.5.8
Keywords|needs_review |
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
--
You are receiving this mail because:
You are on the CC list for the issue.
1:52 a.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
--- Comment #9 from Ondřej Kuzník <ondra(a)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.
--
You are receiving this mail because:
You are on the CC list for the issue.
2:55 a.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
Ondřej Kuzník <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |IN_PROGRESS
Ever confirmed|0 |1
--- Comment #10 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
https://git.openldap.org/openldap/openldap/-/merge_requests/409
--
You are receiving this mail because:
You are on the CC list for the issue.
12:24 p.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|IN_PROGRESS |RESOLVED
--- Comment #11 from Quanah Gibson-Mount <quanah(a)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
--
You are receiving this mail because:
You are on the CC list for the issue.
11 a.m.
New subject: [Issue 9671] pwdPolicySubentry: no user modification allowed
https://bugs.openldap.org/show_bug.cgi?id=9671
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
604
days inactive
638
days old
14 comments
1 participants
participants (1)
-
openldap-its＠openldap.org