--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