This is a multi-part message in MIME format. --------------060309030709060507050000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit
Hi Michael,
I'm having a bit of difficulty understanding your response, and it looks like my initial message was perhaps equally as unclear to you :-) Let me try to clarify, please let me know if this still doesn't make sense.
You mention that "pwdFailureTime is also used as a failure lockout counter". I don't see how that conflicts with what I am requesting. I'm only asking for /excess/ pwdFailureTime values that are above the pwdMaxFailure count to be purged. For example, if pwdMaxFailure is 3, and pwdFailureTime has the following values:
pwdFailureTime: 20150702184821Z pwdFailureTime: 20150702185821Z pwdFailureTime: 20150702190822Z pwdFailureTime: 20150702191007Z pwdFailureTime: 20150702191012Z
What I'm requesting is that the /oldest/ two values be deleted from this set:
pwdFailureTime: 20150702184821Z pwdFailureTime: 20150702185821Z
(To be more precise, I'll suggest that when ppolicy_bind_response() processes the BIND failure that triggers the addition of 20150702191012Z to pwdFailureTime, that's when it could delete the two oldest values. It already loops through the entire set of pwdFailureTime values, so adding a check to delete older ones above the pwdMaxFailure count could be done in that same loop).
I'm not seeing how this would conflict with the password policy specification -- am I missing something?
In the particular situation that's prompting this request, it's not just two or three values -- for one entry it was over 38000 values that had accumulated over time! (and generally high values for many other entries).
ITS#7161 doesn't address this issue -- it adds more precision to the timestamp values, but it doesn't purge excess stale values.
Here's how this issue relates to ITS#7089. In ITS#7089, the requester was seeing failed bind attempts to entries that didn't have a password defined. As a result, pwdFailureTime values were consistently being added to these entries. The common theme is that there is no built-in way (to my knowledge) in OpenLDAP to protect against pwdFailureTime values continually being added to entries indefinitely.
This enhancement would mitigate that problem by putting a cap on the number of pwdFailureTime attributes that could ever accumulate on an entry -- the pwdMaxFailure count. Just like administrators have control over expiring old log files, they would get the ability to ensure that pwdFailureTime values couldn't accumulate indefinitely.
Please let me know what you think.
Thanks,
-Kartik
Michael Stroeder wrote:
This wording in the slapo-ppolicy man page sounds friendly towards this interpretation: "Excess timestamps beyond those allowed by
pwdMaxFailure
may also be purged."
Looking at the source code though, it doesn't seem that pwdFailureTime values are actually removed unless a successful bind occurs --
whereupon
all values of course are removed.
I would like to request an enhancement to purge stale pwdFailureTime values as mentioned above.
Nope. The number of pwdFailureTime is also used as failure lockout counter. Actually it was improved with ITS#7161.
This would also largely mitigate the issue raised in ITS#7089
I don't see the relation with ITS#7089.
--------------060309030709060507050000 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
<html> <head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Michael,<br> <br> I'm having a bit of difficulty understanding your response, and it looks like my initial message was perhaps equally as unclear to you :-) Let me try to clarify, please let me know if this still doesn't make sense.<br> <br> You mention that "pwdFailureTime is also used as a failure lockout counter". I don't see how that conflicts with what I am requesting. I'm only asking for <i>excess</i> pwdFailureTime values that are above the pwdMaxFailure count to be purged. For example, if pwdMaxFailure is 3, and pwdFailureTime has the following values:<br> <br> pwdFailureTime: 20150702184821Z<br> pwdFailureTime: 20150702185821Z<br> pwdFailureTime: 20150702190822Z<br> pwdFailureTime: 20150702191007Z<br> pwdFailureTime: 20150702191012Z<br> <br> What I'm requesting is that the <i>oldest</i> two values be deleted from this set:<br> <br> pwdFailureTime: 20150702184821Z<br> pwdFailureTime: 20150702185821Z<br> <br> (To be more precise, I'll suggest that when ppolicy_bind_response() processes the BIND failure that triggers the addition of 20150702191012Z to pwdFailureTime, that's when it could delete the two oldest values. It already loops through the entire set of pwdFailureTime values, so adding a check to delete older ones above the pwdMaxFailure count could be done in that same loop).<br> <br> I'm not seeing how this would conflict with the password policy specification -- am I missing something?<br> <br> In the particular situation that's prompting this request, it's not just two or three values -- for one entry it was over 38000 values that had accumulated over time! (and generally high values for many other entries).<br> <br> ITS#7161 doesn't address this issue -- it adds more precision to the timestamp values, but it doesn't purge excess stale values.<br> <br> Here's how this issue relates to ITS#7089. In ITS#7089, the requester was seeing failed bind attempts to entries that didn't have a password defined. As a result, pwdFailureTime values were consistently being added to these entries. The common theme is that there is no built-in way (to my knowledge) in OpenLDAP to protect against pwdFailureTime values continually being added to entries indefinitely.<br> <br> This enhancement would mitigate that problem by putting a cap on the number of pwdFailureTime attributes that could ever accumulate on an entry -- the pwdMaxFailure count. Just like administrators have control over expiring old log files, they would get the ability to ensure that pwdFailureTime values couldn't accumulate indefinitely.<br> <br> Please let me know what you think.<br> <br> Thanks,<br> <br> -Kartik<br> <br> <br> Michael Stroeder wrote:<br> >> This wording in the slapo-ppolicy man page sounds friendly towards this<br> >> interpretation: "Excess timestamps beyond those allowed by pwdMaxFailure <br> >> may also be purged."<br> >><br> >> Looking at the source code though, it doesn't seem that pwdFailureTime<br> >> values are actually removed unless a successful bind occurs -- whereupon <br> >> all values of course are removed.<br> >><br> >> I would like to request an enhancement to purge stale pwdFailureTime<br> >> values as mentioned above.<br> ><br> > Nope. The number of pwdFailureTime is also used as failure lockout<br> > counter. Actually it was improved with ITS#7161.<br> ><br> >> This would also largely mitigate the issue raised in ITS#7089<br> ><br> > I don't see the relation with ITS#7089.<br> <br> </body> </html>
--------------060309030709060507050000--