Hi! I don't know the current versions and theit improvements, but the usual solutions would be these: 1) Delay the error after repeated auth failure, maybe exponentially (con: connections may increase) 2) Automatically blacklist a user after a number of auth failures (con: a valid user may be locked out by attacker) 3) Automatically blacklist a host that is causing repeated auth failures (con: other users from the same host may be locked out) 4) Temporarily disable a combination of host/user after repeated auth failures (there should be a mechanism to reset) Such blacklists could be stored in LDAP, naturally... Regards, Ulrich <52FA730C.2020305(a)janua.fr&gt;:

Hi Clément, After intense testing sessions, both with OpenLDAP 2.4.28 and 2.4.39, I come to the conclusion that as far as I don't want the account to be locked after too many failures, there's no way to either limit the number of pwdFailureTime attributes per user or just prevent this attribute to be updated and thus the number of values increases indefinitly until the account is reset or the user binds successfully: - pwdmaxFailure is efficient only if pwdLockout is TRUE (but I want to keep it FALSE !) - whatever password policy is specified for the user (no policy (that is, use the default which has pwdLockout set to false), unexisting policy, or specific existing policy), the pwdFailtureTime is created and increases. pwdFailureTime should not exist or at least should not increase when pwdLocjout is false. So it looks to me like a bug, as you mentioned. When can we expect it to be fixed ? Will it require to upgrade to the latest OpenLDAP version or will it be backported so that if for example I use 2.4.36, I'll have the fix available if I recompile ?

Cyril Grosjean wrote: I strongly disagree. I don't use password failure lockout but I definitely want to see pwdFailureTime appear! There's no need for a fix. ITS#7788 is not a bug! I find pwdFailureTime *very* useful for reporting login failure in a 3rd-party component even without using slapo-ppolicy's lockout feature. If you don't want pwdFailureTime then simply you should not load slapo-ppolicy. Ciao, Michael.

Clément OUDOT wrote: Why? 'pwdFailureTime' is declared as NO-USER-MODIFICATION USAGE directoryOperation and is not referenced in any object class at all. In the context of this discussion you can only argue that it should or should not be replicated. But ITS#7788 is not a bug. It's just a certain implementation. Ciao, Michael.

Clément OUDOT wrote: So what? Can you please point me to any text saying that 'pwdFailureTime' MUST NOT be used if password lockout is not used and especially why? Yes, it's my personal view. Just like saying ITS#7788 is a bug is yours. Ciao, Michael.

Thank you for your feedback Michael. I partly agree with you as well as with Clément. Depending on the business needs, one solution or the other should be configurable. If I have different types of users, I may need to maintain bind failure times for some of them, but not all of them. So, removing the ppolicy overlay is not a solution. Also, you can determine bind failure times through the logs. It will prevent unuseful access to the directory and allow you to get failure times for deleted users, so enabling you to work asynchronously. Also, I can't understand why max. failure count should not limit the number of failure times per user when pwdLockout is false. I want to limit the number of values for the pwdfailuretime for some users only, and without locking them. And I just can not do that with OpenLDAP. Setting the lockout duration to 1 second as suggested by Clément could be a workaround, but I have to test it to check possible side effects. If you want to keep the trace of an unlimited number of failure times, the logs are the best place: otherwise, it's a joke to build a denial of (replication) service by sending bad credentials continuously. Some customers have business cases where using account lockout is not an option. But we of course need to protect them against DoS attacks too. Slowing the replication flows can be considered as some kind of DoS, depending on one's use cases. I understand that for some other use cases, keeping the track of bind failures in entries is efficient and not necessarily dangerous for replication that's why I think it should be configurable. And if not, I find it's at least limitation if not a bug.