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

[michael@stroeder.com]

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=
mit
>> later you would automatically unlock some accounts you don't want to u=
nlock
>> at this particular point in time.
>=20
> Two thoughts on this:
>=20
> 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 =
some
> accounts are not going to be locked out as fast as they might be under =
the
> 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=
ur
particular deployment.

> It seems to me that any "inadvertent" unlocking due to purged
> pwdFailureTime values could be embraced under this general umbrella of =
leniency.

No! You set a new lockout limit and most people would expect this to be s=
olely
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=
ds
> after you decide to change the configuration, before actually changing =
the
> 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=
ime.

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=
ured
too often because of brain-dead comapny security policies.