Subject: [ldapext] Working on password policy standardization

From: Clément OUDOT <[email-masked]>
Date: Wed, 18 Mar 2015 10:37:05 +0100

Hello,

following the mail of Ludovic requesting for help on drafts
standardization, and as proposed by Michael, I would like to start a
discussion on the password policy subject.

As a disclaimer, I would like to say that I never worked on publishing
drafts or RFC, it is my first attempt here. So please feel free to
point out all the mistakes I could do to help me improve this work.

1/ Current situation

We have two drafts on the subject:
* draft-behera-ldap-password-policy-10
* draft-zeilenga-ldap-passwords-00

I join them to this message.

As far as I know, the only implemented draft is the Behera draft, but
only in version 9. This is implemented at least in OpenLDAP, but also
in OpenDJ and ApacheDS (needs confirmation).

2/ Main drawbacks

A list of drawbacks of the Behera draft is presented in Zeilinga draft
in Appendix A. I will not reproduce them all here but focus on the
most important (from my point of view):
* The lock/unlock feature for directory administrators is not clear,
and relies on an operational attributes (pwdAccountLockedTime) that
should not be written by administrators
* There is no time limit for grace authentications
* Disallowing password change should be done with ACL, not ppolicy configuration
* PPolicy do not allow DSA-generated passwords

I would add some others:
* There is no definition of what "directory administrators" are, and
how provide them specific rights to handle password policy
* There is no indication on how apply a password policy to a group of
users (I know there was a discussion on this on ApacheDS mailing list
some days ago)
* The password checker feature is complex to implement. Default
password policy allows to specify min lenght (and max lenght), and
history check. Why not define in the standard policy how to check
different class of characters (upper, lower, digits, etc.)? And also
the possibility to refuse a password containing the value of an
attribute of the entry (uid, cn, etc.)?
* The "password change after reset" feature is also complex to
implement, and often ignored by LDAP clients, as the BIND result is
always true (the password change after reset information is only
present in response control).
* There is not authentication date. This is a common requested
feature. It is for example implemented in lastbind overlay in
OpenLDAP.

And also a remark from Ludovic on this list:
> There was a general consensus that the current password policy draft needs to be split in multiple documents to separate the configuration of it, the internal state representation and the management side of it (controls and possible extended operations).

3/ Goals

* Split password policy drafts in multiple documents :
  - Configuration
  - Internal state representation
  - Management (controls and extended operation)

* Remove all unused features of current drafts (pwdAllowUserChange, ...)

* Clarify all the administration operations, and how to allow them to
directory administrators

* Provide more rules on password policy checking

* Propose a technical solution to apply a password policy to a list of
users (for example with collective attributes)

I would be happy to have your feedback on this message, and advices on
how to advance on this topic.

Clément OUDOT.