[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes

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=
particular deployment.

> 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=
n this
> 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!

Ciao, Michael.

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.