By default, the Trusted Solaris environment allows a maximum of five failed attempts to enter the correct password during a single access attempt. If a user or role account enters the wrong password one time too many during a single attempt, the account is locked. Having such a limit helps forestall brute force attempts to gain access by guessing multiple different passwords.
A count of incorrect passwords entered during a single attempt is kept in the flag field of the user or role's entry in the local shadow(4) file or in the NIS+ table.
Because NIS does not make the flag field of the shadow database available, a count of failed retries cannot be maintained on a system that relies on the NIS name service. If enforcing a maximum number of failed login attempts is essential to your site's security policy, use either NIS+ or local files.
If the user or role enters the correct password before the count exceeds the maximum, the flag is re-set to zero (0). If an account enters the wrong password one time too many during a single session, the account is locked, as described in the passwd(4) man page.
The number of retries allowed applies only for multiple bad passwords entered in sequence in either of the following two occasions:
When logging into a host
When re-authenticating oneself in order to change a password or to assume a role.
If an account is ever locked by inadvertent error, the Security Administrator role can open the account by giving the user a new password using the Password tab in the User Accounts tool or by using the appropriate options with the smuser(1M) command line interface.
The Security Administrator role can change the RETRIES limit system-wide and can also change whether the limit applies to all users or individual users. Following are the actions that can be taken to change the default:
The Security Administrator role can change the maximum number of retries to be any number that is consistent with the site's security policy.
The procedure, "To Change the Allowed Number of Password Tries", describes how to set the RETRIES value in the local /etc/default/login file.
The Security Administrator role can specify that any individual user's account cannot be locked or can change the default system wide, so that account locking does not occur for anyone. Role accounts, since they do not log in directly, cannot be locked. The entries for individual users take precedence over system-wide entries, which in turn take precedence over the system default.
The procedure, "To Prevent Account Locking for Individuals", describes how to update a user's account with the User Accounts tool to prevent the account from being locked. The procedure, "To Prevent Account Locking for All User Accounts", describes how to set a system-wide password lock policy.