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.