Re: replication delay problem

[Cyril Grosjean <cgrosjean@janua.fr>]

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.

Attachment: smime.p7s
Description: Signature cryptographique S/MIME