I've already notified Pulse Secure support folks.   I opened a case 00449355 today for something else.  I noticed that we did NOT receive via EMAIL any Case Comments which Pulse Secure support engineers put in the Case Center for that particular case, even though when the Pulse support engineer emailed us directly, we'd get it just fine.   Not only that, none of the email addresses we put in the CC list actually received any of those Case Comments either.   Something is seriously broken there. ... View more

When will Pulse Connect Secure 9.1R11.4 (to address SA44784) be available? ... View more

Certain discussions in previous threads weren't clear to me.   I have a bunch of users who connect over the web, authenticate via SAML then LDAPS, then use Pulse Terminal Services Client to RDP.   Let's say when my existing appliances running PCS 9.1R8.2 / PCS 9.1R10 are upgraded to the 9.1R11.x FIXED RELEASE (assuming it's released tonight),   when a user (who's already had the older PSAL / Pulse Setup Client / Pulse Terminal Services Client installed in their Windows profile "\AppData\Roaming\Pulse Secure" previously fetched from PCS 9.1R8.2 / PCS 9.1R10) connects to the newly upgraded appliance which will be running the 9.1R11.x FIXED RELEASE:   ---> will those existing Pulse components in the user's profile be automatically updated to a newer version of PSAL / Pulse Setup Client / Pulse Terminal Services which addressed this issue?   From what I see, Pulse Setup Client might be the component with the bad implementation which checked for code-signing cert expiration instead of checking whether the code signing time falls into the period for which the code-signing cert was valid. ... View more

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 'some.user@domain.com'   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 'some.user@domain.com'   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. ... View more

https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44503/   In Security Advisories 44503, Pulse Secure advised us all to upgrade previous Windows Client 9.1R5 and older (such as 5.3R7.1, 9.0R4, 9.1R3.1) to 9.1R7 to address client-side vulnerabilities.   My question:   Most of our appliances are running Pulse Connect Secure 8.3R7.1 (pending replacement with PCS 9.1R7 to be built).   Since PCS 8.3R7.1 use different/older PSAL, different/older Pulse Setup Client, different/older Pulse Installer Service, IF I upload the Pulse Desktop Client (PDC) 9.1R7 package "ps-pulse-9.1r7.0-b2525-package.pkg" to those PCS 8.3R7.1 appliances and set that PDC 9.1R7 to be the ACTIVE CLIENT PACKAGE, will it PROPERLY/CORRECT install / upgrade existing older versions of Pulse Desktop Client 5.3R7.1 and 9.0R4 and 9.1R3.1 on my endpoints properly when those older Pulse Desktop Clients connect to those appliances?   The reason is ask is because PCS 8.3R7.1 use different/older PSAL, different/older Pulse Setup Client, different/older Pulse Installer Service.   The Security Advisory said in Question 5, "Question 5: How do I deploy the patched Pulse Secure Desktop clients to my endpoints?     Answer: If you intend to deploy a patched Pulse Secure Desktop Client, upload the client bundle to your PCS or PPS gateway, configure it as the active version, and have your end users connect to the gateway. The Pulse Secure Desktop Client will auto-upgrade upon connection.", ---> but since PCS is 8.3 branch and PDC is 9.1 branch are different, I am uncertain whether that will work correctly.   Any advice would be greatly appreciated.  Thanks. ... View more

Pulse Connect Secure 9.0R4 virtual appliance Pulse Client 9.0R4 for Windows x64 SecureAuth MFA + AD LDAP   Back when our Pulse Connect Secure was running 8.3R7.1, whenever we connect to the appliance using Pulse Client 5.3R7.1 or Pulse Client 9.0R4, it would launch Internet Explorer for authentication to SecureAuth MFA, then afterwards run ActiveX to launch external Host Checker. It will pass the 1st Host Checker policy and will fail the 2nd Host Checker policy.  However, because Global HC is set to "Perform dynamic policy reevaluation" = DISABLED, and the Realm-Level HC is set to EVALUATE, and the Role-Level HC is set to ALLOW ALL USERS, it will successfully map to the Layer 3 VPN role and establish the L3 VPN connection just fine. That external Host Checker process "dsHostChecker.exe" will remain active for the duration of the L3 VPN session and called home every 10 minutes to check in.   Now that our Pulse Connect Secure appliance is upgraded to 9.0R4, whenever we connect to the appliance using Pulse Client 9.0R4, it would launch Pulse Client's built-in browser and apparently used "PulseSecureService.exe" Service for Host Checking. The logs on the appliance indicated that, just like before it passed the 1st Host Checker policy and will fail the 2nd Host Checker policy. However, because Global HC is set to "Perform dynamic policy reevaluation" = DISABLED, and the Realm-Level HC is set to EVALUATE, and the Role-Level HC is set to ALLOW ALL USERS, it will successfully map to the Layer 3 VPN role and establish the L3 VPN connection just like before.  ---> The problem is that AFTER 10 minutes (the defined interval for re-evaluation), the Pulse Client 9.0R4 for some reasons COULD NOT perform the periodic RE-EVALUATION at 10-minute interval, and it will immediately drop the L3 VPN connection.   This is causing major issue for us in migrating to 9.x (8.3Rx will reach end of support in October 2019) because we are required to have MFA in front and required to run Host Checker to determine who is allowed to have L3 VPN   Any thoughts as to why Pulse Client 9.0R4 with its built-in browser COULD NOT run Host Checker at periodic interval with our setup (MFA+LDAP)?  No matter what settings we have for Host Checker at Global Level, at Realm Level, or at Role Level, Host Checking just wouldn't run after 10 minutes, then the connection just dropped. ... View more

Is something wrong with the "download.pulsesecure.net"?   All our appliances have not been able to download the "epupdate_hist.xml" since last night   https://download.pulsesecure.net/software/av/uac/epupdate_hist.xml   When manually going to the above link and entered the download credentials, "download.pulsesecure.net" threw a "401" error. ... View more

Pulse Connect Secure 8.3R3, 8.3R6, etc.   Many of our users run the McAfee consumer endpoint protection product on their called "McAfee Total Protection" version 16.x various releases (R13, R15, etc.)   We were using ESAP 3.2.8 SDK v4.  Many of our users complained that Host Checker could not detect their McAfee Total Protection 16.x product (with the latest updates dated 10/11/2018) and Host Checker kept throwing error about their Windows 10 Windows Defender real-time protection isn't enabled. Error message is "Windows Defender 4.13.xxxxx.x" does not comply with policy. Compliance requires real time protection enable." (naturally it's disabled because McAfee is installed).  As a result, they're unable to establish  VPN connection.   Pulse Secure stated in the Release Notes for ESAP 3.3.1 that 3.3.1 supports McAfee Total Protection 16.x:   https://www.pulsesecure.net/download/techpubs/current/1404/pulse-connect-secure/esap/3.3.x/ps-esap-3.3.1-releasenotes.pdf   ---> Even after we uploaded and activated ESAP 3.3.1 and the Host Checker on the users' home machines were upgraded, Host Checker with ESAP 3.3.1 OPSWAT SDK v4 still couldn't detect McAfee Total Protection 16.x at all.   Anyone else encountering the issue?  This is most frustrating, as it resembled similar issue with Norton Security Suite 22.12.0.104 back in mid-March 2018. ... View more

Pulse Connect Secure 8.3R3 ESAP 3.2.8 SDKv4 Endpoints running Windows 10 Enterprise x64 version 1709 with all security updates up to July 2018   When using McAfee ENS 10.5.3, Host Checker (ESAP 3.2.8 SDKv4) detected everything correctly.   When using McAfee 10.6.0.542, Host Checker (ESAP 3.2.8 SDKv4) continued throwing error that "Compliance requires latest virus definitions", even though the endpoints had the latest virus defs.   According to Pulse Secure documentation here:   According to Pulse documentation,  ESAP 3.2.8 SDKv4 supports McAfee Endpoint Security 10.x, but apparently it does NOT work with McAfee ENS 10.6.x     Has anybody else run into this issue?     ... View more

Pulse Connect Secure 8.3R3 ESAP 3.2.5 ---> ESAP 3.2.6, OPSWAT SDK v4   McAfee Endpoint Security 10.5.3 real time protection on Windows  was detected correctly with ESAP 3.2.5   After upgrading ESAP to 3.2.6, Host Checker fails to detect real time protection for McAfee Endpoint Security 10.5.3 on Windows (never tried Mac)   In User Access Log, kept throwing error "reason 'Rule-AV:McAfee Endpoint Security 10.5.3 does not comply with policy. Compliance requires real time protection enabled."   After rolling back to 3.2.5, detection of  real time protection for McAfee Endpoint Security 10.5.3 on Windows  worked correctly again.   Does anybody here experience the same issue?   We're aware of a similar issue in the recent past (as described in KB43668) when Host Checker also failed to detect real time protection on Windows for Symantec Endpoint Protection 14.0.3x ... View more