Antw: replication delay problem

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

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

>>> Cyril Grosjean <cgrosjean@janua.fr> schrieb am 11.02.2014 um 19:59 in Nachricht
<52FA730C.2020305@janua.fr>:

> I use a couple of OpenLDAP 2.4.36 servers in a multi-master replication 
> setup.
> Write operations are sent to a single server, and then replicated to the 
> second one.
> 
> 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 ?