Re: password policy: delayed failures

Jim Willeke wrote:
>
>
> -jim
> Jim Willeke
>
>
> On Thu, Jul 1, 2010 at 6:53 AM, Howard Chu <[email protected]
> <mailto:[email protected]>> 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.

But that seems to ultimately be what you're asking for. "if the return code is 
returned immediately, then the application can end the LDAP session 
immediately" - so basically you want no restriction in the directory, and push 
the responsibility out to the application.

Or, you want a different policy for each application - which is feasible, if 
each application first authenticates as its own identity and then uses some 
"special" Bind to authenticate its client.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/