Warning: UNABLE TO PROCESS SMSESSION seen in Web Agent logs

Products

• CA Single Sign On Secure Proxy Server (SiteMinder)
• CA Single Sign On SOA Security Manager (SiteMinder)
• CA Single Sign-On
• SITEMINDER
• CA Single Sign On Agents (SiteMinder)

Issue/Introduction

The error messages are generally part of the normal operation of SiteMinder. They occur when a user's request presents a SMSESSION cookie that has expired through an Idle timeout.

Resolution

These are part of the normal operation of Web Agents, they occur when users present a SMSESSION cookie that is not current, usually because their sessions have expired.

As users access SiteMinder-protected resources, they are directed to log on and then get a SMSESSION cookie. However, after accessing the initial resource and performing the protected task, many users will then drift to other websites or perhaps leave their web browser active, but idle for some time.

When the user, after this period of "inactivity" then accesses the protected website, if they have not visited it within the time that exceeds the IDLE timeout of the SMSESSION cookie then the Web Agent will record the failed timestamp with the message "Warning: UNABLE TO PROCESS SMSESSION" and re-direct the user to the authentication scheme, usually the login page.

There will therefore be a number of these warnings seen in any Web Agent log and they are not a cause for alarm. In a webserver environment with many active users and a short realm timeout, the warning will occur more frequently.

Setting either a smaller or larger idle timeout for the protected realm will influence the number of occurrences of this warning. An analysis of the number of these warnings per hour will give a clue of how many users are getting caught and having to re-logon.

 

  NOTE:

  There are some other conditions under which the SMSESSION warning is
  given, and if you have a situation where users are unable to access
  the resource, and every request is received a "Warning: UNABLE TO
  PROCESS SMSESSION" then you need to look for other causes, such as a
  timing difference in the webservers or miscommunication between the
  webagent and the policy server about the correct session decryption
  keys.