https://bugs.openldap.org/show_bug.cgi?id=10261
Issue ID: 10261 Summary: draft-behera-ldap-password-policy - evolution pwdAccountDisabled Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: david.coutadeur@gmail.com Target Milestone: ---
Hello,
For information, I tried to send a mail at: draft-behera-ldap-password-policy@ietf.org first, but I get a: Recipient address rejected: User unknown
I'd like to propose an evolution for the current version of draft-behera-ldap-password-policy.
Indeed, in the specification, there is the notion of locked or blocked account, with the presence of pwdAccountLockedTime, preventing users from authenticating.
However:
* any account with sufficient privileges can modify the userPassword
* when he does so, the pwdAccountLockedTime is removed
This behaviour is advisable most of the time. But sometimes we need a more restrictive policy.
The goal of this evolution is to propose an alternate behaviour where the "disabling attribute" is never removed unless asked explicitely, and where userPassword cannot be modified until the "disabling attribute" is present.
This attribute could be named pwdAccountDisabled.
Here is the proposed evolution:
4.1.1. Password Validity Policy
...
A password cannot be used to authenticate while the corresponding account has been disabled.
4.2.8. Disabled account
A password cannot be changed while the password owner has been disabled. While doing so, the LDAP directory should send a Constraint violation (19) error code with additional info: Account is disabled.
5.3.12. pwdAccountDisabled
This attribute holds the time that the user's account was disabled. A disabled account means that the password may no longer be used to authenticate and none can change the userPassword until it is disabled.
( 1.3.6.1.4.1.42.2.27.8.1.33 NAME 'pwdAccountDisabled' DESC 'The time an user account was disabled' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE directoryOperation )
Thanks in advance for your consideration. Of course, it is opened to discussion, and maybe can I help a little for the implementation.
Regards,