RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime

[jckidder@aep.com]

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.