[Date Prev][Date Next]
Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
- From: firstname.lastname@example.org
- Date: Mon, 06 Jul 2015 17:30:47 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Kartik Subbarao wrote:
> On 07/06/2015 12:25 PM, Michael Str=C3=B6der wrote:
>> Hmm, still have some doubts: If you want to raise the failure count li=
>> later you would automatically unlock some accounts you don't want to u=
>> at this particular point in time.
> Two thoughts on this:
> 1) If you raise the failure count limit, aren't you inherently making a=
> decision to be more lenient in your policy, and thereby accepting that =
> accounts are not going to be locked out as fast as they might be under =
> previous policy?
Yes, there could be a situation where you want to deliberately relax the
lockout policy after carefully considering various security aspects of yo=
> It seems to me that any "inadvertent" unlocking due to purged
> pwdFailureTime values could be embraced under this general umbrella of =
No! You set a new lockout limit and most people would expect this to be s=
effective on user accounts which did not reach the new limit yet.
> 2) If pwdFailureCountInterval is set to some reasonably low number, the=
> whole concern becomes moot: Just wait for pwdFailureCountInterval secon=
> after you decide to change the configuration, before actually changing =
> configuration :-)
Consider that you are under on-going attack with many different accounts
affected by the lockout treshold. Then you cannot simply wait for
pwdFailureCountInterval seconds because your system is changing all the t=
Such a situation is a real world scenario.
=3D> @OpenLDAP developers: leave as is!
P.S.: I'm not a big fan of password lockout anyway because it's misconfig=
too often because of brain-dead comapny security policies.