Issue 7084 - Password Modify Extended Operation to set pwdReset: TRUE
Summary: Password Modify Extended Operation to set pwdReset: TRUE
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: 2.5.0
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-08 12:26 UTC by Michael Ströder
Modified: 2020-10-14 21:03 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Michael Ströder 2011-11-08 12:26:09 UTC
Full_Name: 
Version: 
OS: 
URL: 
Submission from: (NULL) (192.166.104.102)


Feature Request:
The Password Modify Extended Operation should set pwdReset: TRUE if the
accompanying password policy specifies pwdMustChange: TRUE.

Section 8.2.7 of http://tools.ietf.org/html/draft-behera-ldap-password-policy-09#section-8.2
says:

   If the value the pwdMustChange is TRUE and the modification is
   performed by a password administrator, then the pwdReset attribute is
   set to TRUE.  Otherwise, the pwdReset is removed from the user's
   entry if it exists.

So the question is how to determine whether the modification is performed by a
password administrator. There could be an attribute in the password policy entry
with values like authzTo/authzFrom to specify the set of password admins.
Comment 1 Quanah Gibson-Mount 2017-04-03 18:03:05 UTC
moved from Incoming to Software Enhancements
Comment 2 Ondřej Kuzník 2020-04-06 09:42:18 UTC
How about deciding whether this is an administrator by checking whether the authorization identity is the same as the entry DN? For those, we can add pwdReset to the modify unless already specified.

The concern is there might be management frontends that use a common identity for their LDAP requests and don't do ProxyAuthZ, do we just force them to do the right thing now?
Comment 3 Michael Ströder 2020-04-06 11:41:32 UTC
Maybe my original comment was not clear enough.

Of course it is sufficient for most use-cases to just check authz-DN != entryDN.

My suggestion was to define a new attribute for a pwdPolicy entry for defining authz-IDs considered to be an administrator - kind of an additional constraint to the condition above. The syntax could be similar or the same to that already implemented for authzTo/authzFrom attributes. But no proxy authorization allowed at all.
Comment 4 Ondřej Kuzník 2020-06-03 13:20:27 UTC
I have created a patchset that attempts to address this and other ppolicy related issues here:
https://git.openldap.org/openldap/openldap/-/merge_requests/77

Please review, test and let me know if this addresses the issue and if you have any other comments.
Comment 5 Quanah Gibson-Mount 2020-07-06 17:58:18 UTC
  • 49504c16 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
Fix whitespace in ppolicy.c


  • 3e0447f4 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7089 Skip lockout checks/modifications if password attribute missing


  • 3ec005a0 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7788 Report if there is a policy that applies


  • 0b6ac3fd 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7788 Skip lockout processing if no policy applies


  • a030aacc 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7788 Allow pwdFailureTime tracking be disabled in policy


  • 376d5d65 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7084 ACL of 'manage' gives pasword administrator access

Password administrators can bypass safeModify, password quality checks
and trigger reset if policy instructs the server to.


  • e05c09b9 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#8762 Clear pwdFailureTime on unlock


  • 5bf16496 
by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 
ITS#7084, ITS#7089, ITS#7788 Update test to account for new functionality