Ryfujk

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.