Subject: Session expired/ Web access warning
JoakimI think some others have raised similar issues. See if the following helps.
Please check if the system time on the OS and servers are the same. Excerpts from technote 1159786
Problem
All users’ sessions are timed out when those users switch to a specific Lotus Domino server that participates in single sign-on (SSO), also called multi-server session authentication. This problem is seen on only a few servers in the domain.
This behavior can occur when the operating system time on the faulting server is earlier than the time on the server where the LTPA token was originally issued.
To resolve this issue, set the time on the faulting server to be the same or later than the time on the server where users log in.
Additional information
Starting with Domino 6.0.3 and Domino 6.5, a new feature was added that allows the cookie issued by SSO to have an idle session timeout. With an idle session timeout, the cookie is set to be valid between certain times. This validity window is updated each time a request is made to the server. A common configuration is to have one server where users login for Web mail or Domino Web Access. This server will be the first to issue the LTPA token; then the user is redirected to his or her specific mail server using either the Domino Web Access Redirect database (provided with Domino 6.03/6.5) or a homegrown method. If the mail server’s time is behind the time of the login server, then the token is considered expired when in fact it is actually not yet valid on the mail server.
Please also check your server settings for the fields mentioned in this document:
The Minimum Timeout field sets how long a session can sit idle before it times out. As noted above, this setting is a new feature for Domino 6.0.3 and 6.5 servers and higher only. For previous versions of Domino (both 6 and R5) the Idle Session Timeout functionality will not apply.
The value for the Minimum Timeout must be set no higher than the Expiration time specified in the Web SSO document because the Expiration time is the upper limit timeout for the overall session.
Below is the description of this new feature as listed in the 6.5 Release Notes:
Domino HTTP idle session timeout for SSO configurations
Domino HTTP supports SSO (Single Sign-On configuration for Domino HTTP multi-server session-based authentication). The SSO configuration now allows the administrator to configure an idle timeout, in addition to the SSO fixed expiration timeout. The idle timeout and the fixed expiration timeout both influence when an SSO user may be reprompted to enter in a password.
The use of the fixed expiration timeout remains the same. The user may be prompted for a password when first accessing an SSO HTTP server. Thereafter the user can access this server as well as other SSO servers in the configuration without being reprompted for a password. The fixed expiration timeout provides the maximum amount of time that an SSO user can continue to operate in the SSO environment without being prompted again for a password.
The SSO idle timeout additionally allows the administrator to control how long the user can remain idle after logging in, i.e. how long the user is not actively accessing the SSO environment. For example, a user’s SSO session may become idle when the user has stepped away from his desk for some period of time. The idle timeout can guard against the situation of users leaving an SSO session unattended. If the user does not access the SSO environment within the configured amount of time, the user’s session becomes idle and the user will be reprompted for the password the next time that the user accesses the SSO environment. This SSO idle timeout is similar in concept to the idle timeout that has long been available for Domino HTTP single session servers, however the SSO configuration honors both an idle timeout as well as the configured SSO fixed expiration.
An idle timeout is specified in minutes. Each Domino SSO HTTP server has the ability the check the configured idle timeout and reprompt the user for a password if the user’s session has been idle. As with any timeout or expiration enforced across multiple machines, there is potential for problems if the participating machines do not share the same notion of what time it is. A short idle timeout may be difficult to deploy and is not recommended if various machines in the SSO environment do not have their clocks synchronized.
The idle timeout should be considered as a minimum; sometimes it may take longer than the minimum for the idle timeout to occur. The idle timeout period is often effectively about twice the minimum. For example, if the administrator configures a minimum idle timeout of 5 minutes, sometimes the user’s idle timeout may occur after 5 minutes; other times it may actually take up to 10 minutes for the user’s session to timeout. Since various conditions determine when the idle timeout occurs, the idle timeout should be viewed as a range, with the earliest timeout occurring at the configured time while sometimes being delayed to about twice the configured time.
Because the idle timeout should be viewed as a range, the idle timeout will work best in general if it is one-half the amount of time (or less) than the configured fixed expiration. Suppose that the configured fixed expiration is 30 minutes. In this case, the idle timeout will be most effective if it is configured for 15 minutes or less (a greater idle timeout may result in the fixed expiration largely determining the behavior). For example, for a fixed expiration time of 30 minutes, it may be appropriate to set an idle timeout anywhere from 5 to 15 minutes.
To configure the idle timeout, two new settings have been added to the SSO configuration (underneath the Expiration minutes, which is what has been referred to here as “fixed” expiration).
Idle Session Timeout Enable
A checkbox allows the administrator to configure an idle timeout. This checkbox is unchecked by default.
Minimum Timeout (minutes)
If the idle session timeout is enabled, this setting specifies the number of minutes that a user can remain idle before the session may be considered expired due to being idle. This number must be greater than 0 and less than the fixed Expiration minutes.
The SSO idle timeout configuration potentially impacts all the participating Domino HTTP servers in the SSO environment. In order for the idle timeout to be honored by all Domino HTTP servers in the configuration, each Domino HTTP server must be upgraded to run this release. While it is possible to deploy an idle timeout in an SSO configuration that includes Domino machines running previous releases, the idle timeout behavior will not be consistent unless all machines are upgraded.
SSO configurations may apply to both Domino and WebSphere, however, the idle timeout configuration will be most useful and easiest for users to understand if all participating machines in the SSO environment are Domino machines. In a mixed Domino/WebSphere environment, users may experience an idle timeout on Domino servers, but will not encounter an idle timeout when accessing WebSphere. Since WebSphere only supports the notion of fixed expiration, an idle timeout can’t be supported with WebSphere SSO. Therefore, if the SSO configuration includes WebSphere, and if the user logs in first to WebSphere to obtain access to the SSO environment, then the idle timeout will not apply to the user’s session.
RM