This section explains the policy attributes that govern account lockout.
A Directory Server account refers loosely to a user's entry and to the permissions that user has to perform operations on the directory. Each account is associated with a bind DN and a user password. When an intruder appears to be trying to crack a password, you want Directory Server to lock the account. The lock prevents the intruder from using the account to bind. The lock also prevents the intruder from being able to continue the attack.
As administrator, you can also manually render inactive an account or the accounts of all users who share a role. See Manually Locking Accounts for instructions. Yet, a key part of your password policy is specifying under what circumstances Directory Server locks an account without your intervention.
First of all, you must specify that Directory Server can use pwdLockout(5dsat) to automatically lock accounts when too many failed binds occur. Directory Server keeps track of consecutive failed attempts to bind to an account. You use pwdMaxFailure(5dsat) to specify how many consecutive failures are allowed before Directory Server locks the account.
Directory Server locks accounts strictly according to password policy. The operation is purely mechanical. Accounts can lock not because an intruder is mounting an attack against the account, but because the user typed the password incorrectly. Thus, you can use pwdFailureCountInterval(5dsat) to specify how long Directory Server should wait between tries before cleaning out the records of failed attempts. You use pwdLockoutDuration(5dsat) to specify how long lockout should last before Directory Server automatically unlocks the account. The administrator does not have to intervene to unlock accounts of users who make legitimate mistakes with no malicious intent.
If your user data is replicated across a replication topology, lockout attributes are replicated along with other entry data. The pwdIsLockoutPrioritized(5dsat) attribute's default setting is TRUE, so updates for lockout attributes are replicated with a higher priority. A user is thus limited to making pwdMaxFailure consecutive failed attempts to bind to any single replica before being locked out, and probably fewer attempts at other replicas before being locked out. For details about how to make sure that a user gets exactly pwdMaxFailure attempts before being locked out across an entire replicated topology, see Preventing Authentication by Using Global Account Lockout in Sun Java System Directory Server Enterprise Edition 6.3 Deployment Planning Guide.