Environment
NetIQ Access Manager 4.3
Situation
- New installed NetIQ Access Manager 4.3 has been configured to protect a GroupWise Webaccess server
- The connection between the Access Gateway proxy and the GroupWise Webaccess server has been configured to protect traffic by making use of SSL
- Idle clients get logged out after about 5 minutes.
- Session timeout has been configured for 60 minutes and therefore does not match the 5 minutes logout symptom
Resolution
- as a workaround disable Session Assurance (turned on in case a complete new NAM 4.3 has been setup)
Cause
The GroupWise Webaccess server drops the SSL session with the proxy. The root cause seems to be a problem with the SSL session maintenance and SSL Session Ticket usage.
During a complete new SSL session establishment (full SSL Handshake / No SSL Session ID in SSL Client Hello) created by the proxy the GroupWise Webaccess server sends a "New Session Ticket" SSL message. This is usually only used if the SSL client (proxy) likes to re-use an existing cached SSL session which allows a faster handshake. In this Scenario the client (proxy) sends the old SSL Session ID in the client Hello. Looking at a LAN trace shows that this is not the case.
Due to this situation the connections drops and the proxy server returns a HTTP 502 Bag Gateway error message. The idle GroupWise client runs a polling process checking for any changes. This process is not able to handle the 502 Bad Gateway error message and continues polling the GroupWise Webaccess server in a regular basis. In this situation the Session Assurance Fingerprint will require a new Session Assurance Fingerprint (default every 5 minutes). Re-using the old fingerprint will cause a logout which a given user will only notice in case of any action with the GroupWise WebAccess client
During a complete new SSL session establishment (full SSL Handshake / No SSL Session ID in SSL Client Hello) created by the proxy the GroupWise Webaccess server sends a "New Session Ticket" SSL message. This is usually only used if the SSL client (proxy) likes to re-use an existing cached SSL session which allows a faster handshake. In this Scenario the client (proxy) sends the old SSL Session ID in the client Hello. Looking at a LAN trace shows that this is not the case.
Due to this situation the connections drops and the proxy server returns a HTTP 502 Bag Gateway error message. The idle GroupWise client runs a polling process checking for any changes. This process is not able to handle the 502 Bad Gateway error message and continues polling the GroupWise Webaccess server in a regular basis. In this situation the Session Assurance Fingerprint will require a new Session Assurance Fingerprint (default every 5 minutes). Re-using the old fingerprint will cause a logout which a given user will only notice in case of any action with the GroupWise WebAccess client