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

Issue with transparent filtering, AD SSO. timeouts not functioning

Running on an SG135, 9.355-1.

All I want is the ability to bypass exe blocking for specific users, without logging into the UTM interface. I've attempted to do this with the minimum interruption to service by  using AD SSO with a separate filter profile for bypass users. If there is a more straightforward way, I'd love to hear it.

According to https://www.sophos.com/en-us/support/knowledgebase/120666.aspx credentials are re-authenticated every 5 minutes. In my testing, this does not seem to be the case - it can take anywhere from 15-45 minutes after logging out as one user and logging in as a new user before the re-authentication occurs. This is not suitable and unpredictable, and would lead to great frustration when attempting to download a file.

After contacting premium support, I was first of all told credentials were not cached at all, then told that yes they were cached, then told to reinstall the firmware on the SG135!!!

Anyone know if the re-authentication time is adjustable in some way, or weather this is a bug, or there is a more straightforward way to achieve what I want to achieve.

Thanks.



This thread was automatically locked due to age.
  • Authentication caching is confusing.  :)


    Part of the problem is that in transparent mode, AD SSO cannot be done a variety of types of requests.  The UTM cannot silently do authentication for HTTPS requests or for any url that has a ?parameter.  Therefore the UTM will continue to use the now-expired authentication until the next time it sees a request that it can authenticate silently.  Although that means that sometimes it is using an old user, it is a tradeoff because it is also not as intrusive to the user.  You can somewhat force it to notice a user change by logging into windows as a new user, waiting five minutes, then going to a simple http site with no parameters such as http://www.bing.com/

    That being said, if all you want is an easy way to bypass exe blocks there is a better way.  Go to Web Protection, Filtering Options, Bypass Users.  Add a user here.

    Now on all block screens there will be a Unblock button.  Click it and you will be asked for credentials.  Enter in the credentials of the bypass user you have configured.  You will now be allowed to download the file.  Note that this does not change the "logged in user". The intention is that IT support staff can make themselves Bypass Users.  Then when someone complains they really need a file the IT support guy can walk over to the desk, enter in their override user/pass, and allow the download. 

    IIRC you can even create a local (non AD) user called "bypass" with a known password.  Then tell your users you trust with those credentials so that they can decide for themselves whether they should override the block.  Or if this is really common even consider using Warn instead of Block.

  • Thanks for the input.

    I was also told by support that bypass user would only work for sites and not extension blocking? This is what I first looked at as a solution....

    However, if I add a bypass user, click OK, I don't get the unblock option when attempting to download an exe. http://imgur.com/uVto6mB

    Do I need to reboot the appliance or restart any services?

    From support - 'Bypass users option would work for all the users, however it would not work in the case of extension ublocking. This feature would not work if you are trying to unblock any exe files and it only works for the websites.'

  • I think that's right.  I forgot that bypass only does category blocks and not file blocks.  This feature is actually from when the UTM was by Astaro and I don't think has changed at all in the last 3 years.  I don't think it is commonly used after we introduced website tagging.  Most admins prefer to do the Allow while sitting at their own desk and logged into WebAdmin rather than walking over to the user's desk.

    Sorry, I don't think there is any way of easily doing it from the user's terminal without logging in as a different user.  If you are using AD SSO you have the limitation I described above, which AFAIK is at worst a 5 minute delay.

    You could use Browser authentication which would be immediate.  After logging into the Portal the user remains logged on until they close that browser tab.  If they click logoff then a different user can log in.

  • The 5 minute delay for AD SSO with the proxy in transparent mode- are you saying there needs to be 5 minutes of no web activity from the machine before re-authentication? The documentation seems to suggest that browsing should not affect the time to re-auth, but in my testing It's taken demonstrably longer than 5 minutes to re-authenticate via the browsing to a plain http site than 5 minutes - In one case, more than 30 minutes. If it were 5 minutes it would a be kind of acceptable cludge.

    Not sure why the bypass user couldn't have worked for exe files too, I see from a cursory google  it's been a feature request for over 3 years. Shame.

    Basically it seems I have two options, lower security or inconvenience admins and users.

    Is the UTM going to continue to be actively developed? or is development moving to the XG platform?

    Cheers 

  • With any new feature development, it is a balance of how many people (and what type) of people are asking for feature X versus feature Y and which feature will help the most people, be the most popular, and drive the most sales.

    Please recognize I'm volunteering my time in these user forums, I'm not here in any official capacity. I know you are already engaged with Support.  Raising a feature request with Support gets a lot more "weight" than at that site.

    Off the top of my head it is controlled by the following setting (I may be wrong).  Using the command line:

    cc get auth cache_lifetime

    It is 300 seconds, which is 5 minutes.  You can change the "get" to "set" and change it if you want.

    It should be that if you log into Windows as a different user and you are doing "plain" browsing  the UTM sees the new user within 5 minutes.

    In my opinion, the majority of admins find it a greater inconvenience to log into people's workstations as themselves then to log into webadmin.  Once the policy is configured, doing a bypass in webadmin takes about 30 seconds including the time it takes to log in.  You may find that inconvenient.  Most people don't.  Its true that the product doesn't behave in your preferred workflow, but the product does give you a way of achieving the same goal with a different workflow.

    You are using UTM 9.35.  9.4 is just released.  9.5 is being planned right now.  The UTM is being actively developed.  However as the UTM is already feature rich and the XG is not yet at feature parity there will be a greater development effort put into XG.

  • I do appreciate the time taken to respond.

    I understand that different organisations work differently, as you've mentioned though, a bypass user would be a really straightforward method of, well, bypassing the blocking. I imagine there must be a good reason why it hasn't been implemented or the developers would have already done it.

    Thanks for your assistance. It's certainly been more useful than 'premium' support has been.

  • No problem.

    I suspect that it is not a technical issue.  Its more of a priority issue.  When a customer with a 5,000 seat license asked for a feature it gets higher priority than a feature asked by a dozen people using the free Home license.  Sandboxing is a sexy feature than drives advertising and sales.  Improvements to a rarely used feature does not.  Features that have workarounds get lower priority than features that have no workaround.  That is a reality that exists for any company anywhere.  Product Management decides what features get worked on and it is a business decision as much as anything else.


    As for support - I just have more experience in this specific area.