Operating tips

Topic 51123 | Release Notes | TRITON AP-WEB | 02-Feb-2015

Working in the TRITON Manager

Using reporting tools

Content Gateway

Working in the TRITON Manager

To improve your experience with the Web module of the TRITON Manager:

Disable all browser pop-up blocking features.

If you have problems accessing the console from Internet Explorer:

Make sure that Internet Explorer Enhanced Security Configuration (IE ESC) is disabled.

If problems continue, reset Internet Explorer to its default configuration. To do this, in Internet Explorer, go to Tools > Internet Options and select the Advanced tab, then click Reset. When prompted, click Reset again.

If this is your first experience with a Websense web protection solution, review the New Admin Quick Start tutorial (Help > Getting Started > New Admin Tutorial) for help getting started with policy management and reporting.

Avoid using the browser Back and Refresh buttons. Instead, use the breadcrumbs at the top of the page or the left and right navigation panes.

Click OK at the bottom of each page in the Web module of the TRITON Manager to cache changes made on the page.

In some instances, when you are performing secondary tasks, you must click OK on the secondary page, and then click OK again on the main page to cache your changes. Make sure you see the "Changes have been cached" success message.

Click Save and Deploy to implement cached changes.

It can take up to 30 seconds for all Websense components to be updated with the changes.

Using reporting tools

To improve your experience with your reporting tools:

If you install TRITON management components first, and then install Log Server, manually restart the Websense TRITON - Web Security service on the TRITON management server machine. This ensures that reporting data appears in the Web module of the TRITON Manager, and that presentation reports scheduled jobs are properly stored in the Log Database.

If you are using Internet Explorer 8, make sure that Compatibility View (the button between the URL and the Refresh button in the browser address bar) is turned off.

Content Gateway

The following details are provided to help improve your experience with Content Gateway.

Installation

Configuration

IWA support for load balanced environments

Proxy user authentication

SSL Internal Root CA

Installation

Content Gateway tolerates different software versions in the same cluster. This is intended to simplify the process of upgrading a cluster. You should not run a cluster containing different versions for a prolonged period of time (many days).

Configuration synchronization does not take place among nodes of different versions.

Condition alarms are passed among all nodes.

The VIP feature is supported.

Cache size should be restricted to 147 GB. This size provides optimal resource utilization while also providing an excellent end-user experience. Because today's Internet sites are often composed of dynamic, uncacheable content, caching is a less significant factor in the end user's web browsing experience.

Configuration

In explicit proxy deployments, send HTTPS traffic to port 8080

In explicit proxy deployments, when HTTPS (SSL support) is enabled, client browsers should be configured to send HTTPS traffic to proxy port 8080.

Accessing Intranet sites in an explicit proxy deployment

If your clients cannot access your Intranet sites, verify that your operating system has been correctly configured to resolve all internal and external hostnames. Use the nslookup command to verify that a domain is listed in your DNS server:

For internal-facing servers:

nslookup intranet.example.com

For external websites:

nslookup www.example.com

If your organization has multiple DNS domains, verify that a hostname in each domain resolves correctly. If you are unable to resolve hostnames, verify the contents of the /etc/resolv.conf file, which provides search rules for how domain names are resolved in DNS.

When Content Gateway is on a V-Series appliance, the domain of the hostname is automatically added to /etc/resolv.conf. For example, if the hostname of the appliance is vseries.example.com, then Content Gateway treats "intranet" requests as "intranet.example.com".

DNS proxy caching

The DNS proxy caching option allows Content Gateway to resolve DNS requests on behalf of clients. This option off-loads remote DNS servers and reduces response times for DNS lookups. You can use the DNS proxy caching option only with a layer 4 switch or a Cisco router running WCCP v2.

DNS proxy caching can only answer requests for A and CNAME DNS entries. Other types of request (e.g., MX) will not be answered.

Limitation: If the host name to IP address mapping is not in the DNS cache, Content Gateway contacts the DNS server specified in the /etc/resolv.conf file. Only the first entry in resolv.conf is used. This might not be the same DNS server for which the DNS request was originally intended.

See "DNS Proxy Caching" in Content Gateway Manager Help.

If your environment is configured such that you have DNS servers that resolve internal sites only and others that resolve external sites only, see Using the Split DNS option in Content Gateway Manager Help.

Using extended event logging

To investigate unexpected system behavior, it is sometimes helpful to enable the Log Transaction and Errors option (extended event logging) in Content Gateway Manager (Configure > Subsystems > Logging). However, extended event logging adds significant load to Content Gateway processes. Therefore you should not enable extended event logging when Content Gateway is at the high end of its processing capacity.

Reverse proxy

Content Gateway does not function as a reverse proxy.

IWA support for load balanced environments


	Important After upgrade to v8.0.0 check and, if necessary, rejoin IWA domains. If you customized your 7.8.2 or higher deployment to support an external load balancer with IWA user authentication (see the description, below), the configuration is preserved during upgrade to version 8.0.x. You do not need to re-apply the custom configuration. You should, however, test your deployment to verify that the load balancer is performing as expected.

With Websense Content Gateway, Integrated Windows Authentication (IWA) uses the Kerberos protocol, with NTLM fallback.

In an explicit proxy deployment with an external load balancer, because the clients point to a FQDN that does not match the Content Gateway hostname, they receive a Kerberos ticket that Content Gateway cannot decrypt.

Normally, Content Gateway would be configured to share the hostname of the load balancer, but this is not possible when the load balancer requires hostname resolution (as with DNS-based load balancing).

In these cases, Content Gateway must be configured to use a custom keytab that corresponds to the load balancer's hostname for decryption.

Samba's implementation of Kerberos prevents this, because it requires keytab entries to match the service's hostname.

Please see Configuring Integrated Windows Authentication with a load balancer in Content Gateway manager Help for more information.

Proxy user authentication

Client browser limitations

Not all Web browsers fully support transparent user authentication (prompt-less).

The following table indicates how a browser responds to an authentication request when Integrated Windows Authentication (IWA) is configured.


Browser/ Operating System	Internet Explorer (v10, 11 tested)	Firefox	Chrome	Opera	Safari
Windows	Performs transparent authentication	Performs transparent authentication (v28, 32 tested)	Performs transparent authentication (v34, 35, 38 tested)	Performs transparent authentication (v24 tested)	Falls back to NTLM and prompts for credentials (v5.34.57 tested)
Mac OS X	Not applicable	Performs transparent authentication (v28, 32 tested)	Falls back to NTLM and prompts for credentials (v38 tested)	Falls back to NTLM and prompts for credentials (v20 tested)	Performs transparent authentication (v7.0.2 tested)
Red Hat Enterprise Linux, update 6	Not applicable	Performs transparent authentication (v28 tested)	Browser issue prevents IWA from working (v34,35 tested)	Not tested	Not applicable

SSL Internal Root CA

It is strongly recommended that all instances of Content Gateway use the same Root CA, and that for best security the signature algorithm be SHA-2, although SHA-1 is supported.

The default Root CA (presented to clients) is signed with SHA-256.

The best practice is to replace the Websense default Root CA with your organization's Root CA signed by SHA-2 or stronger. See Internal Root CA in Content Gateway Help.

The Root CA should be imported into all affected clients.


	Note Client connections may fail (depending on specific browser behavior) if the client sees a certificate generated by an unknown Root CA.