coudot@linagora.com wrote:

Le 16/01/2014 15:31, Howard Chu a écrit :

...

coudot@linagora.com wrote:

...

Full_Name: Clement OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122)

Here is the situation : a user account is 1/ expired (the password age is more that the one configured in pwdMaxGae) 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy configuration object is TRUE)

In this case, when doing a BIND, the result code is 0: $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy ldap_bind: Success (0); Password must be changed (Password expires in 0 seconds) dn: uid=coudot,ou=users,dc=example,dc=com

If I remove pwdReset attribute, then: $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy ldap_bind: Invalid Credentials (49); Password expired

According to password policy draft, the password must change flag should not affect the BIND result code.

The draft specifies the policy checks in the order in which they are to be performed. The PasswordMustBeChanged check occurs before the PasswordExpired check.

The code works as designed.

Well, I understand. If this is not a bug in the OpenLDAP implementation, it is maybe a point to discuss in the draft. Indeed, a simple LDAP client (that don't use ppolicy control) will get a successful BIND response even if the password is expired.

How can the password be expired if the admin has just reset it?

Maybe it is the wanted behavior, maybe not.

The fact is that if an administator reset the password (by changing password value and setting pwdReset to TRUE), this reseted password will never expire. From my point of view, this is a security flaw in the password policy system, as a lot of applications just use the BIND operation on LDAP server (searches and other operations are done by application LDAP accounts).

I agree that the MustChange feature doesn't mesh well with applications that simply perform a Bind and then do nothing else. Feel free to raise this point on the ldapext mailing list.