[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
- From: subbarao@computer.org
- Date: Mon, 06 Jul 2015 16:12:14 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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--