The pwdFailureTime
attribute is deleted when a user successfully binds.
It's added to each user object to track how many failed binds have occurred since the last successful bind, part of the whole point of using the ppolicy
overlay so dumping and reloading the database to get rid of them doesn't really make any sense.
The pwdMaxFailure
attribute in your policy object sets how many failed binds are tracked before the action defined by the pwdLockout
attribute is triggered. It defaults to 0 which means an unlimited number of failures are tracked (which might explain the behaviour you're seeing), but if you then set it to a non-zero number you will then trigger pwdLockout
which defaults to true after that many failures. This will mean users get locked out of their account, however if user objects are accumulating pwdFailureTime
attribute values to the degree that you're uncomfortable seeing them then it means they're not successfully binding anyway.
You can also try setting the pwdFailureCountInterval
attribute on your policy object which according to the documentation will reset the failed password count after value
seconds which I would assume clears any pwdFailureTime
attributes to achieve that, but then you're changing the heuristics for tracking failed binds.