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 ?
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
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 ?
2014-02-11 19:59 GMT+01:00 Cyril Grosjean cgrosjean@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 ?
You may face this bug: http://www.openldap.org/its/index.cgi?findid=7788
To limit pwdFailureTime, you had to attach a password policy to the account with a max failure number, else number of values will grow over the time.
Clément.
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 ?
You may face this bug: http://www.openldap.org/its/index.cgi?findid=7788
To limit pwdFailureTime, you had to attach a password policy to the account with a max failure number, else number of values will grow over the time.
Clément.
2014-03-01 9:20 GMT+01:00 Cyril Grosjean cgrosjean@janua.fr:
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 !)
You can keep it TRUE but let a lockout duration of 1s for example.
- 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.
Yes this is a bug.
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 ?
I think you will have to upgrade to the latest version. I have no idea when the fix will be provided.
Clément.
Cyril Grosjean wrote:
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.
I strongly disagree. I don't use password failure lockout but I definitely want to see pwdFailureTime appear!
When can we expect it to be fixed ?
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.
2014-03-01 13:29 GMT+01:00 Michael Ströder michael@stroeder.com:
Cyril Grosjean wrote:
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.
I strongly disagree. I don't use password failure lockout but I definitely want to see pwdFailureTime appear!
I disagree too. It's not because you find it useful that it should not be considered as a bug.
An entry that is not associated to a password policy (and no default ppolicy configured) should not own any ppolicy operational attribute.
When can we expect it to be fixed ?
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.
No, if you want pwdFailureTime, you should configure a ppolicy for the entry, or configure a default ppolicy.
Clément.
Clément OUDOT wrote:
An entry that is not associated to a password policy (and no default ppolicy configured) should not own any ppolicy operational attribute.
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.
2014-03-01 20:07 GMT+01:00 Michael Ströder michael@stroeder.com:
Clément OUDOT wrote:
An entry that is not associated to a password policy (and no default ppolicy configured) should not own any ppolicy operational attribute.
Why?
'pwdFailureTime' is declared as
NO-USER-MODIFICATION USAGE directoryOperation
and is not referenced in any object class at all.
But it is an operational attribute of password policy, and it is loaded with ppolicy overla.
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.
It is your point of view, not mine. An OpenLDAP developer should give its own.
Clément.
Clément OUDOT wrote:
2014-03-01 20:07 GMT+01:00 Michael Ströder michael@stroeder.com:
Clément OUDOT wrote:
An entry that is not associated to a password policy (and no default ppolicy configured) should not own any ppolicy operational attribute.
Why?
'pwdFailureTime' is declared as
NO-USER-MODIFICATION USAGE directoryOperation
and is not referenced in any object class at all.
But it is an operational attribute of password policy, and it is loaded with ppolicy overla.
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?
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.
It is your point of view, not mine. An OpenLDAP developer should give its own.
Yes, it's my personal view. Just like saying ITS#7788 is a bug is yours.
Ciao, Michael.
2014-03-02 18:35 GMT+01:00 Michael Ströder michael@stroeder.com:
Clément OUDOT wrote:
2014-03-01 20:07 GMT+01:00 Michael Ströder michael@stroeder.com:
Clément OUDOT wrote:
An entry that is not associated to a password policy (and no default ppolicy configured) should not own any ppolicy operational attribute.
Why?
'pwdFailureTime' is declared as
NO-USER-MODIFICATION USAGE directoryOperation
and is not referenced in any object class at all.
But it is an operational attribute of password policy, and it is loaded with ppolicy overla.
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?
That's not what I said. I said pwdFaliureTime must not be updated for an entry without ppolicy attached, nothing to see with password lockout.
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.
It is your point of view, not mine. An OpenLDAP developer should give its own.
Yes, it's my personal view. Just like saying ITS#7788 is a bug is yours.
Please read well the ITS. There is nothing linked to password lockout.
Clément.
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.
openldap-technical@openldap.org
-
Clément OUDOT -
Cyril Grosjean -
Michael Ströder -
Ulrich Windl