From subbarao@computer.org Mon Jul 6 16:12:16 2015 From: subbarao@computer.org To: openldap-bugs@openldap.org Subject: Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes Date: Mon, 06 Jul 2015 16:12:14 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3989718552517489196==" --===============3989718552517489196== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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 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-- --===============3989718552517489196==--