Looking for some suggestions for how others are using Timeout Policies. We have experimented with several options from hours to days but have yet to find an option that meets all our needs. One complaint we sometimes get is that Timeout occurs while the user is in the middle performing some function in an application and they potentially lose some progress. Or worse someone from a customer support team is on call with a customer and temporarily loses access to an application needed to support the customer. With our previous VPN application this was never an issue as it needed to be manually launched and authenticated to. So users would launch the VPN app at the beginning of their shift and authenticate, and then they would be good for the rest if their work day. It would be ideal if we could somehow refresh the timeout period when the user starts their shift.
guess this depends on your exact security policy
but a general easy way to handle ‘timeout happens in the middle of my work’ is probably to go for a longer timeframe
i wouldn’t go much shorter than 12h (so a full working day of employee is covered) and not much longer than 7 days
Good question Joe !
I’m curious on other responses here.
We are currently using the 7 day timeout for general domain resources but Financial App Segment might be configured for 12 hours in the near future.
I haven’t tested the option in mobile portal ‘Automatically Attempt ZPA Reauthentication’, has anyone here ?
i have it set but ZPA still ends up on ‘auth required’ state and i need to click on that; just can’t remember if this always happens after timeout or only every n’th time
We have automatic reauth enabled, but since we also require MFA the user still has to interact with the client. In our case it basically just prevents the user from having to click the Authenticate button in the ZCC. Depending on how your MFA works, it may also result in users getting unexpected MFA requests on their phone. We use DUO MFA, and when the ZPA timeout occurs (even if the user is not at their machine) it will send a push to their phone.
It would be good if we could force a re-auth at “next reboot” or “next login” after the re-auth timer has expired.
This would stop someone’s access being interrupted in the middle of the day and causing them problems.
Funky idea Gordon, now you’ve got me thinking of a new Enhancement Request
I’ll honestly be happy with a ZCC 10 minute advance warning of session timeout with the ability of ‘one-time’ to snooze for x minutes (configurable in App Profile like ZIA re-enable security).
This could address Joe’s requirements but also help with ours.
I like this idea as well.
the biggest issue in that regards is the fact that this ‘auth required’ info can very easily be overseen.
In worst case it is only a small red dot in the tasktray (and the user decided to not show that icon)
→ in result user annoyed, one more unnessary ticket.
Some optional setting like ‘if auth timeout reached - popup ZCC in front and demand reauth … without breaking any existing connection for a configurable grace time.’
That would make the issue ‘undeniably visible’ to even the most ignorant user and give him some time to react before ZCC ‘cuts the wire’ so to say.
I think the timeout warning is a great idea. Ideally the timeframe would be configurable. Something like “Your Zscaler session will expire in X minutes, click “Re-Authenticate” now to avoid service interruption.” And have the “Re-Authenticate” button right in the popup warning.
Please back ER-12149 if it meets your requirements
Thank you to this thread for the inspiration
User’s ZPA session is about to timeout for Re-authentication during important customer interaction which requires information to be entered in a database using ZPA. Timeout causes temporary loss of connection while entering crucial data.
ZPA user receives a ZCC notification popup 10 minutes prior to ZPA timeout with the ability to perform a ‘one-time’ snooze option for x amount of minutes. The x amount of minutes can be configured in the App Profile like the “Reactivate Internet Security After (In Mins)”
This enhancement request will avoid user impact during critical time window without losing ZPA connection.
i’d probably rephrase the ER a bit
“ZPA user receives a ZCC notification popup”
“ZCC should be brought in front of all other windows showing a warning that ZPA access is about to expire”
Nothifications/popups can easily be overseen (think ‘afk because of biological needs’); only if ZCC is in front waiting on the user to action it is obvious enough.
Then the user can either quickly click ‘get out of my way for the next 10 min’ or reauth right there.
Valid point and happy to amend.
We are planning to use the new “Notification Framework” once we move to ZCC 3.8 for that reason.
I find the notifications much clearer without Win 10 interfering.
using that as well already (recently started with global 22.214.171.124 rollout)
But the notifications are not ‘sticky on top’ nor do they force the user to react.
Combine that with ‘hidden tasktray icon’ and the result is a SD ticket for ‘ZPA kicked me out yaddayadda’…
Since it was not obvious to me when we first setup our timeout policy, the timeout setting is per application. So if you have some app segments you don’t want to timeout (SCCM & NTP for example), you can allow that to continue communicating even when ZCC shows reauthentication is needed.
@joe.van has a good point which I’ve missed !
I guess the correct Zscaler approach will be to exclude this ‘critical’ or time sensitive App Segment/Segment group to ‘Never timeout’ . I’m guessing the ER might be ignored then