https://bugs.openldap.org/show_bug.cgi?id=9794
Issue ID: 9794
Summary: Define behaviour for pwdChangedTime modifications
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
This issue applies to:
- draft-behera-ldap-password-policy
- openldap 2.5
- openldap 2.6
It is a proposition of behaviour for pwdChangedTime modifications.
modification of the draft:
--------------------------
In section: "8.2.7. Policy State Updates", change this paragraph:
If the value of either pwdMaxAge or pwdMinAge is non-zero, the server
updates the pwdChangedTime attribute on the entry to the current
time.
into:
If the value of either pwdMaxAge or pwdMinAge is non-zero, the server
MUST update the pwdChangedTime attribute on the entry according to this
workflow:
Then insert a new paragraph:
- if the current operation (add or modify) on the password includes
adding or modifying a valid pwdChangedTime attribute, then use this
pwdChangedTime. A "Valid" pwdChangedTime means a syntactically
correct value, compliant with the schema, approved by access rules,
and MAY require a relax control according to the schema defined in
section 5.3.2.
See Relax control RFC for more information:
https://datatracker.ietf.org/doc/html/draft-zeilenga-ldap-relax
- an invalid pwdChangedTime value MUST result in an error, and the
pwdChangedTime MUST NOT be stored
- in any other case, compute the current date and store it in a
GeneralizedTime format
Feel free to comment or propose other ideas.
modification of the code:
--------------------------
If this behaviour makes a consensus, it would be useful to patch both OpenLDAP
2.5 and 2.6.
NOTE: current OpenLDAP 2.5 allows modifying pwdChangedTime alone, but fails to
add a user with both userPassword and pwdChangedTime (it results in a
duplicated pwdChangedTime error)
modification of the documentation:
----------------------------------
In slapo-ppolicy, it can be useful to add a comment in "OPERATIONAL ATTRIBUTES"
section:
Every attribute defined as "NO-USER-MODIFICATION" SHOULD not be
written by standard users.
If needed, an administrator MAY modify them with the relax control.
See Relax control RFC for more information:
https://datatracker.ietf.org/doc/html/draft-zeilenga-ldap-relax
--
You are receiving this mail because:
You are on the CC list for the issue.
