Skip to main content

Check out Interactive Visual Stories to gain hands-on experience with the SSE product features. Click here.

Skyhigh Security

Choose the Right Authentication Method for your Deployment

  1. Last updated
  2. Save as PDF

Introduction

This document will discuss the most common examples, and show the ruleset/rules in context for reference. This document will only discuss how the Secure Web Gateway obtains the credentials also known as the authentication "front-end". This article does not discuss how Secure Web Gateway validates the credentials also known as authentication "back-end" (example of an authentication back-end would be NTLM, Kerberos, LDAP, eDirectory, etc...).

Direct Proxy Auth vs Authentication Server Auth (for Transparent Setups)

Direct proxy authenticates every connection, only browser change required is to the proxy settings. Authentication server is a session-based authentication. Authentication server requires a trust relationship with the browser.

Authentication "front-end" vs"back-end"

As described above, the Authentication "front-end" has to do with how Secure Web Gateway obtains the users credentials. The Authentication "back-end" has to do with how the Secure Web Gateway validates those credentials. The type of authentication front-end chosen dictates how the Secure Web Gateway is to interact with the user (this may mean the user gets prompted).

Ruleset Library

The ruleset library is a place to find example rulesets for use within your configuration. It can be accessed from within the rulesets tab under the "Add" button. When you select a ruleset to add, it may prompt you stating that conflicts exist, simply click "Auto Solve Conflicts" and then choose the option that works best for you (solve by referring to existing objects, or solve copying and renaming to suggested).

clipboard_e2b4454d702d37706e9fe93f88647b196.png

 

Common Authentication Examples by Deployment Method

Direct Proxy

The recommended authentication front-end for Direct Proxy is "Direct Proxy Authentication and Authorization". This ruleset can be found in the ruleset library. When using NTLM or Kerberos direct proxy authentication is promptless (provided the browser supports it, Safari doesn't for example).

What it looks like (by default)

Direct Proxy Authentication and Authorization

The default ruleset has rules for creating exceptions based on the client IP and the destination URL.

clipboard_edf843695791544a1596d47fa24115ebb.png

Authenticate With User Database

The authentication "back-end" used by default is the internal "User database", this is almost always immediately swapped out for NTLM (see "expected or likely modifications"). This ruleset will only apply if the user has not already authenticated (Authentication.IsAuthenticated equals false) and they have not already failed authentication (Authentication. Failed equals false).

clipboard_e41905c3803ca583c8a927e346995a467.png

 

Authorize User Groups

The third ruleset is meant for restricting web access to a list of user groups. If the user is not in a specified internet access group, they will be blocked.

clipboard_e98417398482427303312f8238e624db7.png

 

Expected or likely modifications

Change out the authentication back-end

As stated above, most customers will immediately swap out the default authentication"back-end" to use their internal resources (such as Active Directory via NTLM).

clipboard_e0bb3870261779299b1bac210077975be.png

Modify or disable Authorize User Groups

Depending on your directory structure and company policy you may need to define the groups that are allowed internet access. If you do not have such a policy then you may just end up disabling the ruleset altogether.

clipboard_ede0665e359e2250ef3a6df383f00c69c.png

Add more exception rules

Depending on your needs you may need to create more exception rules in order to accommodate applications or specific server IP ranges which do not authenticate correctly.In the screenshot above you will see two new rules added one based for User-Agent exceptions (Header.Request.Get("User-Agent)), another for the server IP(URL.Destination.IP).

clipboard_e3d4ee3bb8bd0a2861e1a065b1020b155.png

 

Placement

Typically Direct Proxy Authentication would be placed after the Global Allowlist, but before Common Rules. See screenshots above for more info. Placing the ruleset in this manner will allow for Global Allowlist entries to be allowed without authentication (common requirement).

Technical Details / Attachments

1.5.0_directproxy_ntlm.pcap - Be sure to decode port 9090 traffic as HTTP

  • Packet #4 shows original client request
  • Packet #9 shows Secure Web Gateway's response (407) offering NTLM
  • Packet #11 shows client sending Negotiate step of NTLM process
  • Packet #16 shows Secure Web Gateway responding with Challenge step of NTLM process
  • Packet #18 shows client sending final step (Authenticate) of NTLM process
  • Packet #41 shows Secure Web Gateway allowing the request and delivering the content

1.5.1_directproxy_basic.pcap - Be sure to decode port 9090 traffic as HTTP

  • Packet #4 shows original client request
  • Packet #9 shows Secure Web Gateway's response (407) offering only Basic auth
  • Packet #11 shows client sending Basic credentials
  • Packet #32 shows Secure Web Gateway allowing the request and delivering the content

1.5.2_directproxy.xml - Secure Web Gateway ruleset with customizations described above.

Implementation Considerations

A direct proxy deployment with direct proxy authentication is a perferred deployment for Citrix or shared workstation environments.

Transparent Modes (Transparent Router /Transparent Bridge / WCCP)

The recommended authentication "front-end" for a transparent setup is the Authentication Server. The authentication server works by storing the user's information into a session database. For brevity's sake a user's session consists of their IP address, username, and session expiration time. Each time a request is made, the session database is checked to see if a session exists for the user's IP. If a session exists, the request is passed through. If a session does not exist, a redirect is sent in response to the request. The requesting machine should follow the redirect and authentication will be performed. If the user provides valid credentials, a session is stored and the Secure Web Gateway issues another redirect back to the originally requested URL. To see the whole process the TCP dump shows it very well (2.5.0_authserver_ntlm.pcap).

What it looks like (by default)

Authentication Server (Time/IP based Session)

The "Authentication Server (Time/IP based Session)" ruleset acts as a container for all of the authentication server rules.

clipboard_e567cd2c7a0f6a2a1b4c94fab33321346.png

 

Check for Valid Authentication Session

This ruleset will evaluate whether or not there is a session for the incoming IP address. If there is a session for the IP, then the user will be allowed. If there is NOT a session for the IP, the SWG will send a redirect to the Authentication Server (see below ruleset).

clipboard_ed5d07dbffe8b1c76317a71a9ffe6cae2.png

Authentication Server

This ruleset comes into play when the client makes a request for the Authentication Server. If the user successfully authenticates, SWG will create a session in its session database.

clipboard_e3ee9f13ec9fd87f16a40c05598990f9a.png

Expected or likely modifications

As the Secure Web Gateway issues a redirect to itself when a request is made, there are some client side settings that need to be changed in order to establish a trust relationship between the Secure Web Gateway and the client/browser (which will allow for promptless authentication when using NTLM or Kerberos).

Browser security settings

In order for authentication to be promptless (for NTLM or Kerberos), the appropriate security settings in place. Below are the minimum settings for authentication to take place without prompting the user. See below if you wish to modify IE settings using Group Policy.For Firefox the "about:config" would need to be adjusted, see the settings for"network.automatic-ntlm-auth.trusted-uris" (for NTLM) or "network.negotiate-auth.trusted-uris" (for Kerberos). For Firefox URLs need to be separated by commas or spaces (see:http://kb.mozillazine.org/Network.au...h.trusted-uris).

The Secure Web Gateway IP or fully qualified domain name needs to be added to a Security zone that allows for Automatic login. In the example, I have added the Secure Web Gateway's IP to the Intranet Zone, and set the zone to automatically login, if the site has been found in the Intranet Zone.

clipboard_e10ee9fe8706eb74dd956a8f1e6ef4631.png

clipboard_edb896948ec014784f5d469eab7d87ed7.png

clipboard_e553d0924a4adb65a00bdda79e8b3a6c4.png

 

Push browser settings via Group Policy

If you have the ability to push out group policy settings this is the easiest means to push out the appropriate browser security settings.

Adding sites to Intranet Zone and enabling Automatic login for intranet zone

http://technet.microsoft.com/en-us/l.../dd572939.aspx

Add sites to intranet zone: Computer Configuration > Policies > AdministrativeTemplates > Windows Components > Internet Explorer > Internet ControlPanel > Security Page, then find "Site to Zone Assignment List". Here is a list of possible "values" which indicates the zone:

  1. Intranet zone – sites on your local network.
  2. Trusted Sites zone – sites that have been added to your trusted sites.
  3. Internet zone – sites that are on the Internet.
  4. Restricted Sites zone – sites that have been specifically added to your restricted sites.

Enabling automatic logon for Intranet Zone (on by default): ComputerConfiguration > Policies > Administrative Templates > Windows Components >Internet Explorer > Internet Control Panel > Security Page > Intranet Zone,then find "Logon options".

clipboard_e8d2ab8efa3bf3248011db2a34edc9944.png

clipboard_e8a8dcb658015c99c4cd6e6ca16a2caf0.png

  1. Back to top
  • Was this article helpful?

Recommended articles

  1. Article type
    Topic
  2. Tags
    This page has no tags.