How To: Setting up Web Gateway as a reverse proxy with two factor authentication

Version 5

    Prerequisites

    Proxy Version

    The rule set, and steps below, require Web Gateway version 7.1.5.2.0, or later.  (Versions 7.1.0.x.x, or earlier, do not contain the necessary properties that are used in the rule set.)

    DNS

    To ease the implementation of this configuration, external clients must be able to resolve *.support.local to the Web Gateway's IP address.  (That is, that "mickeymouse.support.local", "jimminycricket.support.local", etc. should all resolve to the IP of the Web Gateway.)  The reason for this is that the Web Gateway will send redirects to the client in order to perform authentication, as well as to maintain the initial URL that the user requested.  Specific DNS entries can be added for each redirect, (instead of a wildcard DNS entry) but they are all contingent on the resources defined later. 

    Two Factors

    For this example, the two-factors that are used are NTLM (Active Directory), and the User-Database.  It is assumed that the Web Gateway is properly joined to the domain, and that basic NTLM authentication is working.  This example is defined to be a proof of concept, and the factors can be changed (i.e. NTLM and RADIUS) at the customer's lesiure.

    Initial Configuration

    Define proper proxy listener ports

    Navigate to Configuration -> Proxies(HTTP(S), FTP, ICAP, and IM) -> HTTP Proxy, and configure the proxy listener ports to match below:

     

    listener_ports_reverse_proxy.JPG

    Import Reverse proxy rule set

    a. Within 'Policy' -> Rule Sets (tab), click to 'Add' a new "Top Level Rule Set".  Select to 'Import rule set from Rule Set Library'. 

    b. Within the Rule Set Library, select to 'Import from file...', and browse for the rule set attached to this doc (Reverse_Proxy_with_Two-Factor_Authentication.xml).  

    c. For any conflicts that arise, select to 'Solve by Referring to Existing Objects'.   You should now have a rule set called "Reverse Proxy with Two-Factor Authentication". 

    d. Note that, as mentioned above, the two factors that will be used are NTLM (against Active Directory), and the User Database.  As such, navigate to 'Reverse Proxy with Two-Factor Authentication' -> Authentication Server -> Gather Two Factor Credentials

    e. The setting container specified in the rule "authenticate first factor" should be set to <ntlm-test>.  Be sure this corresponds to an authentication method of NTLM.

    f.  The setting container specified in the rule "authenticate second factor" should be set to <User Database>.  Be sure this corresponds to an authentication method of "User Database", as this will be our 'Token' credentials below.

    Import block page template

    a. Expand out the new rule set called "Reverse Proxy with Two-Factor Authentication", and then navigate to the sub rule set called 'Authentication Server' -> 'Gather Two Factor Credentials'.  Be sure 'Show Details' is selected in the main pane.

    b. Locate the rule called 'Authenticate First Factor'.  There is a 'Block' action on that rule, and the template listed is '2factorBlock'.  Click on that '2factorBlock' template item.  You'll note that the 'Collection is likely set to 'Default Schema', but the 'Template Name' is blank.

    c. Click to 'Edit' the template name.  Within the Template Editor, under the top 'Templates' section, click to 'Import'.  Import the '2factor-logon-page-template-final.zip' file attached to this document. 

    d. You will be warned that some files may exist, and it will ask if you would like to overwrite the originals.  Select 'No To All'. 

    Correct block page template

    a. With the template imported, you'll now see an available template called '2 Factor Block Page'.  Navigate to that template, and then to 'en', and then click to select 'html'.  You are now viewing the 'source' of the page.

    b. There are two properties that initially need to be correct.  First, look for the section of HTML that looks like:

     

    template_correct1.JPG

     

    c.   Look for the property defined in Red.  It will likely not be the exact same numical value, but click to select the entire '$xxxxx$' item, including both '$' symbols.

    d.  With that item selected, click to 'Add' an item within the HTML editor.  Add a 'Property', an select the very first properyt listed.  (in my case, it is 'Antimalware.Infected'.)  The $Antimalware.Infected$ property now replaces the $xxxxx$ property on the page.

    e. Double-click the $Antimalware.Infected$ now on the page, and then from the drop-down menu that appears, change the property to be User-Defined.2factorfailreason and then click OK.  (We need to do steps d and e here because of a minor bug in the editor that prevents you from adding user-defined properties directly.  This should be fixed in a later version of Web Gateway). 

     

    f. Next, look for this section of the HTML:

     

    template_correct2.JPG

     

    g. Look for the $xxxxx$ property defined in red.  Here, select that property, but be sure to NOT select the double-quotes on either side of it. 

    h. Using nearly identical steps as above, click to add a property, and then add the 'Antimalwre.Infected' property on that page. 

    i.  Double-click on that 'AntiMalwre.Infected' property, and change the property to be User-Defined.2factorurl .  Then, click OK.

     

    j.  Click 'Save Template Changes' to exit the template editor.  For the block action 'template name' listed in the rule 'Authentication First Factor', it should now be set to '2 Factor Block Page':

    template_name.JPG

    k. For the rule Reverse Proxy with Two-Factor Authentication -> Authentication Server -> Gather Two Factor Credentials -> authenticate second factor, be sure that the '2 Factor Block Page' is the selected 'Template Name' for that block action as well.

    l.  Save Changes thus far.

     

    Final Configuration

    Define internal resources

    a. The next step is to define the internal 'resources' that we want access to.  Navigate to 'Reverse Proxy with Two-Factor Authentication -> Reverse Proxy Feature -> Secure Reverse Proxy.

    b.  In the first rule (called 'Map Hosts 'Rewrite Host Source' to Rewrite Hosts Target'), the list 'Rewrite Hosts Source' is the external URL that clients would access. (i.e wiki.support.local).  In the lists 'Rewrite Hosts Target', this is the destination resource that the Web Gateway will connect to (i.e. 10.10.65.101)

    c. Add all applicable external source hosts and target hosts, ensuring that each are in the same relative positions in within each list.

     

    Test

    a. Add a sample user in the User-Database, that has the same username as your Active Directory user. 

    b. On the block page that appears where you enter your two credentials, type your AD username in the Username field.  Type your AD password in the 'password' field, and type the User Database password in the 'Token' field.

     

    Update external domain

    It is likely that the external domain that will be used will not be 'support.local'.  (i.e. perhaps 'mydomain.here' will be used instead).  To update:

     

    a. Navigate to 'Policy' -> Settings (tab) -> Engines -> Secure Reverse Proxy Filter, and select the 'Default' setting container.  Update the 'Secure Reverse Proxy Domain' to be the preferred domain (i.e. mydomain.here).

     

    b. Next, in the 'Policy' -> Settings (tab) -> Actions -> Redirect, click on the 'Redirect to Authentication Server' action setting container.

    c. Leaving every other part of the 'Redirect URL' in place, replace 'authserver.support.local:444' with 'authserver.mydomain.here:444', and click OK.

     

    d. After, within the Template Editor, click to view the HTML of the '2factorBlock' template.  Look for the section of HTML that looks like:

     

    template_new_domain.JPG

     

    e. Change the "form id" line to match:

    template_new_domain_chg.JPG

     

     

    f. Lastly, make sure DNS can resolve '*.mydomain.here', and make sure that entries within the 'Rewrite Hosts Source' list reflect the new domain (i.e. 'wiki.mydomain.here')