This is a multi-part message in MIME format. --------------000605000401060905080908 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit
On 07/06/2015 12:25 PM, Michael Ströder wrote:
Hmm, still have some doubts: If you want to raise the failure count limit later you would automatically unlock some accounts you don't want to unlock 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 some accounts are not going to be locked out as fast as they might be under the previous policy? It seems to me that any "inadvertent" unlocking due to purged pwdFailureTime values could be embraced under this general umbrella of leniency.
2) If pwdFailureCountInterval is set to some reasonably low number, then this whole concern becomes moot: Just wait for pwdFailureCountInterval seconds after you decide to change the configuration, before actually changing the configuration :-)
I guess I haven't come across many sites that set pwdMaxFailure, but /don't/ also set pwdFailureCountInterval. But even in those cases, I think #1 would be valid :-)
Regards,
-Kartik
--------------000605000401060905080908 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 07/06/2015 12:25 PM, Michael Ströder wrote:<br> </div> <blockquote cite="mid:559AABDC.8060706@stroeder.com" type="cite"> <pre wrap=""> Hmm, still have some doubts: If you want to raise the failure count limit later you would automatically unlock some accounts you don't want to unlock at this particular point in time. </pre> </blockquote> <br> Two thoughts on this:<br> <br> 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? It seems to me that any "inadvertent" unlocking due to purged pwdFailureTime values could be embraced under this general umbrella of leniency.<br> <br> 2) If pwdFailureCountInterval is set to some reasonably low number, then this whole concern becomes moot: Just wait for pwdFailureCountInterval seconds after you decide to change the configuration, before actually changing the configuration :-)<br> <br> I guess I haven't come across many sites that set pwdMaxFailure, but <i>don't</i> also set pwdFailureCountInterval. But even in those cases, I think #1 would be valid :-)<br> <br> Regards,<br> <br> -Kartik<br> </body> </html>
--------------000605000401060905080908--