I can't speak on behalf of the project but my position has not changed. If= we pursue your interpretation of the standard to a logical conclusion then= once the account is locked the user can never authenticate again. That is= not the intent.
The goal of any lockout mechanism is to make brute force password guessing = impractical. They keyword here is guessing. How many attempts should your= users have to legitimately guess their password? If your users don't know= their password then they need to change it anyway. If your users can't re= member the password they just changed then you have problems you can't addr= ess in code. If you want to give your users more than 3 attempts to guess = their password then set pwdMaxFailure to that value. Don't set it to a low= er value and then manually unlock their accounts multiple times. Unlocking= a user's account so that they can continue to guess their password adds no= value.
JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER@AEP.COM | D:614.716.4970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: MUNTEANU Mihai-Adrian [mailto:mihai.munteanu@thalesgroup.com]=20 Sent: Tuesday, October 31, 2017 3:57 AM To: Jon C Kidder; openldap-its@OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime
Hello Jon,
Have you reconsidered your resolution after my last comment related to the= password policy described in https://urldefense.proofpoint.com/v2/url?u=3D= https-3A__tools.ietf.org_html_draft-2Dbehera-2Dldap-2Dpassword-2Dpolicy-2D1= 0&d=3DDwIFAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&m=3DUita= RrJCJvbTRkNKnAG1MUsggW9F3FGUn7Nufv__g0U&s=3DxO5WwTWeNQanNDEj4KkwiizlVWEJDjY= kkfXMVAglLZM&e=3D ?
Thanks, Kind regards, Mihai
-----Original Message----- From: Jon C Kidder [mailto:jckidder@aep.com] Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its@OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime
This is not a bug.
pwdFailureTime is only cleared after the first successful bind. If you're = manually unlocking the user's account it can be assumed that you've gone th= rough the exercise of ensuring the user is using the proper password. Perh= aps by setting a new temporary password? If you haven't gone through that = exercise 1 attempt vs multiple attempts is not going to matter. The user i= s going to lock their account again anyway.
We've just recently deployed a password self-service tool and have accounte= d for this current behavior in our help desk procedures. Our cyber securit= y team loves this behavior.
JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER@AEP.COM | D:614.716.4= 970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O= f mihai.munteanu@thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its@OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu= reTime
This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac= hments. If suspicious please forward to incidents@aep.com for review.
********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_= incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&= m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-= sUN8henbPip3IgOunodI&e=3D Submission from: (NULL) (86.12.190.162)
Scenario:=20 0. we have configured that after 3 login failed attempts, the account to be= locked. 1. user test1 fails to login 3 times -> account is locked 2. admin unlocks = test1's account and notify test1 user 3. user test1 tries 1 time to login u= sing a wrong password and gets his account locked again. Expectation here: account should not be locked after first attempt of a wro= ng password, but after third attempt, as it was the case on step 1.=20 It turns out that it is locked again after first attempt due to the fact th= at on step 2, only pwdAccountLockedTime field is removed from LDAP, but not= also pwdFailureTime fields. It seems pwdFailureTime is internally cleared only: - when test1 successfully authenticate (having his account unlocked) - admin changes test1's password
See below my details: $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ...
$>cat unlock.ldif: dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime
$>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc= k.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed
$>cat unlock.ldif dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime
$>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f = unlock.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom"
$>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z entryCSN: 20171027055105.381686Z#000000#000#000000 ...
Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic= ally removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to = be automatically removed via removal of pwdAccountLockedTime.