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

[quanah@zimbra.com]

--On Monday, July 06, 2015 5:12 PM +0000 subbarao@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