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 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.
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).
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).
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).
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.
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).
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.
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).
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).
1.5.0_directproxy_ntlm.pcap - Be sure to decode port 9090 traffic as HTTP
1.5.1_directproxy_basic.pcap - Be sure to decode port 9090 traffic as HTTP
A direct proxy deployment with direct proxy authentication is a perferred deployment for Citrix or shared workstation environments.
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).
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).
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.
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).
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.
If you have the ability to push out group policy settings this is the easiest means to push out the appropriate browser 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.
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.
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.
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.
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.
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.
2.5.0_authserver_ntlm.pcap - Be sure to decode port 9090 traffic as HTTP
2.5.1_authserver_basic.pcap - Be sure to decode port 9090 traffic as HTTP
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).
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.
There is no default of this ruleset! See attachments (3.5.0_directproxy_authserver.xml).
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.
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
Same as shown in the above screenshot, below Global Whitelist, above Common Rules.
See considerations for the respective authentication example.
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.
The default rules will apply to unauthenticated traffic, they will also block requests that are not able to be verified.
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.
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.
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.
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.
4.5.2_mcp_auth.xml_v2.zip - McAfee Web Gateway ruleset with customizations described above (fixed for 7.5.2).
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
-Login Page w/ SSL
-McAfee Identity Manager
-Dealing with Apple Products
-FTP proxy authentication
The more comments I get, the more likely will be to update this.
This should have given you the right idea of what kind of authentication to use based on the deployment type you have in place.