Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 2535 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

UTM webfilter not detecting new user.

Luc Levesque

Hi, 

 

The scenario is, we are a school board. Students don't have access to youtube but teacher do.  I have setup AD SSO, have the profile done, Standard filtering, proxy set with pac file, etc.  Most of the time it works pretty well except for this situation. 

Student logs in to pc, works there for a while and logs off.  Teacher logs in tries to go to youtube and gets blocked. I looked at the logs and the student username is still the detected user. Sometimes it takes no time to change, sometime it takes weeks.  How do I clear that information in the UTM. is there a check mark to not cache user sessions? 

What am I missing here?



This thread was automatically locked due to age.
Parents
  • +1

    You are not using https inspection.

    UTM cannot obtain the user identity if the connection uses https.   As a workaround, it assumes that the current user is the same as the lsat user to make an http request from that address.  This is reasonable, and really the only feasible option.

    If the first-ever request is https, the connection is handled as an unauthenticated user.

    If the user changes, and the second user starts with an https session, UTM will assume the first user is still present.

    If you enable https inspection, the problem goes away because UTM sees the AD SSO (NTLM) information on every request.   But of course, https inspection introduces other challenges.

    Basic authentication (ask every time), and AD SSO with HTTPS inspection, are the only methods with no dependency on IP-to-user assumptions.

  • 0 in reply to DouglasFoster

    ah.  it makes perfect sense. Thanks for the info.  That is the part I was missing. 

     

    If I already distribute the UTM certs, will those https inspection issues still be there?

Reply Children
  • 0 in reply to Luc Levesque

    You should distribute the HTTPS inspection for any configuration, because UTM needs to impersonate the remote server (a) to display a block/warn page when the URL is an https page, and (b) for every connection when inspection is on.

    Issues with https inspection largely involve compatibility:    

    • Ciphersuite issues:  I have posted recently that some sites appear to refuse connection from anything, including UTM, that is running an older version of OpenSSL. 
       
    • Remote site certificate chain problems:   A significant number of sites have installed their server certificate but have not installed their intermediate certificate, creating an incomplete chain.   (A properly configured server will send the server certificate and all intermediate certificates, but not the root certificate.)  The major browsers all do lookups on the certificate revocation data to transparently and safely obtain the intermediate certificate, but UTM does not.   The workaround is to collect the intermediate certificates, as problems are identified, and load them into UTM as if they were root certificates.  This is a hassle, but it is somewhat temporary.   Once a core set of certificates has been collected, the problem stops occurring.

    • Dual-channel websites:   Remote access tools like TeamViewer or GotoMyPC generally use two channels, one for authentication and another for the operational connection.   HTTPS inspection usually breaks these applications, because the two channels originate from different devices, so exceptions need to beconfigured.

    • Issues with ActiveX or other plug-ins that do not work well with https inspection active.

    Overall, if you are going to use https inspection, you should have your log analysis tools in place, and use them routinely, to identify where https inspection has caused problems.   This allows you to be more proactive, rather than depending entirely on user complaints.

  • 0 in reply to DouglasFoster

    Thanks, I appreciate the info. 

    With that I have nailed down the problem. After trying to force the new NTLM to be detected with a http site, the UTM would still pickup up that students creds. Somehow the teacher managed to store a student login credential in her "identity manager" and this is what windows/edge was sending out to the UTM. 

    Once we deleted that erroneous entry in the the manager, everything worked fine.  

Unfiltered HTML