Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 16830 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Web Protection Authentication Timeout

ntoupin
I'm currently using AD SSO backend sync (Web protection/filter in transparent mode).  I have clients of our devices (Windows, Mac, Android) as well as many guest devices (iPhones, iPads, etc.).

Due to this I set the authentication timeout to be 8 hours so users would basically authenticate once a day on their devices (if they aren't on our device the UTM is popping up with a sign-in pop up or window in their browser just as it should).

The issue I'm currently having is we have Chromebooks internally, these cannot pickup the AD SSO like our windows machines, however the "browser" authentication mode works great for them (Device-specific authentication -> Linux).  

The only issue with this is that the chromebook users, since they are being prompt via the browser login, are basically logging in once per device per day -- even if the chromebook user changes: User A is the first user to use chromebook 1 today, they get the prompt and authenticate. User B goes to use chromebook and isn't prompt due to the session still being within the 8-hour window according the firewall and therefore is authenticated as if they were user A.


So ultimately my questions are:
- It doesn't look like there is any way to specific a authentication session timeout per filter policy, profile, or device type - is this true?
- Due to the above would my only option be to set all authentication timeouts to be X amount of time so the chromebooks would need to authenticate per user due to session time? 
- Has anyone else encountered this or something similar and found a good resolution?


This thread was automatically locked due to age.
Parents
  • 0
    When you log in via Browser auth it should pop up a new tab (sometimes blocked by your pop up blocker).

    The (screwy but we cant change it because some customers rely on it) logic is:
    - While the pop-up is open the user is logged in
    - After the pop-up is closed they have until auth timeout while still considered logged on

    Then what you do is make sure that pop-ups are always allowed, set your timeout to two minutes.

    Chromebook user logs in, popup appears in new tab.  As long as they keep that tab open they are fine.  When the user logs off the tab is closed and the UTM now thinks no user it logged in.  Next person comes in and starts again.  If anyone ever closes the tab they'll find themselves logged out after 2 minutes (negative reinforcement will teach them not to).

    This is assuming that Chromebook doesn't do some screwy multi-user thing and keep users running even in background.
  • 0 in reply to Michael Dunn
    When you log in via Browser auth it should pop up a new tab (sometimes blocked by your pop up blocker).

    The (screwy but we cant change it because some customers rely on it) logic is:
    - While the pop-up is open the user is logged in
    - After the pop-up is closed they have until auth timeout while still considered logged on

    Then what you do is make sure that pop-ups are always allowed, set your timeout to two minutes.

    Chromebook user logs in, popup appears in new tab.  As long as they keep that tab open they are fine.  When the user logs off the tab is closed and the UTM now thinks no user it logged in.  Next person comes in and starts again.  If anyone ever closes the tab they'll find themselves logged out after 2 minutes (negative reinforcement will teach them not to).

    This is assuming that Chromebook doesn't do some screwy multi-user thing and keep users running even in background.


    If we could have a separate timeout for specific profiles then I could do that.  Unfortunately with only one setting I cannot as setting the timeout to 2 minutes would cause all mobile users (phones, tablets, etc.) to authenticate very frequently and be difficult for our users to use.
Reply
  • 0 in reply to Michael Dunn
    When you log in via Browser auth it should pop up a new tab (sometimes blocked by your pop up blocker).

    The (screwy but we cant change it because some customers rely on it) logic is:
    - While the pop-up is open the user is logged in
    - After the pop-up is closed they have until auth timeout while still considered logged on

    Then what you do is make sure that pop-ups are always allowed, set your timeout to two minutes.

    Chromebook user logs in, popup appears in new tab.  As long as they keep that tab open they are fine.  When the user logs off the tab is closed and the UTM now thinks no user it logged in.  Next person comes in and starts again.  If anyone ever closes the tab they'll find themselves logged out after 2 minutes (negative reinforcement will teach them not to).

    This is assuming that Chromebook doesn't do some screwy multi-user thing and keep users running even in background.


    If we could have a separate timeout for specific profiles then I could do that.  Unfortunately with only one setting I cannot as setting the timeout to 2 minutes would cause all mobile users (phones, tablets, etc.) to authenticate very frequently and be difficult for our users to use.
Children
No Data
Unfiltered HTML