Managing Invalid Login Handling
When you specify a preauthentication level of 2 (PADATA-ENC-THIRD-PARTY) for a principal, the security server is able to detect and track invalid login attempts for that principal. This makes it possible for administrators to limit the possible impact of password guessing attacks by
· Setting a limit to the number of successive invalid login attempts before the principal's account is disabled. (A successful login resets the counter.)
· Specifying the period of time the principal's account will be disabled once that limit is reached.
You do this by attaching instances of two ERAs (max_invalid_attempts and disable_time_interval) to the principal. Specify values for these ERAs as follows:
max_invalid_attempts
Specifies an integer indicating the number of successive invalid login attempts the security server should accept before marking the principal's account as
disabled.
disable_time_interval
Specifies an integer indicating the number of minutes the principal's account should be disabled from login attempts.
The following is an example of a dcecp command to create a principal and attach max_invalid_attempts and disable_time_interval ERAs:
dcecp> principal create smitty -attribute {{max_invalid_attempts 7} \
{disable_time_interval 60}}
Note: At DCE Version 1.1, the invalid login handling functionality accurately tracks login activity in a cell with one master and no replicas, but does not keep accurate counts in replicated cells. This is because
· Login attempts in a replicated cell are randomly assigned to either a master or replica.
· There is at present no mechanism for replicas to communicate to the master and, therefore, no way for the master to maintain an accurate count.
For further information on how to use dcecp to attach ERAs to principals, see Creating and Using Extended Registry Attributes.