Web Gateway: Choosing the right Authentication Method for your Deployment

• Introduction
• Direct Proxy Auth vs Authentication Server Auth (for Transparent Setups)
• Authentication “front-end” vs “back-end”
• Ruleset Library
• Common Authentication Examples by Deployment Method
• Direct Proxy
• Transparent Modes (Transparent Router / Transparent Bridge / WCCP)
• Direct Proxy AND WCCP
• Alternative uses of Authentication and applicable deployment type
• McAfee Client Proxy (MCP)
• Conclusion

Introduction

I am writing this document as there is often a lot of confusion about what kind of authentication should be performed based on the type of deployment chosen. This document will discuss the most common examples, and show the ruleset/rules in context for reference. This document will only discuss how the Web Gateway obtains the credentials also known as the authentication “front-end”. This article does not discuss how 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 Web Gateway obtains the users credentials. The Authentication “back-end” has to do with how the Web Gateway validates those credentials. The type of authentication front-end chosen dictates how the 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).

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.

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).

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.

Expected or likley 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).

Modify or disable Authorize User Groups

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

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).

Placement

Typically Direct Proxy Authentication would be placed after the Global Whitelist, but before Common Rules. See screenshots above for more info. Placing the ruleset in this manner will allow for Global Whitelist 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 McAfee Web Gateway’s response (407) offering NTLM
• Packet #11 shows client sending Negotiate step of NTLM process
• Packet #16 shows McAfee Web Gateway responding with Challenge step of NTLM process
• Packet #18 shows client sending final step (Authenticate) of NTLM process
• Packet #41 shows McAfee 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 McAfee Web Gateway’s response (407) offering only Basic auth
• Packet #11 shows client sending Basic credentials
• Packet #32 shows McAfee Web Gateway allowing the request and delivering the content

1.5.2_directproxy.xml – McAfee 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 a the McAfee Web Gateway issues another redirect back to the originally requested URL. To see the whole process the tcpdump 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.

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 MWG will send a redirect to the Authentication Server (see below ruleset).

Authentication Server

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

Expected or likley modifications

As the 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 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.automatic-ntlm-auth.trusted-uris).

The McAfee Web Gateway IP or fully qualified domain name needs to be added to a Security zone which allows for Automatic login. In the example, I have added the McAfee 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.

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/library/dd572939.aspx

• Add sites to intranet zone: Computer Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > 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): Computer Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone, then find “Logon options”.

Modify authentication server URL to match existing security settings

If your browser has security settings to include your internal domain in the Intranet Zone (*.yourdomain.local), it may be more conveient to customize the McAfee Web Gateway’s Authentication Server URL to match the existing security settings. See below for examples. If you change the URL it MUST resolve to the McAfee Web Gateway.

Default URL – References a property which contains the McAfee Web Gateway’s IP address as well as a property which uses the port for which the request came from. Each item between the dollar symbols ($) is a property, the other items “http://” and “:” are static strings.

http://$<propertyInstance useMostRecentConfiguration=”false” propertyId=”com.scur.engine.system.proxy.ip”/>$:$<propertyInstance useMostRecentConfiguration=”false” propertyId=”com.scur.engine.system.proxy.port”/>$

Default URL (human readable): http://10.10.69.71:9090

Alternative URL – References a property which contains the McAfee Web Gateway’s hostname instead as well as a the port again. The static strings in the text below is “http://” and “.yourdomain.local:”.

http://$<propertyInstance useMostRecentConfiguration=”false” propertyId=”com.scur.engine.system.hostname”/>$.yourdomain.local:$<propertyInstance useMostRecentConfiguration=”false” propertyId=”com.scur.engine.system.proxy.port”/>$

Alternative URL (human readable): http://mwgappl.yourdomain.local:9090

Background information on the Authentication Server URL  – The Authentication server URL is generated by the appliance when a request is made, so if you have multiple appliances, each of them will generate a different URL. For this reasoning the URL must be dynamic and as such uses properties to call the IP of the machine or hostname.

Enable “Re-validate Session under ideal conditions” rule

Under the default rules, a user must perform authentication every 600 seconds. There are certain situations where you may not want authentication to happen. Enabling the “re-validate” rule allows a session to be extended under ideal conditions. An example of less than ideal conditions would be as follows.

1. User logs into PC, browses to the Web, in the process, they authenticate with MWG using the authentication server (they now have a 600 second / 10 minute browsing session before they have to authenticate again).
2. Immediatley after, the user visits their helpdesk portal to file a ticket (599 seconds remaining on their browsing session).
3. The user is filling out details in the helpdesk form, they did NOT submit it (takes about 300 seconds / 5 minutes).
4. The user decides to browse the web a little (200 more seconds).
5. The user goes back to the helpdesk form to fill in the final details (takes 200 seconds, session expired 100 seconds ago).
6. The next request made by the user must perform authentication because their session has expired.
7. The user clicks submit, and all form data is lost (because they were required to authenticate instead).

This is why the “Ideal conditions” rule is important, to prevent situations like this.

With the “Re-validate Session under Ideal Conditions” rule enabled, the user would not have been forced to authenticate in step 7, but rather in step 4 and avoided the authentication on the POST request.

Increase session TTL

For reasons listed in the previous point (ideal conditions rule) it would be a good idea to increase the session TTL if needed. Alternatively, if you’re users do not have to share their workstations this can be increased as well.

Update “Revalidate session under ideal conditions” to coordinate with session TTL increase

If you decide to increase the session TTL, it would be a good idea to increase the value in the “ideal conditions” rule. Under the default rules a “hard-check” is performed every 600 seconds. With the “ideal conditions” rule enabled, a “soft-check” is performed every 200 seconds (600-400). Here is an example of values you could set in place.

Values:

• Session TTL: 3600 Seconds (1 hour)
• Ideal Conditions: 600 Seconds (10 minutes)

What values mean:

• Hard-check will be performed every 1 hour (if there is no activity, or if ideal conditions did not occurr).
• Soft-check will be performed every 10 minutes provided an HTTP GET request is made within the hour session.

Placement

As with Direct Proxy Authentication, the Authentication Server ruleset would be placed after the Global Whitelist, but before Common Rules. See screenshots above for more info.

Technical Details / Attachments

2.5.0_authserver_ntlm.pcap – Be sure to decode port 9090 traffic as HTTP

• Original request: tcp.stream eq 0, packet #9 shows redirect to Authentication Server URL.
• Authentication Server request: tcp.stream eq 1, packets  #21 and #27 show authentication being performed. Packet #29 shows McAfee Web Gateway issuing a redirect back to original URL.

2.5.1_authserver_basic.pcap – Be sure to decode port 9090 traffic as HTTP

• Original request: tcp.stream eq 0, packet #9 shows redirect to Authentication Server URL.
• Authentication Server request: tcp.stream eq 1, packet #21, show authentication being performed. Packet #24 shows McAfee Web Gateway issuing a redirect back to original URL.

2.5.2_authserver.xml – McAfee Web Gateway ruleset with customizations described above.

Implementation Considerations

Use of the authentication server with a Citrix based architecture or shared workstation environment will result in mixed authentication information (userA authenticates, obtains a session, then userB logs in and is still browsing under userA’s session).

Direct Proxy AND WCCP

When using multiple deployment methods it is necessary to change the authentication front-end based on how the request is received (while using Direct Proxy, or if it was intercepted using WCCP). The easiest means to accomplish this is by the incoming proxy port.

What it looks like (by default)

There is no default of this ruleset! See attachments (3.5.0_directproxy_authserver.xml).

Expected or likley modifications

Differentiate between Direct Proxy users and WCCP users

As stated above different deployments call for different types of authentication to take place. In the below screenshot I have designated Direct proxy traffic for port 9090, and WCCP traffic for port 9091. This distiction can be used in the proxy rules to differentiate the type of incoming traffic.

Update authentication rules to apply to their respective deployment type

Following the proxy port settings stated above you must update the ruleset criteria to match (see below).

• Direct Proxy = Direct Proxy Authentication = 9090
• WCCP = Authentication Server = 9091

Placement

Same as shown in the above screenshot, below Global Whitelist, above Common Rules.

Technical Details / Attachments

3.5.0_directproxy_authserver.xml – McAfee Web Gateway ruleset with customizations described above.

Implementation Considerations

See considerations for the respective authentication example.

Alternative uses of Authentication and applicable deployment type

McAfee Client Proxy (MCP)

McAfee Client Proxy is an application that is installed on your endpoints. The primary function of the McAfee Client Proxy is to intelligently route web traffic to specified proxies. MCP is also designed to pass encrypted user information to the proxies it communicates with. The McAfee Web Gateway has the ability to decrypt this information and use it in it’s rules.

What it looks like (by default)

The default rules will apply to unauthenticated traffic, they will also block requests that are not able to be verified.

Expected or likley modifications

Modify proxy port for transparent common name handling

When using MCP, for SSL requests, it will make requests to the Web Gateway using the IP of the destination web site. As such the proxy port on Web Gateway needs to be adjusted in order to accomodate this change. On the proxy port you must check the box for “Transparent Common Name Handling for Proxy Style Requests. This will prevent any common name mismatches from occurring. This is why it is good to have a separate proxy port dedicated to MCP traffic.

Differentiate between MCP users and other proxy traffic

In order to distinguish between other sorts of traffic, it may be ideal for you to setup a dedicated proxy port for MCP traffic. In the example below, I chose 9092. You should check the box for “Transparent common name handling for proxy style requests”.

As an additional proxy port has been added and dedicated to MCP users, so should the MCP authentication rules should be reflected to incorporate this.

Group membership issues

MCP is able to pass group membership information to the Web Gateway, but there are some circumstances where MCP may only be able to pass limited group information. As such it may be a good idea to disregard the group information given by MCP, and perform a LDAP lookup against the directory itself. This can be done with a separate LDAP lookup.

Placement

Contrary to typical authentication rules, MCP authentication should be placed towards the top most of the ruleset. This is required because we need the MWG to verify the headers of MCP. All MCP requests should have this header information, so if it doesn’t then there is no use proceeding further.

Technical Details / Attachments

4.5.2_mcp_auth.xml_v2.zip – McAfee Web Gateway ruleset with customizations described above (fixed for 7.5.2).

Implementation Considerations

For implementation considerations on MCP check out my other guide Best Practices: Setting up McAfee Client Proxy with Web Gateway: TO DO

• -eDirectory
• -Certificate Authentication
• -Login Page w/ SSL
• -Cookie Authentication
• -Proxy Chaining
• -McAfee Identity Manager
• -Try-Auth
• -Dealing with Apple Products
• -IM authentication
• -FTP proxy authentication

Conclusion

This should have given you the right idea of what kind of authentication to use based on the deployment type you have in place.