> 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