Advanced Password Services (APS) Guide › Administration and Operations

Administration and Operations

This section contains the following topics:

Introduction

APS Processing during User Authentication

Password Lifetime

Backup Policy Servers

Special Case: Three Strikes, You're Out

SiteMinder's [Basic] Password Services

Using Persistent Cookies

Authorization Mapping and AZRedirect

FPS Process Flow

Introduction

Advanced Password Services (APS) runs in conjunction with the SiteMinder Policy Server. After SiteMinder has attempted each authentication of a user against a directory, APS is consulted to verify the authentication. Each login attempt, successful or failed, is presented to APS behind the scenes and APS is asked to verify that the user is valid and not disabled. Advanced Password Services checks its own records of that user's activity, including the number of failed login attempts that user has accumulated and the length of time since the user last successfully authenticated. APS then checks whether the user has been disabled, finally updates its records and either allows an authenticated user access, or halts a successful authentication, rejecting the login and (possibly) disabling the user's account.

Advanced Password Services also allows users to change their own passwords through the Change Password Interface, which can be customized for your organization, or the API, which can be called by your own or third party tools. Users must be configured through the SiteMinder Policy Server to have access to the Change Password Interface, but in most circumstances, this will not require periodic maintenance.

Password content policies apply only to passwords changed through the Change Password Interface and the API. They are not applied to existing passwords nor password changes made using other interfaces (such as Windows NT or iPlanet's Directory Server).

APS includes Forgotten Password Services (FPS), which can allow users to interactively recover forgotten passwords or user ids in as secure a manner as possible.

There is also a Help Desk interface (not shown in diagram above) called APSAdmin, which allows sites to quickly set up simple user account enable/disable/password reset operations.

APS Processing during User Authentication

The following graphic shows the processing that occurs when SiteMinder calls APS during User Authentication. SiteMinder passes the result of its authentication to APS (success or failure). It shows what APS does if SiteMinder has already rejected the login (almost always because the user's password is bad):

The process description continues in the following graphic to explain what APS processing occurs when SiteMinder has indicated a successful authentication (at least until the APS invocation):

The following graphic shows how APS checks whether a user is disabled. Since SiteMinder does not "know" about APS disabling, it has already approved the authentication. If the user has already been approved by SiteMinder, APS must check the disabled status first:

If the user passes all of these tests, then conditions like user inactivity and password expiration must be checked, as shown in the following graphic:

Password Lifetime

The following graphic demonstrates how certain APS settings affect the lifetime of a password.

There are three settings which affect password lifetime.

• Password Expiration controls the maximum amount of time that can pass between password changes (or since the user account was created).

  If Password Expiration is not set (or zero), the user's password has an infinite lifetime (never expires).

  Password Expiration can be overridden at the user level using the smapsExpirePasswordDays attribute in an LDAP entry.

• Expiration Warning controls how long before actual expiration we start to warn the user that their password will expire.

  If Expiration Warning is zero or not set, no password warnings will be issued.

• Expiration Grace controls the amount of time after the password has actually expired that we will allow the user to still login, though the user will have to change their password before accessing the system.

  Once the Expiration Grace period has expired without a password change, the user will be disabled when they login.

  If Expiration Grace is not set or zero, the user account will be disabled immediately upon password expiration (subject to the Grace Logins setting, as described below).

A fourth setting, Grace Logins, can also affect this process.

The following tables describe what happens at each of the "Login Points" shown in the diagram.

Note that APS may redirect the user or take other actions that have nothing or little to do with password lifetimes (i.e. Force Password Change, User Expiration). These actions are not reflected in the tables below.

Also, if a particular redirect is undefined, APS will not perform the redirect and may ignore the lifetime setting (e.g. if there is no Expire Change Redirect, then APS will ignore the Expiration Grace period).

Backup Policy Servers

Advanced Password Services will operate simultaneously on any number of Web Servers using a single set of SiteMinder Policy Servers. In case of a failure of the SiteMinder server, APS can switch over to secondary servers in the same way that a Web Agent will. Primary and backup Policy Servers are configured using the SmPortal.cfg file (see the SmPortal/SmTransact Administration Guide). They can be configured either in failover or in round-robin mode.

Each SiteMinder Policy Server must have Advanced Password Services installed. Each such server is configured separately and independently. It is important that the configuration of all such machines be identical, though APS does not enforce this. There are some cases where they should differ between machines, but this always involves specific performance tuning when the Policy Servers are geographically dispersed.

See the description of the Max Failures setting for details about how multiple Policy Serves impact that functionality.

Special Case: Three Strikes, You're Out

SiteMinder, with APS installed, supports two different "Three Strikes, You're Out" options. These options are basically unrelated and can be used together, if care is taken with the configuration. It is fairly typical for a site to confuse users (or themselves) by improperly configuring the two options.

APS keeps a failure count on a per user basis. This failure count is kept in memory and written to disk (for LDAP users). The information is kept both on disk and in memory for LDAP users, so that the feature will still work even if the Primary LDAP server is unavailable. APS will use the setting in memory or the setting on disk, whichever has a later date/time. Each failure count is maintained with a timer (controlled by the Failure Count Timeout setting). If no attempts are made for this amount of time, the failure count is discarded. The count includes all attempts, regardless of which browser supplied the authentication credentials, but only those that apply to the specific user.

Most implementations of HTML form-based login keep a retry count. In the form login mechanisms supplied with SiteMinder, this count is kept in a transient cookie called RETRYNO, SMRETRYNO, TRYNO or SMTRYNO. This count is kept for the duration of the browser session. It includes all failures, regardless of the user id entered. Usually, when this value hits a threshold, further attempts are prevented and an error message (or page) is displayed.

Please note that Basic Authentication (where the browser presents a dialog box for authentication) works the same way, but the count is not configurable; it is always three. In this case, it is consecutive retries, but, like above, it is independent of the user id entered.

The counters kept at the browser level should only be considered "speed bumps". A savvy user knows that he need only stop, and then restart the browser and further attempts can be made.

The APS tracking will, eventually, lock down (disable) the user. Regardless of what the user does, the account is no longer available.

Some sites will use one capability or the other. For the most security, with the minimum user distress, both should be used with care, as described below:

The "speed bump" (browser-side) options should be set to a value of three (note that Basic Authentication is not configurable). The APS Max Failures setting should be set to 5.

At the end of three attempts, send the user to an error page that reads something like "You've apparently forgotten your user id or password. Please call our Help Desk for assistance." or refer the user to your Forgotten Password Support page.

A normal user will typically do exactly what is asked; they will call the help desk for assistance. The account is not disabled, since the APS count will only be 3.

If, however, the user is intent on breaking into the site, they will stop the browser, then restart it and continue to attempt a break-in. After two more attempts, APS will intercede and the account will be disabled. Further attempts will be denied. This will only happen in two cases:

• The user shut down the browser and explicitly continued to make attempts.
• The user is accessing through multiple browsers.

In either case, it is a real attempt at intrusion, not just a mistaken user.

APS should not be configured to redirect the user in this case (nor in the disabled case). Instead, an email should be sent to an internal security administrator, possibly through a pager gateway, telling the administrator that an intrusion attempt is in progress. If possible, email should be sent to the owner of the user id as well, describing that the account is disabled and why.

The "speed bump" will continue to operate, so the hacker will never know that the account has been disabled.

SiteMinder's [Basic] Password Services

Starting with Version 4.1, SiteMinder included Password Services (often referred to as Basic Password Services). The functionality included is essentially a subset (with a few extensions) of the Advanced Password Services Version 1.1 functionality.

In the process, CA modified SiteMinder so that Password Services can be enabled or disabled on a per-authentication scheme basis. This is done using a checkbox on the authentication scheme setup pages in the Policy Management interface. If this flag is turned off for a given authentication scheme, neither Password Services nor Advanced Password Services will be invoked. It is critical for Advanced Password Services operation that this flag be turned on for all authentication schemes (there are probably reasons that it might be turned off in special cases, but we haven't seen any yet).

Password Services and Advanced Password Services, as of this writing, are not compatible. You can use only one or the other, not both. In fact, at this time, there is no way to convert from one to the other (though such conversion could be written; contact CA Professional Services if this is required).

Because of this, when APS is used, all Password Services settings (except the authentication scheme setting above) must be disabled. If not, unpredictable results may occur.

Using Persistent Cookies

SiteMinder Web Agents can be configured to use persistent cookies. When this option is turned on, the user authenticates once from a particular machine/browser and a permanent record of that authentication is stored in a cookie. Whenever the user accesses the site from the same machine/browser, the user is not authenticated again (though the user is re-validated to ensure that the cookie is still valid).

APS is not involved in the validation process, only in the authentication process. If persistent cookies are to be used, the following functionality of APS will not work properly, since the user's last login date will not be recorded (last login implies authentication). None of these options can be used with persistent cookies.

Account Expiration

Since users don't authenticate, there is no last login date upon which to base the calculation.

Account Inactivity Warning

Since users don't authenticate, there is no last login date upon which to base the calculation.

Password Expiration Warnings

The detection of this situation occurs during the authentication process, which is not invoked.

True password expiration

The detection of this situation occurs during the authentication process, which is not invoked. Users will not be disabled at the end of their grace period.

APS is not invoked during user validation (which occurs when a persistent cookie is presented), only during authentication. Thus, the above functionality is not operable.

However, Force Change Password and Expired Password (as during the grace period) can still be handled using the AZRedirect capability, since AZRedirect is invoked in all cases. If the site does not use AZRedirect, then APS functionality will only occur during the initial authentication (when the persistent cookie is created) and will never be invoked again.

Of course, voluntary password changes will work correctly, since it does not involve the authentication process.

Authorization Mapping and AZRedirect

Some strange things can happen when using Authorization (AZ) mapping and AZRedirect in the same Policy Domain. The problem arises because the authenticating user is checked during the authentication process, but the authorizing user is used during AZRedirect. The problem occurs when the two users are not the same.

APS checks the Force Password Change flag, Generational Redirects, and several other user settings both at authentication time and during AZRedirect. If the two users are not the same, APS will not be looking at the same set of flags.

In addition, the change password process needs to update the authenticating user rather than the authorizing user. Thus, you should never perform AZ mapping within the change password domain. This also means that the Immediate Password Change setting will only be reset in the authenticating user.

FPS Process Flow

The Forgotten Password Services (FPS) component of APS is essentially a finite state machine (FSM). An FSM is a standard computer software construct that make decisions based on a finite number of states and the transition conditions between these states.

FPS defines the following states:

Only states ending in zero are external states. That is, ones that will exist whenever FPS is invoked. FPS can then convert to an internal state, resulting in a redirection that is, for all intents and purposes, equal to another external state.

The state transitions are defined as:

Whenever Forgot (Forgot.exe on Windows NT) is executed, it communicates with the SmAPS library on the SiteMinder server. All logic is actually contained in the SmAPS library; Forgot is merely a communications stub. Basically, the only logic in Forgot is for handling communications errors.

FPS first determines the initial state. This will always be one of the external states (number ending in zero). This is done using the referrer (the page that sent the user to Forgot) and cookies.

Once the initial state is determined, FPS can determine what the expected POST data is supposed to be (if any), validate it, and determine the next state. It can then determine the next place that the user is to be redirected and whatever setup is required for that page.

If debugging is turned on (using the DEBUG statement in the SmPortal.cfg file and the DEBUG setting in the FPS configuration file), state changes are recorded in the log. Problems can often be diagnosed using this information.