On Thu, 2011-09-08 at 14:03 -0500, Timothy Pearson wrote:
> > 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
<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