Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes - openldap-bugs

6 Jul 2015


      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>
    &gt;&gt; This wording in the slapo-ppolicy man page sounds friendly
    towards this<br>
    &gt;&gt; interpretation: "Excess timestamps beyond those allowed by
    pwdMaxFailure <br>
    &gt;&gt; may also be purged."<br>
    &gt;&gt;<br>
    &gt;&gt; Looking at the source code though, it doesn't seem that
    pwdFailureTime<br>
    &gt;&gt; values are actually removed unless a successful bind occurs
    -- whereupon <br>
    &gt;&gt; all values of course are removed.<br>
    &gt;&gt;<br>
    &gt;&gt; I would like to request an enhancement to purge stale
    pwdFailureTime<br>
    &gt;&gt; values as mentioned above.<br>
    &gt;<br>
    &gt; Nope. The number of pwdFailureTime is also used as failure
    lockout<br>
    &gt; counter. Actually it was improved with ITS#7161.<br>
    &gt;<br>
    &gt;&gt; This would also largely mitigate the issue raised in
    ITS#7089<br>
    &gt;<br>
    &gt; I don't see the relation with ITS#7089.<br>
    <br>
  </body>
</html>
--------------060309030709060507050000--