Full_Name: Jeffrey Crawford
Version: 2.4.26
OS: FreeBSD 8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (169.233.231.78)


Note: The following was copied from my mailing list question and it was
suggested that it be made an enhancement request:

Hello Everyone,

I'm having trouble enforcing our password policy for login attempts
within a particular time frame. After looking into the issue a little
further it seems to stem from the fact that the operational attribute
pwdFailureTime can only resolve time down to the second. so if there
are three Bind attempts within a single second we only get a single
pwdFailureTime entry for that time. Our policy is geared more to try
and prevent brute force attacks since this instance of the ldap server
will be available publicly. However someone can continuously try to
bind and not lock the account for as many seconds as is defined in the
pwdMaxFailure attribute in the policy definition.

For example:
if the following account locking configs are set
pwdMaxFailure: 10
pwdFailureCountInterval: 3600
pwdLockout: TRUE
pwdLockoutDuration: 30

If I try to lock my account by providing the incorrect credentials 11
times, it didn't lock if my 11 attempts were shorter than 10 seconds,
I then tried 100 in a for loop which finished in 7 seconds, it still
didn't lock. I looked at the account and counted the number of
pwdFailureTime's and found 7. I then place a one second sleep between
each bad bind attempt and low an behold it would lock as expected.
Therefore there seems to be a limitation of pwdFailureTime to only
resolve down to the second and its inability to store the same time
multiple times.

I'm not sure if this is expected behavior, but it makes locking
policies against brute force attacks more difficult to fend against. I
did a quick look to see if there was a way of delaying a incorrect
credential bind so it wouldn't return for at least a second, but
didn't see one. If such a config exists it might help if someone can
point me to it.

Thanks
Jeffrey Crawford