LevelBlue Knowledge Base » Knowledgebase » Legacy Products » Secure Web Gateway » Users and Authentication

How to bypass Authentication by header

Charles — Mon, 27 Apr 2015 15:17:40 GMT

This article applies to:

SWG 9.x
SWG 10.x

Question:

Some sites or programs require you to bypass Authentication in order for it to be accessed through the SWG appliance. For Example, Google Earth’s update mechanism will not allow the program to run if it cannot contact its host site, and the host site cannot be reached when using Authentication through the SWG.

Procedure:

To bypass authentication for our Google Earth example, we will bypass using the User-Agent header that Google Earth uses to access its host site.

-Navigate to Polices -> Condition Settings -> Header Fields

-Under Exclude by Headers click edit and enter the following information.

Header Name:

Condition:

Header Value:

- Save and Commit changes.

*note: in VSOS 9.0.0 you cannot add more than one user agent header name to the same Headers Field list. If you need to add more than one user agent you will need to create a separate list for each user agent entry.

-Other programs and hardware have been known to need to have authentication bypassed in order to be used. Here is the program and the Header name used to allow access.

Application	Header	Value	Expression
Google Earth	User-Agent	Regular Expression	^GoogleEarth.*
iPhone	User-Agent	Regular Expression	Apple iPhone.*
iPad	User-Agent	Regular Expression	Apple iPad.*
iTunes	User-Agent	Regular Expression	iTunes/.*
-	-	-	AppleCoreMedia/.*
Microsoft Updates	User-Agent	Equals	Windows-Update-Agent
-	-	Regular Expression	^MicrosoftBITS/.*
Adobe Flash	User-Agent	Regular Expression	^Adobe Flash Update.*

In some scenarios SWG does not recognize LDAP users

ofer Kalef — Wed, 05 Feb 2014 01:20:06 GMT

This article applies to:

SWG 10.x
SWG 11.x

Question:

In some scenarios SWG does not recognize LDAP users, even if they are in an imported group.

Information:

If a customer adds a user/users after importing user/users group, the user/users won't be in the SWG database.

Use scheduled updating of LDAP/AD users or manually import users after any changes that you make to the LDAP tree structure (for example, adding/removing groups, changing their order), or the changes will not be applied.

Users exist in more than one LDAP Group

ofer Kalef — Sun, 24 Nov 2013 03:52:40 GMT

This article applies to:

SWG 10.x

Question:

What if the same user exists in 2 or more LDAP groups and each LDAP group has different policies applied, what policy will be applied to the user?

Reply:

If an LDAP user is included in more than one group, the policy implemented will automatically be that of the first group appearing in the list. Group priority is listed from top to bottom.

How to configure ISA server in order to forward client IPs for HTTPS traffic as well

ofer Kalef — Fri, 23 Aug 2013 04:48:56 GMT

Description
In an ISA-Finjan-Internet topology, with the Vital Security ISA Connector properly working with HTTP requests, no client IP addresses are forwarded to the Finjan appliance for HTTPS traffic.

Symptoms

Cause
The option "Add headers to HTTPS CONNECT request" is not selected.

Solution
In ISA Server Management, select the Finjan ISA plugin. In the section "Configuration / Add-ins", mark the option as checked.

Software Version
Vital Security IP/Username Forwarding Plug-in for ISA Server 2004 to Vital Security IP/Username Forwarding Plug-in for ISA Server 2004 and ISA Server 2006
v 2.1

This article applies to:: NG 1000; NG 5000; NG 6000; NG 8000

This article was previously published as:

Finjan KB 1887

How To Exclude Web Applications From the Authentication Mechanism

Rudolf Kessler — Fri, 31 Aug 2012 07:06:10 GMT

Description
Some web applications (such as Citrix Webmeeting) get stuck due to authentication requests which can not be handled by such applications.
This article describes how to exclude them from authentication mechanism.

Symptoms
Example:
Citrix Webmeeting gets stuck, or the connection setup wizard does not succeed.

Cause
An authentication request is sent to the client in a later session stage, but the application cannot handle it correctly.

Solution
The solution is to exclude this application / site from authentication mechanism.

Drawback: The client is not authenticated or identified anymore and the policy for unknown users is applied.

1. Step: Create a list of URLs you want to exclude (It might be necessary to do a packet trace and analyze the destination URLs)

2. Step: add a condition to your authentication policy (it might be different from this example):

Note: This condition is based on URLs, basically other conditions such as header fields are also possible - it depends on the needs.

Step 3: Commit your changes

Note: This option applies also to other identification policies (IP, Basic)

Software Version
9.x

This article applies to:: NG 1000; NG 5000; NG 6000; NG 8000

This article was previously published as:

Finjan KB 1810

Transparent authentication on SWG and virtual authentication hostname

Rudolf Kessler — Fri, 10 Aug 2012 05:29:56 GMT

This article applies to:

SWG 9.x deployed in transparent mode
SWG 10.x deployed in transparent mode

Question:

What is the purpose of virtual redirection hostname ?

Information:

When SWG is deployed transparently, it can't authenticate clients using the "HTTP 407 Proxy Authentication" method that it uses in explicit mode.Rather, it must use the same type of response that a web server would send "HTTP 401 Unauthorized".

In order to facilitate this, SWG redirects the traffic to a "virtual authentication hostname".

The virtual authentication hostname must resolve to an external IP so that SWG will have a chance to intercept the traffic and issue an authentication challenge.

When the end-user sends the request to the Scanning Server and the Scanning Server is configured to perform user authentication, the Scanning Server responds with an HTTP 302 Redirect, which redirects the user to a virtual host. The virtual host is pre-configured, and its default value is vhost.finjan.com. The virtual host does not have to be a real host; however, the host name of the virtual host must be resolvable by the enduser.

The end-user then closes the session and opens a new session for the virtual host (which does not actually exist). When Vital Security identifies a request for the virtual host, it knows that it must perform user authentication, and it responds to the end-user with HTTP 401 – Authentication Required.

The end-user then sends the credentials, and the Scanning Server authenticates the end-user against the Active Directory.

It is recommended to change the virtual authentication hostname to vhost (without ".finjan.com") and hosting the DNS entry for vhost on local DNS servers.

For testing/evaluation purposes we have been using public DNS server addresses, i.g. 8.8.8.8 or 8.8.4.4.

In transparent mode, user not authenticated/identified on HTTPS website

Rudolf Kessler — Fri, 08 Jun 2012 06:34:06 GMT

This article applies to:

SWG 10.x

Question:

When a user browses a HTTP site, authentication/identification works correctly and any subsequent HTTPS session works fine (the user is already authenticated/identified). When a user browses a HTTPS site first, authentication/identification doesn't work and the logs indicate the user is an "Unknown User". How can we correctly identify the user in both cases? (Configuration is Transparent mode, authenticate or get user credentials identification policy, and IP Caching is set as the "Authentication Retention Method").

A user opening a new browser to a HTTPS site is unrecognized (Unknown User), but there is no problem if the user first browses to a plain HTTP site and then any HTTPS site.

Reply:

Authenticate or Get User Credentials policy for HTTPS is not supported. This can be seen when trying to enable transparent mode on a device with the "Authenticate" or "Get User Credentials" identification policy, as the following alert is displayed:

HTTPS Transaction will not be authenticated as long as Transparent Proxy is enabled.

Or:

It works when HTTP is used first because the user credentials are cached after authentication, and are sent by the browser in subsequent requests to the SWG.

Windows 7 end users cannot authenticate with NTLM

Rudolf Kessler — Thu, 24 May 2012 01:45:52 GMT

This article applies to:

SWG 10.x

Symptoms:

Client can connect with an XP workstation, but not with Windows 7
Using 2008 AD server
Client connections return a "STATUS_INVALID_PARAM" error code when you use a "Send NTLMv2 response only" authentication level in Windows Server
2008 or in Windows Vista

Causes:

An issue in AD server

Resolution:

MS Solution to implement on the AD server is in:

http://support.microsoft.com/kb/957441

How to bypass Authentication by URL

Rudolf Kessler — Wed, 16 May 2012 14:07:33 GMT

This article applies to:

SWG 9.x
SWG 10.x

There may be a need to bypass Authentication for some sites. The below step by step will show how to setup an Authentication bypass list by URL. With this setup you will be able to add URL’s to a custom URL list that will bypass authentication for all users.

Procedure:

First, you will need to create a custom URL list that you can add sites too specifically for authentication bypass. To do this, go to Policies -> Condition Settings -> URL Lists. Add a new URL list; you can call this "Authentication Bypass List" (or any other name you want). Add the URL that you wish to bypass.

Second you will need to add a rule to the Identification rule you are using. Go to Policies -> Identification. Open the Identification Policy you are using and right click on the first rule. Click “add condition”. Condition name: URL list. Applies to: Everything except for the items selected below. And then select the new URL list you created in the first step. Save; commit

Notes:

All users that are not authenticated will receive the Unknown Users Policy.

Authentication failure withMS AD 2008 R2 when using windows 7/vista Client

Rudolf Kessler — Mon, 14 May 2012 02:17:31 GMT

This article applies to:

SWG 10.x
Windows Vista or Windows 7 clients

Symptoms:

Trying to configure authentication against Microsoft AD 2008 R2.
With Windows XP clients, authentication is successful when you disable NTLM V2 enforcement.
However with Windows 7 or Windows Vista clients, you see "Authentication failure" in the weblog viewer.

Causes:

This problem occurs because of an additional security check in Windows Server 2008 and Windows Vista.
This problem is limited to clients that use NTLMv2 authentication without extended security.

Resolution:

To resolve this issue , you can install and configure a Hotfix that Microsoft provides for this issue. See the following Microsoft Knowledge Base article:

http://support.microsoft.com/kb/957441

What is the policy assignment order?

Rudolf Kessler — Fri, 27 Apr 2012 00:41:00 GMT

Question
What is the policy assignment order for a User Group/User in Trustwave Secure Web Gateway appliance?

Answer

The policy assignment in Trustwave Secure Web Gateway appliance is as follows:

The Local Users are being evaluated according to their respective username IP address. Please note that the Local Users are referred to as Independent Users in version 9.x/10.x.
The Local Groups are being evaluated according to their set IP range.
The imported LDAP users, which are associated with their relevant LDAP groups are then evaluated.
The Unknown LDAP Users is then used, which may result due to unknown user which was imported to the SWG appliance as part of the LDAP objects, but is currently not associated with an LDAP group.
Lastly, if all the above are not relevant, the Unknown Users group is then used, which means users that are completely unrecognized by the system.

Software Version
9.x.x
10.x

This article applies to:: SWG 3000; SWG 5000; SWG 7000
This article was previously published as:: Finjan KB 1521

Allowing Office to retrieve content from Microsoft via SWG

Eric Hanson — Wed, 16 Jun 2010 12:28:00 GMT

Description:
An Identification Policy exception might be necessary on Secure Web Gateway (SWG) appliances in order to enable Office to download supplemental content from Microsoft.

Symptoms:
Although some clipart and templates are included with Office, much more is available as part of Microsoft’s online web collections. Users might find that they are unable to access this online content from within Office applications. When the administrator reviews the Web Log details that are related to these transactions, the following Identification Status is sometimes observed on the Policy Enforcement tab:

Error during authentication handshake

Cause:
Some Office installations have restrictions on proxy authentication. For example, most Office 2003 installations will not authenticate when a proxy is deployed transparently (including WCCP installations). This can prevent users from being able to retrieve supplemental Microsoft Office content.

Solution:
If users are unable to download supplemental Office content from Microsoft, please follow the steps below to add an exception to the SWG appliance’s Identification Policy. This procedure will work for built-in and custom Identification Policies in which the Exclude by Headers list serves as an exception condition. If using a custom Identification Policy that does not utilize this Header Fields list, please add it as a condition to the rule that performs authentication and select “Everything except for the items selected below” in the Applies to field.

Navigate to Policies -> Condition Settings -> Header Fields.
Select the Exclude by Headers list.
Click the Edit button.
Click the green + button to add a new list entry.
In the Header Name field, type:

Host
In the Condition field, select Regular Expression.
In the Header Value field, type:

.*office(images)?.microsoft.com

The entry should appear as it does in the screenshot below:
Click the Save button.
Commit the changes.

Please give the system ample time to finish committing before testing the change.

Software Versions:
9.x

Active Directory LDAP Username must be fully qualified in VSOS 9.2

support finjan — Wed, 01 Apr 2009 00:00:00 GMT

Description
Certain Active Directory LDAP settings that worked previously in VSOS 9.0, may require adjustment in VSOS 9.2.

Symptoms

When trying to import an Active Directory server, the import fails and displays an error message even though all fields are completed with the correct information.

The following error message is displayed:

Cause

A change in VSOS 9.2 allows user names to be input in different formats.

Solution

Because of this change, all user names are required to be input in a fully qualified format.

For example:

User@Domain.com
Domain\User
cn=user,cn=users,dc=domain,dc=com

Note: The user name format must be accepted by the Active Directory server.

Software Version
VSOS 9.2

This article applies to:: NG 1000; NG 5000; NG 6000; NG 8000

This article was previously published as:: Finjan KB 1879

Multiple Administrators - Technical Brief

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1388

Using Transparent Authentication Mechanism with FireFox

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Question
As a result of the new Transparent Authentication mechanism added in Vital Security software version 8.4.3, the browser allows the end-user to connect to the internet without sending requests for authentication from the end-user.

This authentication request arrives from the browser as a result of the HTTP 401 Unauthorized Response sent from the web-server.

If the authentication domain is resolvable as a hostname inside the orginization, the IE browser will forward authentication details automatically.
However, the FireFox browser will not do it automatically.

How can we enable this automatic option for FireFox so that it does not send repeated requests for authentication to the end-user?

Answer
In order to enable this automatic option for the FireFox browser, please do the following:
Open FireFox browser.
Type about:config in the FireFox address bar.
Select network.automatic-ntlm-auth.trusted-uris in the Filter bar.
Type in the virtual redirection hostname that you have defined for your Finjan appliance (e.g. vhost in the example below):

Virtual Redirection Hostname must be defined exactly as it is set for Finjan appliance:

VSOS
8.4.3

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1390

What are the supported configurations of an Authentication Device?

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Question
When configuring an authentication device with the Vital Security Web Appliance, what are the supported configurations of an authentication device?

Answer
The supported configurations are the following:

Software Version
8.5.0

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1590

How to install and configure ISA IP forwarding plug-in

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1282

SSL Authentication while using NG-5100 as a Next Proxy Server

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Description
When using an NG-5100 appliance as a next proxy for the NG-5400 SSL appliance, and using NTLM authentication on the NG-5100, all SSL traffic fails.

Symptoms
The SSL traffic fails when the NG-5400 is configured as next proxy to the NG-5100. When the NG-5400 routes directly to the internet (and not through NG-5100 as next proxy) the SSL traffic works correctly.

Cause
The NG-5100 tries to authenticate every session which passes through it. However, since the NG-5400 has no credentials to authenticate with which are compliant with NTLM authentication, the session fails and an error message is displayed to the user.

Solution
While using authentication, an NG-5400 SSL appliance, as well as the NG-5100 appliance, MUST have direct access to the Internet.

This article was previously published as:
Finjan KB 1268

Can a Lotus Notes client identify Windows Active Directory users, using Vital Security NG (NTLM authentication)?

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Question
Can a Lotus Notes client identify Windows Active Directory users using Vital Security NG (NTLM authentication)?

Answer
No, Lotus Notes does not support NTLM authentication.
Therefore it can't authenticate Active Directory users that were imported by the Vital Security NG proxy, using NTLM authentication.

There is an open feature request for IBM to add NTLM support to Lotus Notes.
Please refer to the following link for more information:
http://www-1.ibm.com/support/docview.wss?rs=474&uid=swg21190929

Software Version
8.3.0
8.3.5
8.4.0
8.4.3
8.5.0

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1260

Read Headers identification method description and usage

Amir Foox — Mon, 23 Mar 2009 00:00:00 GMT

Question
The Vital Security Web Appliance uses four different methods to identify and authenticate network users before allowing any web transaction:
1. Source IP.
2. Read Headers.
3. Get User Credentials.
4. Authentication.
This article describes and demonstrates the Read Headers method.
The "Read Headers" method was meant to be implemented in a topology which includes an additional proxy device that authenticates users on the network, such as a Microsoft ISA server, which is used as an example in the following scenario.

Answer
In the "Read Headers" identification method, the Vital Security Web Appliance relies on the downstream proxy to provide headers information in each transaction.
These headers would be used then to identify the username of the person who originated the transaction and/or the IP of the client machine from which the transaction originated.
The Vital Security Web Appliance can be configured to monitor specific headers, such as X-Authenticated-User for username and/or X-Client-IP for client IP address information. In this scenario, it is assumed that the information forwarded by the downstream proxy is valid.
The Vital Security Web Appliance does not attempt to verify the supplied data.
Please note that the Microsoft ISA server must be properly configured to forward this information to the Vital Security Web Appliance.
Vital Security IP forwarding plugin should be installed on the Micrsoft ISA server for this purpose (please review the below Finjan Vital Knowledge Base article on this topic: http://kb.finjan.com/article.asp?article=1282&p=4 ).
The plugin setup file can be downloaded from the below location:
http://download.finjan.com/products/ng/ipfwd/index.htm
See the below image to confirm that Vital Security ISA connector is configured properly to forward the necessary information through HTTP headers of each transaction:

The Vital Security Web Appliance should be then configured to use "Read Headers" identification policy:
This policy is designed to use one rule "Always Identify Users by Headers" :
This rule is set to "Identify by headers" action based on specific headers information:
The headers to be used by this rule are predefined in the below "Pre Authenticated Headers" list:
As mentioned above, assuming that the information (IP / username) forwarded by the downstream proxy is valid, it then would be properly logged for further usage in reports / log viewer.

Software Version
8.5.0

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1798

Using authentication retention in terminal server environments

Eric Hanson — Mon, 23 Mar 2009 00:00:00 GMT

Question
Can authentication retention be used in an environment with terminal servers?

Answer
Definitions
Authentication Rentention mechanisms allow a Vital Security Appliance to temporarily cache a user's name. This means that the user does not need to reauthenticate with each transaction, thereby improving performance.
Terminal servers are powerful computers that host multiple interactive sessions from different users simultaneously. Many organizations use Windows-based terminal server solutions, such as Microsoft's Terminal Services and similar offerings from Citrix. With these solutions, several users can simultaneously run individual Windows sessions on the same server. The applications within these sessions run on the server itself, rather than on the user's own client PC.
Answer Explanation
It is possible to use the Cookie authentication retention mechanism in terminal server environments. This method sends a temporary identification cookie to the browser, which works well on a multi-session system because cookies are not shared between sessions from different users.
The IP Caching authentication retention mechanism should not be used in terminal server environments. This method temporarily associates usernames with client IP addresses. In a terminal server environment, all transactions that originate from the terminal server will have the same client IP address. Since the terminal server can simultaneously host sessions from different users, a request from the IP address of the terminal server could have been made by any of the users on that server. Therfore, it is not possible to associate a specific transaction with a specific user by simply recognizing that the request came from the terminal server's IP.

Software Version
8.4.3
8.5.0
9.0

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1763

HTTP Error 553 due to Authentication Failure

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Description
After a new installation of VSOS 9.0, all users cannot browse to the Internet.

Symptoms
All users get HTTP Error 553 - Internal Server Error.
In the log viewer of the Management Console, you can see that the transactions failed at the authentication handshake phase:

Cause
In self-authentication / self-redirection authentication method, the scanners perform the authentication in front of the external authentication server (usually AD server).

In order to perform this kind of authentication, the scanners should be able to reach the external authentication server/s.
However, usually the domain controllers of the external authentication server are written in their relative / host name format, not in their FQDN (Fully Qualified Domain Name).

In case the organization's domain is not configured in the DNS settings of the Vital Security Web Appliance, the scanners will not be able to resolve the domain controller name, and the self-authentication will fail.

Solution
Define the organization's domain name in the DNS settings via the limited shell
Access via SSH to the limited shell of the policy server.
Type config_network -> Y -> choose option 4 (DNS) -> 1 (Change Search) -> Type your domain -> Q -> Y

Software Version
9.0

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1741

Internal Server Error while Working with an Authentication Device

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Description
An Authentication Device is used to authenticate users against an Authentication Server. When using a distributed setup including an Authentication Device, sometimes errors are received.

Symptoms
When an authentication redirect is requested via the same proxy that required the authentication you will receive the following error message:

Cause
The proxy client will not forward the Authentication Request to the Authentication Device since this authentication redirect is not authenticated either.

Solution
Make sure that the client or an intermediate proxy will forward the authentication redirect to the authentication device directly. This authentication redirects should not be forwarded via the same Finjan Proxy that required the authentication and issued the redirect itself.

Software Version
8.5.0

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1582