Nonetheless here some more information about our timeouts:
- When establishing a SSH/RDP Session to a Target Device, we log the following message in the PAM UI >> Sessions >> Logs:
- PAM-SPD-0012: CA PAM [<pid>] <account name> connected to <target server>; idle timeout <value>
- If we are the actual application timing out the connection, based off of our timeout settings, we will log the following message in the same session logs:
- PAM-SPFD-0015: CA PAM[<pid>]: Connection terminated; Duration (typically 1 second over the timeout value.
=============================================================================
However we do get a lot of support cases into support about login and applet timeouts. A lot to times there are numerous external factors that can be causing them:
- Load Balancers
- LB have idle timeout values associated with them (traditionally 5 minutes). Even though we haven't hit our timeout, the LB can be timing out the connection. Note: most clients have LB in front to PAM -> but also LB's can be also used to connect to devices.
- VPNs
- Just like LB's, VPN's do have timeout values as well.
- Windows and Unix systems can terminate the session before us:
- Unix -> /etc/ssh/ssh_config ConnectTimeout value - could have a potentially lower value than us.
- Windows -> Group Policies under \\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Session Timeout Limits - can also have lower values than us.
=============================================================================
Nonetheless, after going through all this. We can supply you with a PAM_TCP_DUMP patch that will take a network trace to see exactly where the disconnect is happening.