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
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...
>> Cyril Grosjean <cgrosjean(a)janua.fr> schrieb am
11.02.2014 um 19:59 in Nachricht
I use a couple of OpenLDAP 2.4.36 servers in a multi-master
Write operations are sent to a single server, and then replicated to the
I sometimes have write operations "peaks" of about 900 operations
(modifications of the pwdFailureTime attribute mainly) per hour.
The number of bind failures per user is neither limited nor reset yet and I
especially noticed a script that connects to the directory with the
same service account and (wrong) password. So, until this script is
modified with the right password (which will take time, unfortunately),
it can generate tons of failures, and thus tons of replications.
I noticed a several minutes replication delay between the directories, at
peak time, when comparing the contextCSN attributes.
It looks to me a big delay with regards to the number of modifications.
Anything I could do to limit that delay ?