DS 6 - passwordRetryCount and Account Unlock

Question

Previously, we used to remove the passwordRetryCount attribute in DS 5.2 to unlock an account that had been locked by exceeding the password retry limit.
I'm not seeing DS 6 work in the same fashion. Is there a way to programatically 'unlock' a locked account?

Answer 1

If you need to programatically lock and
unlock accounts, perhaps you can use the
nsAccountLock attribute, which is intended forthat
purpose.The original post was regarding the act of unlocking
an account after the DSA has locked it due to
excessive password retry errors. The DSA uses the
operational attributes rather than the nsAccountLock
attribute and the only way for an "administrator" to
unlock the account without altering the old
passwordRetryCount attribute or deleting the newer
operational attributes is to change the password.
If your users don't mind having their password reset
every time they fat finger that 12
alphanumeric+special character password 3 times in a
row that they're required to come up with every 90
days ( and they're not allowed to use their previous
ten passwords ) then that's obviously the way to go.Could you increase passwordMaxFailure to a value large enough that you can be fairly sure that the user really has forgotten the password? Since the intention of the auth-failure-lockout policy is to thwart dictionary attacks, a passwordMaxFailure value of 6 or even 10 would not weaken the policy.
Also don't forget the a**holes running around who
just love to intentionally enter another user's
password wrong just to make their day. That is one of the purposes of the auth-failure-lockout timeout. You can set passwordUnlock:on and passwordLockoutDuration to some value like 600 (10 minutes), again without significantly reducing protection against dictionary attacks. You might want to look at enabling passwordResetFailureCount, also, although I'm not sure what value it offers in this scenario.
>
Naturally, these anal retentive password polices
don't exist for everyone's environment but some of us
are forced to endure them.Obviously, you are pretty familiar with Directory Server administration. Can you convince whomever sets the security policy for your organization that allowing an adminstrator to manually reset the lockout is not any more secure than tuning the Directory Server policy to automatically handle it?
On a related note, if you want to monitor dictionary attack attempts by scanning the access log, we made some changes in Directory Server 6 so that the "additional information" returned to the client is now written in the log. So you could periodically look for the string "Exceed password retry limit. Account locked." in the access log. I'm not sure if logconv has been updated to help with this search.