Web Gateway: Choosing the right Authentication Method for your Deployment

[#1]

• 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: https://community.mcafee.com/docs/DOC-4996

-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

The more comments I get, the more likely will be to update this.

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.

[almeida]

Hi. This is a great document.

But how about authentication against a corporate SSO infrastructure (OpenAM - http://en.wikipedia.org/wiki/OpenAM) using REST? Maybe using the same cookie that is used by the intranet servers.

[jscholte]

Hi Almeida!

I have looked into OpenAm before it's very interesting, but at the moment authentication via OpenAM or other products using REST for SSO is not currently integrated into the product. If you havent already, I would suggest filing a product enhancement request (https://kc.mcafee.com/corporate/index?page=content&id=KB60021).

Best,

Jon

[northernfrontie]

Has anyone looked at the possibility of providing a mechanism to kill the current authentication session, so that I user on workstation can re-authenticate as a different user, without having to wait for the session TTL to expire.

[jscholte]

Still waiting on a clean way to do this by adding an event to do so...

[prajoshgeorge]

Great article.

[jebeling]

If you use the system shortname in the redirect to the authentication server (transparent proxy deployments), you can get promptless authentication without changing the default browser settings for IE and Chrome. If you have set your system name as FQDN you can use a UserDefined property in the URL string and set the User-defined Property with string manipulation in an event of a rule prior to checking Authentication.

[whitead]

Can you expand on this? i am interested.

[jebeling]

With McAfee Web Gateway 6.7 and later you can have completely prompt-less authentication in an AD environment without doing anything to the default  browser settings for IE and Chrome. By default IE and Chrome will allow automatic login for sites in the Intranet Zone and sites are automatically included in  the Intranet Zone if they are in the same subnet, and their IP can be resolved by shortname. If the clients are not on the same subnet the IP address or  shortname will need to be added to the site list for the Intranet Zone.

For Firefox the setting for automatic login can be found by browsing to “about:config”.  The McAfee Web Gateway auth server needs to be added as part of “network.automatic-ntlm-auth.trusted-uris”. There is a version of Firefox that can be managed in an Active Directory environment via aplugin. However, the plugin can only manage the custom distributions (check outwww.frontmotion.com), it cannot manage an instance of Firefox that was directly downloaded from Mozilla.

To use shortname for the redirect in 7.x you need to change the settings for Authentication.Authenticate. By default the settings are located in Authentication  Server Redirect and the Authentication Server URL is set to: http://$<propertyInstanceuseMostRecentConfiguration="false"propertyId="com.scur.engine.system.proxy.ip/>$:$<propertyInstanceuseMostRecentConfiguration="false"propertyId="com.scur.engine.system.proxy.port"/>$.

The first piece of which is the IP of the MWG. So if the first piece is changed to a shortname that can be resolved by the client to an IP that is in the same subnet as the client, then the browser settings for IE or Chrome should not need to bechanged.

To use the shortname simply change the URL to read http:// $<propertyInstanceuseMostRecentConfiguration="false"propertyId="com.scur.engine.system.hostname"/>$:$<propertyInstanceuseMostRecentConfiguration="false"propertyId="com.scur.engine.system.proxy.port"/>$ or, in a single gateway environment you can simply replace the hostname part of the string which is "$<propertyInstanceuseMostRecentConfiguration="false"propertyId="com.scur.engine.system.proxy.ip"/>$" with the actual shortname.

The ruleset above from the ruleset library Authentication Server (Time/IP Based Session) available in 7.1.

If you have named your systems with FQDN, the hostname property will not return shortname so instead you need to use the following, much more complex string for the redirect: 

http://$<propertyInstanceuseMostRecentConfiguration="false"propertyId="com.scur.engine.stringfilter.string.replacefirstmatch"><parameters><entry><string>com.scur.engine.stringfilter.string.replacefirstmatch.source</string><parametervalueTyp="2"><value><propertyInstanceuseMostRecentConfiguration="false" propertyId="com.scur.engine.system.hostname"/></value></parameter></entry><entry><string>com.scur.engine.stringfilter.string.replacefirstmatch.search</string><parametervalueTyp="3"><value><stringValuevalue="regex(\..*)" stringModifier="false"typeId="com.scur.type.regex"/></value></parameter></entry><entry><string>com.scur.engine.stringfilter.string.replacefirstmatch.replace</string><parametervalueTyp="3"><value><stringValue value=""stringModifier="true"typeId="com.scur.type.string"/></value></parameter></entry></parameters></propertyInstance>$:$<propertyInstanceuseMostRecentConfiguration="false"propertyId="com.scur.engine.system.proxy.port"/>$

The nice thing about this string is that it will return the shortname (no dots) regardless of how youspecified the systemname.

[whitead]

Awesome! Thanks! Very detailed and appreciate it. Makes sense!

[jscholte]

Adjusted Authentication server section regarding "Expected or likley modifications". Settings for Firefox were incorrect. Screenshot showed semi-colon delimiters, but comma or space must be used in case of multiple. Also incorporated Kerberos related about:config setting.

Best,

Jon

[abenjami]

Just as a FYI... If you are getting the following error message;

You might have set the following in your browser settings;

If this is the case, you are not restricting the authentication to the specific sites in your "Intranet Zone" and this is resulting in the security pop-up above. It will probably provide better security to have this set only to your trusted sites which would include the Web Gateway instead choosing this option so that you can limit where the credentials are being passed.  However, if you do set this "Logon" option, you will need to also set the following to get rid of the "Security Warning" above.

Just wanted to make sure in the instance anyone else runs into this issue.

Thanks,

Andrew

[Troja]

Hi all,

has anyone tested such a authentication server solution in a reverse proxy envirionment?

Cheers

[Troja]

Hi all,

authentication server works in my reverse proxy environment.

Thanks , just changed in the string system.hostname to url.host.  🙂

Actually i want to extend this with some more features.

- some kind of logoff to do a real disconnect

- The browser shows a authentication popup. Could this be replaced with some kind of authentication form?

Anyone an idea?

[jscholte]

Hi Thorsten,

I wouldnt recommend using the Auth server described in my document above, for reverse proxy.

Reason being is that it is based on the client IP. For a reverse proxy environment it would be better to use cookies.

If you have cookies, you can clear the browser cache and they are gone. That is one form of logout, however MWG will not destroy the cookie.

You can certainly use a block page to display a web form, there is one in the ruleset library that you can use for example.

Best Regards,

Jon

[Troja]

Hi Jon,

thanks for the information, it´s just a test in my environment......

Authentication works does not work in the moment, hope i will fix it... 🙂

Cheers

[moekhass]

Great document. Anything on Novell eDirectory ldap authentication? I have it setup and works OK with Windows system. When users have an established session, MWG doesn't display authentications message. No prompts in either case. The problem is with Linux desktops. They get authentication required message on browsers, but how can I provide them a login prompt which in turn will allow them to authenticate against Novell ldap servers?

[jscholte]

Hi Moe,

Blast from the past! eDirectory?!?!

I wrote the eDirectory guide here (a long time ago) -- it doesnt apply to what you're asking here but relevent: McAfee Corporate KB - Web Gateway 7.x: How to set up and troubleshoot eDirectory authentication KB69...

I'm guessing that the Linux desktops are not populating their networkAddress attribute properly. If you can get them to populate the networkAddress attribute in eDirectory, then you wont need to prompt for authentication.

However, with eDirectory that can be a common issue, so it's not a bad idea to implement some sort of fail-over anyways. To do this, (I believe) the rules will need to be configured as such. Please if you do test these rules, I'd suggest isolating the rules to your own test machine (rather than applying it to everyone). eDirectory is a different type of auth and I dont have an eDirectory server setup anymore, but I'm pretty sure this should do it.

I'd suggest by making sure the LDAP based eDirectory settings work first (using the auth test feature), then testing them alone as your auth rules, and then incorporate them into the failover rules, then finally in for everyone. When testing, again, test with rules that only apply to you and disable the LDAP cache settings while testing and turn on while in production.

If you have any problems, start a new thread rather than using the comment section here

Best Regards,

Jon

[chris.lee@exper]

Hi,

i follow your guide for the WCCP authentication method. i bump into a issue where if user 1st connection is HTTPS connection. it will not redirect for authentication. because i have problem where user 1st website is HTTPS://mail.google.com. there will not redirect for authentication.because the command.name is CONNECT.

is it ok to remove the command.name does not equal "CONNECT" criteria?

Thank you.

Regards,

Chris

[jscholte]

Hi Chris,

I replied to your discussion post, removing the CONNECT criteria would not solve the problem here because during the CONNECT we should not perform the redirect, in the past this resulted in page cannot be displayed messages.

Could we continue the thread here?

Best Regards,

Jon