I've set up an LDAP server with the ppolicy overlay, but now am having trouble resetting user's password in some cases: if the user has a failed login, then the pwdFailureTime attribute exists and ldapmodify fails complaining that it doesn't.

If my most recent log-in attempt was successful, then I can bind as cn=admin and run the ldif file:

dn: uid=anton,ou=accounts,dc=[redacted],dc=ca
changetype: modify
replace: userPassword
userPassword: foobar
replace: pwdReset
pwdReset: TRUE

which succeeds. However, if the last log-in attempt was with a wrong password, ppolicy adds a pwdFailureTime attribute to the account, and then trying to run the ldif file above results in:

$ ldapmodify -x -D "cn=admin,dc=[redacted],dc=ca" -W -H ldap:// -f pwreset.ldif
Enter LDAP Password: 
modifying entry "uid=anton,ou=accounts,dc=[redacted],dc=ca"
ldap_modify: No such attribute (16)
    additional info: modify/delete: pwdFailureTime: no such attribute

If I try deleting the pwdFailureTime attribute before resetting the password, then I get:

ldap_modify: Constraint violation (19)
    additional info: pwdFailureTime: no user modification allowed

In real life, if a user's forgotten their password and needs it reset, they will generally have tried to recall the password several times, so will have the pwdFailureTime attribute set. Any suggestions?


As for the IETF draft states :

8.2.7. Policy State Updates

If the steps have completed without causing an error condition, the server performs the following steps in order to update the necessary password policy state attributes:

If the value of either pwdMaxAge or pwdMinAge is non-zero, the server updates the pwdChangedTime attribute on the entry to the current time.

If the value of pwdInHistory is non-zero, the server adds the previous password (if one existed) to the pwdHistory attribute. If the number of attributes held in the pwdHistory attribute exceeds the value of pwdInHistory, the server removes the oldest excess passwords.

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.

The pwdFailureTime and pwdGraceUseTime attributes is removed from the user's entry if they exist.

If I'm not mistaken, LDIF is atomic operations, so when the userPassword is modified, it chains to removing the pwdFailureTime attribute, hence why when the modification of pwdReset which seems to trigger also the removing of pwdFailureTime fails.

Why do you need to set the pwdReset to TRUE ? You already reset it. If it is to ensure that the user must "reset" himself the password at the first connection :

may be try instead to modify the pwsMustChange attribute to TRUE, which should set the pwdReset attribute to TRUE(according to the IETF on which is based the OpenLDAP ppolicy)

or may be just switch the two modifications on the LDIF could do the trick.

  • Sorry, didn't get back to this until now. I've left pwdMustChange as FALSE, because mostly my users will be interacting through a web page, which I've put together using PHP, which only has an ldap_modify, which someone with pwdReset=TRUE wouldn't have permission to use... Removing the lines resetting pwdReset doesn't change the error, and I get the same error using phpLdapAdmin, or using ldappasswd at the command line. – Anton Jun 22 '17 at 21:18
  • Ah, however, if I switch the two modifications in the LDIF, then it appears to work. I did hit some other issues, which all seem to centre around the problem that if any policies in ppolicy are triggered, these create internal attributes, and then password changes fail because those attributes don't exist (but only where they actually do). So I guess the workaround for now is to basically not use any of the policies. – Anton Jun 22 '17 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.