--On Monday, July 06, 2015 5:12 PM +0000 subbarao(a)computer.org wrote:
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
I would note that:
IF using delta-syncrepl
AND the data values are replicated
AND authentication attempts can occur against different LDAP masters
You can run into *serious* drift between servers if you try and implement
this, causing endless refresh mode runs that cause the servers to get
further out of sync. See
<
http://www.openldap.org/its/index.cgi/?findid=8125>.
More specifically:
If a client has (most often) a mobile device with a bad password, and it's
authentication attempts are bouncing between masters, even with high
resolution timestamps, you can get collisions in the delete op for old
values that cannot be reconciled, causing fallback/refresh.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration