-jim
Jim Willeke
On Thu, Jul 1, 2010 at 6:53 AM, Howard Chu <hyc@highlandsun.com
<mailto:hyc@highlandsun.com>> wrote:
Jim Willeke wrote:
Just a comment on our experiences with LDAP server delays on failed
bind attempts.
We have encountered issues with applications when there is a delay between
failed attempts.
When there is an delay, the application is left waiting for a response
from
the server.
This was the case with Novell's eDirectory for many years, there was a
fixed
delay, and due to this condition, Novell added a feature to make the delay
adjustable.
If the delay is 3 seconds and five people in a row fail there
password, the
application can only handle 5 people in 15 seconds, which is an
eternity in
our context.
If the return code is returned immediately, then the application can
end the
LDAP session immediately and move on to the next operation.
Also, features like this are obviously optional. If you have a directory
server that is routinely being used by applications, then you probably
want to isolate it from arbitrary clients, and not even deploy any
lockout/delay features at all.
Unfortunatly, applications are nto created equally and usually the goal is to
use LDAP as the authentication source. As I see the recommendation, this
would require pushing the Password (and Account Restriction) Policy
Enforcement Point to ALL the different applications which, IMHO, is not a good
thing and the implementation would woudl require that all applications be
capable of utilizing the same ability to perform the enforcement.