0 Replies Latest reply on May 7, 2015 12:54 PM by jebeling

    Promptless Transparent Proxy Try Auth Session/IP Based - No Client Configuration Required

    jebeling

      Are you looking for a way to do prompt-less try authentication (Authenticate users joined to domain without prompt, and identify users who aren't domain members when possible without prompt) for a transparent proxy deployment without touching the clients?  Cookie based auth often is not an option because cookie auth doesn't work so well for apps like updaters and such, and for some browsers cookie-auth requires security setting changes. This ruleset was developed to address this specific problem.

       

      This ruleset will only work if every transparently redirected client has a unique IP. As far as I know, this  "Try Authentication" ruleset can not be made to work without prompt using Kerberos in a transparent proxy deployment.

       

      Note that, as always, transparent proxy is not a preferred general deployment method except when using McAfee Client Proxy. Transparent proxy without "touching" the client works, and is fully supported, but it makes everything especially rule creation and application more complicated in order to deal with authentication and HTTPS. Explicit proxy or McAfee Client Proxy is highly recommended  for clients you can touch and configure and then use transparent proxy as a supplement only for machines that cannot be configured to use explicit proxy or MCP. When multiple deployment methods are used in the same environment, best practice is to distinguish them by using different proxy ports (the attached ruleset limits the authentication to port 8888 which was configured in my environment for transparent bridge port redirection). Policies should be more restrictive for clients (especially those that cannot be authenticated) that are not using MCP or explicit proxy. For example, it is highly recommended that HTTPS to uncategorized sites is blocked for all transparently redirected clients that are not using MCP (McAfee Client Proxy).

       

      The attached ruleset seems to meet the requirements fairly well. IE and Chrome should work without altering the client if there is a DNS entry that clients can access to resolve the web gateway shortname and the authentication redirect uses the shortname (redirect URL is changed in the configuration settings of IP Authentication, my hostname is MWGTransBr). For Firefox you would have to add the web gateway shortname URI to the  network.automatic-ntlm-auth.trusted-uris list in about:config to avoid the prompt, but again if you enter anything at all at the prompt, it should disappear for the remainder of the session.

      FirefoxNTLMURI.png

       

      The ruleset works by only attempting to authenticate if the client IP has already authenticated or if the User-Agent string is available, does not match the Authentication Bypass User-Agents list and does match the Authentication Capable User Agents list.


      This ruleset has not been extensively tested, and like other postings from those outside of support (like me), will likely not be supported by McAfee. Use at your own risk. Rules could probably be simplified but v11 seems to be working pretty well in my lab and the one customer I built it for.

      .

      I believe that a better alternative to not authenticating Firefox at all is to not add *Firefox* to the Bypass List and instead add a customized Welcome Page ruleset that pops something like this:

       

      FireFox Welcome.JPG

       

      to Firefox users once a day  (I have the welcome page timeout set for 10 hours in my ruleset). Example blockpage html, image for the blockpage and ruleset attached. Obviously the welcome page ruleset would be positioned above the TryAuth ruleset and you would want to customize to match your DNS name.(My shortname is mwgtransbr)

       

      The settings in version 11 are 33 minutes (1980 seconds) for cache time and less than 30 minutes (1800 seconds) cache time remaining for revalidation under ideal conditions. These times could be increased to reduce the chance of unauthenticated requests (first request can't be authenticated or ideal conditions did not exist for any request before the cache time expired), but there is already exposure of mis-authentication, if a user picks up an IP that was recently used for web traffic by another user. For example if I am using Firefox and its user agent is listed in authentication incapable agents, or I am exclusively using HTTPS, and I pick up the IP that the CEO was recently using, I can surf with the CEOs web policy until the cache timer expires, and the logs will display the CEOs username not my login. These times could be shortened to reduce the chance of inaccurate authentication for changing IP/user associations, but this comes at the cost of increasing the probability of having more requests from domain members not being matched to any user.


      By keeping the reauthentication threshold close to the cache time, you reduce the “window of inaccuracy” for different users attaching to the same IP in sequence within the time window, if their requests match the ideal conditions relatively frequently. Regardless of the size of the time window the reauthentication won’t happen unless all of the criteria for “ideal conditions” match.


      Fewer issues will be encountered if SSL scanning is enabled and the authentication ruleset is placed below SSL scanning, because in this case, revalidation can occur on HTTPS GETs as well as HTTP GETs.


      Comments, suggestions, questions, improvements welcome.