--On Monday, July 06, 2015 5:12 PM +0000 [email protected] 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
