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.
