These settings are used during the Authentication process to determine if the user can log in or if APS must force the user to do or see something.
Range: Yes or NoReset Password
Default: No
Recommended: No
Complexity Level: Basic
SiteMinder may not be the only application that uses an LDAP directory for authentication. APS can obfuscate the user's password when it disables an LDAP user account. This prevents a disabled LDAP user account from using any application, not just SiteMinder protected ones. This means that when the account is to be enabled, not only must he be removed from the disabled group, but the password must be reset as well.
This also means that the administrator who resets the user's account will know the password after it is reset, however. By removing this setting, the administrator needs only to enable the account to allow authentication; the password will remain intact. Note that the administrator cannot tell the user what the password was, so it is assumed that the user really does know his original password.
The default is do not reset passwords.
Prior to APS Version 3.0, there were implications to turning off this setting. These implications no longer exist.
This setting applies to LDAP directories only.
Reset Password
Range: Yes or No
Default: No
Recommended: Yes
Complexity Level: Intermediate
Starting with Version 3.0, APS can detect if an LDAP (or ODBC at Version 4.0) user's password was changed using an interface other than an APS interface. If this setting is enabled, then if the password has been changed externally, the user will be required to change their password upon their next login.
This is useful for Help Desk applications. For Administrator Password Reset, they need only change the user's password. Once done, and this setting is enabled, the user will automatically be forced to change their password.
To enable this capability for accounts stored in an ODBC directory, the query Set Password Checksum and the query Test Password Checksum must be defined and implemented.
For LDAP implementations, this functionality requires that the underlying LDAP server allow APS to read back the user password attribute in a consistent manner (usually hashed or encrypted). For iPlanet LDAP Directories, this can only be done if the administrator is cn=Directory Manager. For some LDAP implementations, most notably Microsoft Active Directory, there is no way to read this information.
Auto Force Change
Range: Yes or No
Default: No
Recommended: Yes
Complexity Level: Basic
When a user successfully authenticates and this setting is enabled, any FPS Lockout Counter will be reset to zero.
Reset FPS Lockout
Range: 0 or 3-9
Default: 0
Recommended: 5 or 9
Complexity Level: Basic
Password cracking programs attempt to log into accounts by trying various combinations of passwords until one works. A counter to this kind of attack is to disable a user account after a specific number of invalid passwords have been entered consecutively.
This setting tells APS how many consecutive failed passwords must be supplied before an account is disabled.
APS keeps this counter in memory and stores it in a user's LDAP or ODBC entry (Windows users are kept in memory only). The value stored for a user contains a date/time (in GMT) in addition to the actual number of failures. Whenever APS needs the count for a user, it examines the in-memory counter and any value read from disk and uses the one tagged with the latest date/time. This is so that APS can continue to support Max Failures lockout even if a primary LDAP server is unavailable. Note that user accounts cannot be disabled in this case, but will be locked out in memory anyway.
Each server also keeps a date/time stamp on each counter in memory. If there has been no activity for a particular user after a specified time, the counter is cleared. This timeout value is configurable.
This setting should not be confused with the retry count supported by SiteMinder's Form Login capability or with the retry count supported by most browsers. Those retry counts control how many attempts can be made in a single session before the user must either shut down the browser or reselect the URL. This has no impact on the user's entry in the directory. Password cracking programs understand this capability and can shut down, then restart, browsers as required.
The Failure Count setting should usually be higher than any retry count (the Form Login retry count is configurable; most browsers use a value of 3 and cannot be changed). This allows a user a chance to realize that they have forgotten their password before being locked out by APS. Only a determined user (or a password cracker) would continue to make attempts and thus cause the user record to become disabled.
Further discussion of this issue is described in the section entitled Special Case: Three Strikes, You're Out.
The Max Failures setting must be used with great care when using complex LDAP or multiple directories. To understand why, you must understand how SiteMinder locates users in its directories:
SiteMinder usually receives an unqualified user ID. It does not know which directory the user is stored in, nor where, for hierarchical (LDAP) directories, the user exists within the directory. For example, a site might have three different users called JSMITH, one in the NT domain, and two in LDAP as uid=JSMITH,ou=employees,o=Airius.com and uid=JSMITH,ou=customers,o=Airius.com. SiteMinder only receives the id JSMITH and a password.
SiteMinder searches through its directories looking for a match to the supplied user id. When a match is found, the server attempts to log into (bind to) that account using the supplied password. If the password matches, then it has found the correct user, otherwise it continues its search to the next match on the user id.
If no userid is found with the supplied password, the authentication request is denied.
Now consider how APS works. Each time that a user entry is found, SiteMinder notifies APS and tells it whether the entry was authenticated or not. If authenticated, APS resets any counter associated with the name and checks for to see if the account is disabled, etc.
However, if the authentication for this entry has failed, APS increments the failure count for the entry. If the count exceeds this setting, the user account is disabled and the specified actions (mail, redirection) take place.
This can cause real problems when multiple accounts exist with the same id. In our above example, each time that JSMITH logs in, if it is the third JSMITH found, then the first two will each have their counts incremented and, possibly, be inadvertently disabled.
Consider also the case where one of the JSMITHs has forgotten her password. After three attempts, all three JSMITH accounts will be disabled. This is probably not what an administrator wants, but is the action that APS must take. A cracker program in this case is more likely to succeed, since there are three passwords that might work instead of just one. Also consider that APS does not know which instance of that user actually forgot their password.
Keep these issues in mind when using this setting. If duplicate user ids are possible in your directories, it might not be a good idea to use this setting or it might be a good idea to set this to a higher value.
See also How Do I: Configure "3 Strikes and You're Out"?.
Max Failures=5
Range: 0 or 3-9
Default: 0
Recommended: 3
Complexity Level: Basic
This setting controls how many unsuccessful attempts to change the password are allowed (unsuccessful because the old password is not correct). If this setting is not specified, the Max Failures setting above will be used.
Note that these two settings use the same counter, but set different thresholds for failure.
Max Failures on Change=5
Range: 0 or 5-30 minutes
Default: 0
Recommended: 5
Complexity Level: Intermediate
If an account is disabled because of a failure count, this setting determines how long the user account will be disabled (if Auto Reset Failure Count, below, is enabled). If the user does not attempt to login for this amount of time, the user will be allowed to login. If the user is disabled (Auto Reset is off), he remains disabled. If not set and Auto Reset Failure Count is enabled, this value will be internally set to 5 minutes. This setting is in minutes. This value will be ignored if it is less than 5 minutes.
This setting must be larger than the Failure Count Retention setting below. This number should be set higher than 30 minutes only with great care.
If a user attempts to login within the period, regardless of success or failure, the time period will restart. Thus, it is impossible for a programmatic password cracker to break a password, even if this setting is as low as 5, since 5 minutes must pass between attempts (to test one million passwords would take approximately 9.5 years.
Failure Count Timeout=10
Range: Yes or No
Default: No
Recommended: Yes
Complexity Level: Basic
If this setting is specified, users will not be permanently disabled when they reach the failure count (Max Failures), but will not be allowed to login until the timeout (specified by Failure Count Timeout above) occurs. Any attempt to login (good password or bad) will reset the timer. This feature is off by default. If the keyword appears, then the feature is turned on.
Auto Reset Failure Count
Range: 0 or 5-30 minutes
Default: 0
Recommended: 5
Complexity Level: Advanced
APS keeps track of the failure count for each user both in memory and on disk (for ODBC and LDAP users). This setting tells APS how long to remember these counts. This is different than the Failure Count Timeout setting (above) that controls how long an account will be disabled before automatically re-enabling it.
If no failed attempts occur within this period, APS will reset the counter to zero.
This setting must be lower than (or equal to) the Failure Count Timeout setting above. This number should be set higher than 30 minutes only with great care.
If a user fails a login attempt within the period the time period will restart. Thus, it is impossible for a programmatic password cracker to break a password, even if this setting is as low as 5, since 5 minutes must pass between attempts (to test one million passwords would take approximately 9.5 years.
If this setting is less than 5 or not set, APS will use 5 minutes.
Failure Count Retention=10
|
Copyright © 2014 CA.
All rights reserved.
|
|