Bypassing authentication and filtering for user agents or sites

Some applications cannot authenticate with the cloud service. This might occur with applications such as instant messaging programs, antivirus updates, or software update services.

The Authentication Bypass tab on the Web > Settings > Bypass Settings page enables you to add and edit custom settings to change the default behavior for failing applications or websites that cause problems with authentication.

To bypass authentication for particular applications or sites that do not properly handle authentication challenges, you can specify user agents, domains, URLs, or a combination of these.

Tip:

A user agent is identified by a string sent from your browser or Internet application. This identifies which browser or application you are using, its version number, and details about your system, such as the operating system and version. The destination server can use this information to provide content suitable for your specific browser or application. For example, this is the user agent information for Firefox:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6)

In this example, Windows NT 5.1 indicates that the operating system is Windows XP, and the language setting is US English.

To add a setting for an application or site:

Steps

  1. On the Authentication Bypass tab, click Add under User Agents & Destinations.
  2. Enter a Name for the rule. This name appears in the Authentication Bypass list on the Bypass Settings page, and you can click on it at a later date to edit your settings.
  3. Select the Authentication method for the rule. Note that you can only select a fallback option for the authentication type configured in the policy - for example, if the policy specifies only NTLM identification, you can select Basic or No authentication, but not Form login.
    • Use defaults: Uses your default authentication method.
    • NTLM: Uses NTLM identification for the specified user agent(s) and destination(s). If an application is not NTLM-capable, basic authentication will be used instead. For more information about NTLM identification, see NTLM transparent identification.
      Note: You must have NTLM identification enabled for your account to use this option.
    • Form login: Displays the secure login form to users before they use their cloud credentials to proceed over a secure connection. For more information, see Access Control tab.
    • Basic: Uses the basic authentication mechanism supported by many web browsers. No welcome page is displayed. For more information on basic authentication, see Access Control tab.
    • Welcome page: Displays a welcome page to users before they use basic authentication to proceed. The welcome page is configurable in each policy on the Access Control tab. Note that the welcome page is not available for traffic from I Series appliances. For more information, see Pre-logon welcome page.
    • No authentication: Bypasses all authentication and identification methods in the cloud. Select this option for Internet applications that are incapable of authentication.
  4. Content filtering is enabled by default. Optionally, you can bypass all content filtering for the specified user agent(s) and destination(s) by selecting Disabled.
    Warning: We strongly recommend you do not disable content filtering unless it is for applications and sites that do not work with the cloud service and that you trust implicitly. Disabling content filtering overrides all other filtering rules, including web category filtering actions. This means that all content is allowed. This could allow viruses and other malware into your network.
  5. Define the user agents, if any, for the rule:
    • If the application does not send a user agent string to the Internet, select No user agent.
      Note: This option will match against all applications that do not send a user agent. In this case, we recommend you refine the rule by entering one or more URLs or domains in the Destination sites field.
    • To apply the rule to all user agents, select All user agents. You might want to do this if you are setting up a custom rule that applies to all browsers on all operating systems in your organization.
    • If you want to apply the bypass rule to one or more user agents, select Specific user agents, and enter each user agent on a separate line. Use the asterisk wildcard to match one line to multiple user agent strings, for example Mozilla/5.0*.
  6. Define the destination sites (if any) for the rule:
    • To match against all domains and URLs, select All destinations. You might want to do this if you are setting up a custom rule that applies to a specific user agent that accesses multiple sites.
    • To apply the rule to one or more sites, select Specific destinations, and enter each URL or domain on a separate line. URLs must include the protocol portion (http://) at the beginning and a forward slash (/) at the end - for example, http://www.google.com/. If these elements are not present, the string is treated as a domain. Domains cannot include a forward slash at the end - for example, mydomain.com.

      Use the asterisk wildcard to match one line to multiple destinations: for example, entering *.mydomain.com would match against all domains ending in ‘mydomain.com.’

  7. Click Save.

Next steps

To view the user agents that have made authentication requests via the cloud service, run the User Agents report (under Reporting > Report Catalog > Advanced). If a user agent in this report has a high number of authentication requests, it may be experiencing authentication problems.