Pulse Connect Secure 9.1R8.2 and its Host Checker are highly problematic
Here is the summary of the issue we encountered:
Realm has SAML as first Auth Server, and LDAP(S) as second Auth Server. Host Checker set to EVAL at the realm level. Host Checker restriction is enforced at the Role level ("Allow users whose workstations meet the requirements specified by these Host Checker policies"). User logs on to this realm via their web browser, and once authenticated successfully and passed HC policy, they will be mapped to TS role and HTML5 Remote Desktop role. GLOBAL Host Checker periodic reevaluation interval is set to 10 minutes. Host Checker timeout is set to 20 minutes.
Back when we ran Pulse Connect Secure 8.3R7.1, 9.0R4: When user logs on to the realm via a web browser (e.g. Chrome), browser will invoke PSAL and prompt the user to allow Host Checker to run the first time. HC runs and evaluates at the realm level. User is mapped to role (qualified at the role level) because they pass HC policy. When user gets to the main Pulse web portal, they're once again prompted to let Host Checker run. The second Host Checker process "dsHostChecker.exe" runs and promptly calls home every 10 minutes to report reevaluation results to the appliance (and indicated to the appliance which user was in compliance).
With Pulse Connect Secure 9.1R8.2: When user logs on to the realm via a web browser (e.g. Chrome), browser will invoke PSAL and prompt the user to allow Host Checker to run. HC runs the first time and evaluates at the realm level and User Log would show:
AUT22923 Host Checker policy 'SOME-HC-POLICY' passed on host xxx.xxx.xxx.xxx for user '[email protected]'
After that, even though the user had authenticated successfully, and qualified at the Role level, and is mapped to roles (because they passed HC policy), PCS 9.1R8.2 appliance never prompted the user to run Host Checker again the second time (unlike PCS 8.3R7.1 or PCS 9.0R4). Instead the first instance of "dsHostChecker.exe" continues to run in the background and called home but did not report WHICH USER was in compliance. In the User Log, it simply indicated at the first 10-minute mark (first reevaluation) that:
AUT22923 Host Checker policy 'SOME-HC-POLICY' passed on host xxx.xxx.xxx.xxx
Then at the 20-minute mark when the HC timeout interval is reached, even though the user had already logged in and had been using Pulse TS / HTML5 Remote Desktop for 20 minutes by this time, User Log would show:
AUT23447 Host Checker running on host xxx.xxx.xxx.xxx will exit as the user login timed out.
AUT22927 System process detected a Host Checker time out on host xxx.xxx.xxx.xxx for user '[email protected]'
then PCS 9.1R8.2 appliance immediately killed the user's VPN session, and the user got logged out and lost their TS / HTML5 Remote Desktop sessions.
---> We only upgraded to 9.1R8.2 because of Security Advisory SA44588 ( https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44588 ). We are very unhappy with this behavior exhibited by Pulse Connect Secure 9.1R8.2 and its Host Checker, which did not occur in previous releases. This has caused our user population plenty of grief. The only workaround to maintain production for our organization is either increasing Host Checker timeout interval to a very large interval or setting the periodic reevaluation interval to 0 (which means evaluate at the beginning of the session only).
This problem might be either related to or is a variant of PRS-390488 "Host checker is getting timed out (can be seen on user access log) and user is getting logged out" which Pulse Secure has never resolved.
I have a support ticket open on this and the devs are looking into it. It started for us on on 9.1R4
"Host checker is getting timed out (can be seen on user access log) and user is getting logged out"
Thats exacly what we are seeing. If you change your Hostchecker "Perform check every" time to 4 hours its helps, but you can also set it to 0 and it will not kick your users out. But for us that is not an option because we want it to check. Those users that have a max session length longer than the hostchecker checkin time will get the time out error. Those that have the same time as the hostchecker check in time will get max session timeout instead.
Curious, do you have any policies on the realm you are using set to only evaluate? If so uncheck it and see if it times you out when HC re-evaluates.
if that still times out, what do you have on your SSL conection configuration: Configuration > Security > SSL Options and see what is set under "Allowed SSL and TLS Version".