8 Sep
2011
8 Sep
'11
10:49 p.m.
On Thu, 2011-09-08 at 14:03 -0500, Timothy Pearson wrote:
<snip>
No problem. That's kind of what I thought but I thought I'd ask anyway.
Yes, the option seems to be to increase the number of failed attempts -
that ever present tension of lessening security to enhance
functionality. Thanks - John
Hello, all. I
think this is more of a usage than a development
question. Most of our applications authenticate against LDAP. Many of
these same applications store their passwords in KWallet. If the
password changes, KWallet remembers the old one until it fails and the
user is prompted for a new one. But, when it fires off requests for
several different applications at once, LDAP locks the account so users
are unable to enter the new password. Has anyone found a way to work
around this? I'll explain in more detail in case it is not clear.
In our case, the culprit is usually Kontact and KOrgac. They may store
passwords for an email account, several calendars, several address
books, a task list, etc. When the user changes their LDAP password, the
first time these application try to synchronize, they may send 8, 10,
12, however many requests for authentication depending on the number of
email accounts, calendars, etc. All those requests at once with wrong
passwords look like a brute force attack and LDAP locks the account.
Any tips on getting around this problem would be greatly appreciated.
Thanks - John
You are running into a problem that, in theory, any multithreaded
application that uses concurrent LDAP connections will have. The only
thing I can think of is to block the other threads until the first one
authenticates, but that is nasty to implement on our end and would most
likely introduce significant lag from the user's point of view.
Can you change the number of invalid login attempts before lockout occurs?
I am a bit surprised that the LDAP server is not intelligent enough to
see that the login attempts all use the same (old) password, which would
imply that there is no brute force attack occurring.
Sorry I can't be of much more help!
Tim