New in Websense Content Gateway v7.8.1

Topic 60073 / Updated: 21-October-2013


Applies To:	Websense Content Gateway version 7.8.1 (a component of Web Security Gateway / Anywhere)

ThreatScope™

64-bit Content Gateway

SSL

User authentication

Range-based IP spoofing

Policy Broker resiliency

Filtering Service resiliency

Secured by RSA® authentication

FIPS 140-2 mode

Office 365

WCCP

Japanese language embedded Help

Removed: Support for the Microsoft ISA plugin

ThreatScope™

ThreatScope is a Websense-hosted sandbox that provides enhanced detection of 0-day threats.

Suspicious downloads that fit the Websense Security Labs profile are uploaded to a cloud-hosted sandbox for activation and analysis. ThreatScope observes the behavior of the payload and compiles an extensive report. If the file is found to be malicious, an alert message is sent to the Web Security administrator with information about the threat and links to the ThreatScope report and an Investigative Report generated from your log records. Websense updates the Master Database, ACE analytic databases, and other security components. The next time someone in the organization tries to access the site, they and the organization are protected.

ThreatScope is a premium option for Web Security Gateway Anywhere subscribers.

This feature is described in detail in the version 7.8.1 Web Security Release Notes.

64-bit Content Gateway

Content Gateway version 7.8.1 is now full 64-bit and is offered only as 64-bit.


	Important If you are planning to upgrade to version 7.8.1 and Content Gateway is currently hosted on any version of Red Hat Enterprise Linux 5-series, you must include an operating system upgrade to Red Hat Enterprise Linux 6-series to the Content Gateway upgrade process. Red Hat Enterprise Linux 6.3 or 6.4 is recommended. Web Security upgrade instructions start here.

Content Gateway is certified on:

Red Hat Enterprise Linux 6 series, 64-bit, Basic Server

Kernel version for 6.4: 2.6.32-358

Kernel version for 6.3: 2.6.32-279

V-Series appliances

Content Gateway is supported on:

Red Hat Enterprise Linux 6 series, 64-bit, Basic Server

Kernel version for 6.2: 2.6.32-220

Kernel version for 6.1: 2.6.32-131

Kernel version for 6.0: 2.6.32-71

The corresponding CentOS versions, including updates 3 and 4 (CentOS version numbers have a one-to-one correspondence with Red Hat Enterprise Linux version numbers)

Only kernels listed above are certified or supported. Visit www.redhat.com for kernel information. To display the kernel version installed on your system, enter the command:

/bin/uname -r

Websense, Inc. provides "best effort" support for the version of Red Hat Enterprise Linux and CentOS listed above. Under "best effort" support, Websense Technical Support makes a best effort to troubleshoot cases in standard fashion until the issue is deemed a Red Hat Enterprise Linux- or CentOS-specific issue, at which point you must contact Red Hat directly for assistance.

Websense recommends that the Red Hat Enterprise Linux version that will host Content Gateway be updated to the latest patch before running the version 7.8.1 Content Gateway installer.

Websense also recommends that Red Hat Enterprise Linux systems that host Content Gateway be registered with Red Hat Network and kept up-to-date with the latest security patches.


	Important You can update packages on your Red Hat Enterprise Linux installations and patch kernels if the underlying kernel upgrade does not change the kernel ABI.


	Important Content Gateway is designed to run on a dedicated machine and is not guaranteed to be compatible with other server applications installed on the same machine.

For a complete description of platform requirements, see Hardware requirements and Operating system and software requirements.

SSL

Support for SSL (HTTPS) decryption, analysis, and re-encryption has been re-engineered for version 7.8.1.

SSL support is now part of the core Content Gateway proxy.

Rearchitected support:

Increases connection capacity, boosting concurrent end-to-end SSL connections to a minimum of 10,000 on a V-Series V10000 G2 (10,000 inbound client to proxy; 10,000 outbound proxy to origin server*).

Improves real scaling, because connection capacity is limited only by memory capacity (and the Connection Management settings*).

Improves performance and stability. Asynchronous event, multiple thread architecture and improved caching and memory management improves stability and reduces latency.

*The total proxy concurrent connection limit (HTTP + HTTPS) is determined by the value of Throttling Net Connections (default 45,000) set in the Content Gateway manager on the Configure > Networking > Connection Management > Throttling page.

In addition to the high-level enhancements, SSL support:

Provides functional parity with past versions of SSL Manager, including the Certificate Verification Engine (CVE)

Provides near-parity in the UI presentation in Content Gateway manager. Some configuration options are no longer needed and have been removed (see Changes from past versions, below)

Participates in Content Gateway management clustering; the separate SSL clustering mechanism is removed

Adds support for the TLS v1.1 and v1.2 protocols; support is enabled/disabled with records.config variables; details below

Pre-installs the trusted Root CA tree used by Mozilla Firefox

What is SSL support?

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are the most common protocols for secure transmission of data on the Internet. They rely on data encryption and a system of trusted certificates issued by certificate authorities (CAs) that are recognized by clients and servers. SSL/TLS requests made in a browser are identified by the "https" string that leads the URL.

When the HTTPS protocol is enabled in the Content Gateway manager, HTTPS (SSL/TLS) traffic is decrypted, analyzed, and re-encrypted before it is sent to its destination. ACE real-time analytics are used to inspect content and protect against malicious and undesirable data flow, in the same way that ACE is applied to HTTP traffic.

SSL support:

Can be used with explicit and transparent proxy deployments

Can be configured to accept HTTPS traffic from multiple inbound ports (client to proxy)

Provides certificate handling and management features

Includes configurable certificate validation features

Includes robust decryption bypass features to simplify the process of maintaining compliance with government and corporate laws and policies, and to whitelist trusted sites and blacklist untrusted sites

Allows for customizable messages to users when there is a certificate verification failure or connection error

Support for TLSv1.1 and TLSv1.2

Version 7.8.1 supports TLSv1.1 and v1.2.

Enabling and disabling TLSv1.1 and/or v1.2 is done by changing the value of records.config variables.

Inbound support (client to proxy) is enabled by default.

Outbound support (proxy to origin server) is disabled by default.

To enable TLSv1.1 support on the proxy to origin server connection, set the following variable to 1. Set it to 0 to disable it (default). "client" in the variable name refers to Content Gateway's role in the connection (client to the origin server).

proxy.config.ssl.client.TLSv11 INT 1

To enable TLSv1.2 support on the proxy to origin server connection, set the following variable to 1. Set it to 0 to disable it (default). "client" in the variable name refers to Content Gateway's role in the connection (client to the origin server).

proxy.config.ssl.client.TLSv12 INT 1

To enable TLSv1.1 support on the client to proxy connection (enabled by default), set the following variable to 1. Set it to 0 to disable support. "server" in the variable name refers to Content Gateway's role in the connection (server to the client).

proxy.config.ssl.server.TLSv11 INT 1

To enable TLSv1.2 support on the client to proxy connection (enabled by default), set the following variable to 1. Set it to 0 to disable support. "server" in the variable name refers to Content Gateway's role in the connection.

proxy.config.ssl.server.TLSv12 INT 1

To set the value of a variable:

If Content Gateway is on a Websense appliance, use the Administration > Toolbox > Command Line Utility.

If Content Gateway is installed on a standalone server, edit /opt/WCG/config/records.config. To apply the changes, run the following command from the Content Gateway bin directory (/opt/WCG/bin/):

./content_line -x

Changes from past versions

Although SSL support is functionally unchanged from prior versions, users of past releases will be interested in this summary of infrastructure changes. For a description of how version 7.7.x SSL Manager configuration is handled by the upgrade process to version 7.8.1, see On upgrade, below.

The SSL Manager plug-in is removed.

The /opt/WCG/sxsuite directory and its contents are removed. Notably, this includes sxsuite/inbound*.log and outbound*.log.

Transaction logging is sent to extended.log or squid.log when the logging subsystem is configured for "Log Transactions and Errors" or "Log Transactions Only". Otherwise, logging is sent to content_gateway.out.

The SSL SQLite3 configuration database is renamed new_scip3.db and is located in /opt/WCG/config.

The code for customized Certificate Failure and Connect Error pages has been changed to improve security by including the session ID. If those pages are customized in your deployment (Configure > SSL > Customization), you will have to reapply your customizations.

The Default cipher setting uses all available ciphers except eNULL, the ADH suite, and the EXP suite. EXP suite is added to the exclusion set in version 7.8.1.

On the Certificate Validation configuration page, "Run external program on incidents" is removed.

Port 8071 is no longer used; there is no longer a separate server for SSL user interface configuration pages.

On the Configure > Protocols > HTTPS page, SSL Outbound Port is no longer needed and has been removed.

On the Configure > SSL > Decryption / Encryption Inbound and Outbound pages, Credential Forwarding and VIA Header are no longer needed and have been removed.

On upgrade

When you upgrade from version 7.7.x to 7.8.1, most of your SSL configuration settings are saved and applied to the upgraded version of Content Gateway.

It is very important that you read and follow the step-by-step upgrade instructions. Doing so helps ensure a smooth upgrade process and maximizes retention of data.

Please note the following details.

You can upgrade directly from Content Gateway version 7.7.0 and 7.7.3. Earlier versions must upgrade to 7.7.x before upgrading to 7.8.1.

The Certificate Authority Tree is retained (trusted Root CA tree).

Static entries in the Incident List are retained and added to the new Incident List .

CRL and OCSP revocation records are retained.

The 7.7.x SSL SQLite3 database is converted to a new database file.

Dynamic certificates are not retained. All other certificates are retained.

Customized error message pages are lost. Record your customizations in advance and be prepared to reapply them after upgrade.

If SSLv2 is enabled, the setting is retained on upgrade.

SSL inbound*.log and outbound*.log files are deleted. After upgrade, transaction logging is sent to extended.log or squid.log when the logging subsystem is configured for "Log Transactions and Errors" or "Log Transactions Only". Otherwise, logging is sent to content_gateway.out.

User authentication

Rule-based authentication

Credential caching


	Important If you are upgrading from version 7.7.x and your user authentication configuration includes Multiple Realm Authentication rules, the Rule-Based Authentication enhancements may impact your configuration. Please read the following sections carefully. You will want to review and adjust your user authentication configuration after the software upgrade is complete.

Rule-based authentication

Proxy user authentication now includes a more flexible, expanded, and reorganized rule-based model that supports rules for:

Multiple realms – A realm is a domain that doesn't share trust relationships with other domains and therefore its members must be authenticated by a domain controller within its domain.

Authentication with an ordered list of domains. This is valuable when a user's domain membership is unknown. When a list of domains is specified in a rule, authentication is attempted against each domain, in order, until authentication succeeds or the list is exhausted, in which case no authentication is performed. When authentication succeeds, the domain is cached and the list is not traversed in subsequent authentications. The authentication method (IWA, NTLM, LDAP) can vary by domain and is specified when a domain is added to the Domains list.

Rule match is based on:

Client IP address, and/or

Inbound proxy port (explicit proxy only), and/or

User-Agent value


	Note Support for use of a single authentication method for the entire deployment is unchanged. The proxy can be configured to perform Integrated Windows Authentication (IWA), Legacy NTLM, LDAP, or RADIUS authentication for all clients against a single domain or directory service. See Proxy user authentication.

Users of the pre-existing Multiple Realm Authentication feature should think of rule-based authentication as:

A rename and expansion of the Multiple Realm Authentication feature

The addition of support for ordered domain lists

A reorganization and simplification of how domains are specified for use in rules

A simplification of how credential caching is configured (see Credential caching)

Users of rule-based authentication should understand that the authentication method (IWA, Legacy NTLM, LDAP) has the same features, requirements, and limitations as the same method used standalone. Read the documentation for each authentication method in Content Gateway Help before specifying the method with a domain.

Rule-based authentication structure and logic

Structure:

A list of domains is created and maintained.

When a domain is added to the list, the authentication method is specified.

IWA, Legacy NTLM, and LDAP are supported. RADIUS is not supported.

Domains on the list can be specified in authentication rules.

The Domains list is created and maintained on the Configure > Security > Access Control > Domains tab.

The Domains list is stored in auth_domains.config.

Authentication rules match users (clients) based on:

Client IP address

Inbound proxy port (explicit proxy only)

User-Agent value

When a user matches a rule, authentication is performed against the specified domain or list of domains.

Authentication rules are defined on the Configure > Security > Access Control > Authentication Rules tab. Rules are stored in auth_rules.config.


	Note Credential caching configuration is performed on the Configure > Security > Access Control > Global Configuration Options tab. On that page you specify IP address caching, cookie caching, or both. The setting applies to both transparent proxy and explicit proxy traffic. When both IP address caching and cookie caching are specified, the IP addresses that cookie caching is applied to must be specified.

Logic:

One or more rules are defined for client/domain(s) pairs (Configure > Security > Access Control > Authentication Rules).

When a request for web content is received:

A top-down traversal of the rule list begins

The first match is applied

If the rule includes a list of domains, authentication proceeds as follows:

The proxy attempts to authenticate with the first domain using the method configured for that domain. For example, if the first domain is IWA, Content Gateway transparently negotiates with the browser for credentials.

If authentication fails and Content Gateway hasn't already challenged (prompted) for basic credentials, it then prompts for credentials.


	Important When Content Gateway is an explicit proxy and the first and second domains are IWA, there is no prompt for basic credentials when authentication with the first domain fails. Instead, Content Gateway uses the issued Kerberos ticket to attempt to authenticate against the second domain. When Content Gateway is a transparent proxy and the user is not a member of the first domain, the request for a Kerberos ticket fails because the client does not trust the FQDN sent with the request. The fallback to NTLM authentication also fails and the user is prompted for credentials.

Content Gateway then uses the basic credentials with each subsequent domain, starting with the second, proceeding sequentially until authentication succeeds or the list is exhausted.

Content Gateway then uses the basic credentials to attempt, again, to authenticate with the first domain.

If authentication fails with all domains, the proxy assumes that the user misentered their credentials, prompts again for basic credentials, and attempts to authenticate sequentially against the list.

If no rule matches, no authentication is attempted

Transactions are logged with the user name used by Filtering Service.

Proxy authentication statistics are collected and reported individually for each authentication method on the Monitor > Security pages.

Rule-based authentication configuration summary

If Content Gateway is an explicit proxy and you want to bring traffic in on multiple ports, specify the ports on the Configure > Protocol > HTTP tab.


	Important You must also configure your clients to use the correct port.

Configure Global authentication options (Configure > Security > Access Control > Global Authentication Options). See Credential caching.

Create a Domains list (Configure > Security > Access Control > Domains).

To specify a domain in a rule, it must be a member of the Domains list.

Active Directory domains used with IWA must be joined.

Create authentication rules (Configure > Security > Access Control > Authentication Rules).

5. Restart Content Gateway to make the new rules take effect.

For complete details, see Rule-Based Authentication in Content Gateway Help.

Rule-based authentication best practices

If you know the domain membership of a set of users, create a rule just for that group; do not combine that group with another group and use a list of domains.

Place the rule with the largest number of users authenticating with known domain membership at the top of the list.

If you don't know what domain a set of users belongs to, specify the smallest number of domains needed to authenticate the users in the set.

In a list of domains, if there is an IWA domain, make it first in the list.

If there is more than one IWA domain in a list, place the largest domains at the top of the list.

Note that users who are not joined to the first IWA domain in a list are prompted for credentials (basic authentication).

Note that if the first domain in the list is LDAP, every user who matches that rule is prompted for credentials. The credentials provided by the user are offered to each successive domain in the list.

On upgrade

Multiple realm rules are converted to the new rule-based format. It's important to review and verify the configuration.

The domain defined in each realm rule is added to the Domain list.

If it is a joined IWA domain, it remains joined.

After upgrade, review the Domain list and for every IWA domain, select and edit the entry to assign a unique Domain Identifier (this is not the domain name but rather an internal identifier used by Content Gateway; a name is automatically assigned to other domain/directory service types).

A functionally equivalent rule is created.

After upgrade, review the Authentication Rules list and verify that the:

Rules are in the correct order

Every rule has the correct specifications

If Cookie Mode Caching is specified in the multiple realm rule, the specified IP addresses are moved to the cookie caching list in the Caching Methods section of the Global Authentication Option page. Cache using Cookies only or Cache using both IP Addresses and Cookies should be enabled.

If Content Gateway is a transparent proxy, the v7.7.x Authentication Mode setting (IP address or Cookie mode) is retained from Transparent Proxy Authentication tab.

Credential caching

User authentication credential caching has been simplified and enhanced.

There is now one credential cache for both explicit and transparent proxy mode and one, global configuration for setting the caching method and Time-To-Live.

The redesigned Global Authentication Options page hosts:

The authentication Fail Open setting – This option is unchanged from previous releases.

Credential Caching options – These settings are global and apply to explicit and transparent proxy traffic.

Settings include:

Caching Method

Cache Time-To-Live, in minutes

LDAP purge cache on authentication failure

Redirect Hostname (transparent proxy only) – This option is unchanged from prior versions.

Credential caching options apply to all clients whether Content Gateway is an explicit or transparent proxy. Settings support:

Caching using IP address only – Recommended when all clients have a unique IP address.

Caching using Cookie mode only – Recommended when all clients share IP addresses, as with multi-user hosts such as Citrix servers, or when traffic is NATed in a proxy chain or by a firewall.

Caching using both IP address and cookie mode – Recommended when the network has a mix of clients, some with unique IP addresses and some not. In this mode, cookie mode is used with specified IP addresses and ranges, the remainder are cached by IP address.


	Note The user interface setting to disable the NTLM cache for explicit proxy has been removed. Although not recommended, the cache can be disabled for explicit proxy traffic in records.config by setting the value of proxy.config.ntlm.cache.enabled to 0 (zero). When upgrading from v7.7.x to 7.8.1, if NTLM caching is disabled, it remains disabled.

Credential caching applies to:

NTLM authentication when Integrated Windows Authentication (IWA) falls back to NTLM

Legacy NTLM


	Note When IWA authenticates with Kerberos, Kerberos handles ticket caching (equivalent of credential caching).

The LDAP purge cache on authentication failure causes the proxy to delete the authorization entry for the client from the LDAP cache if the LDAP user authorization fails.

The 7.8.1 Global Authentication Option screen:


	Note The Transparent Proxy Authentication page has been removed.

On upgrade

The credential caching Enabled/Disabled setting for explicit proxy is retained from the v7.7.x Global Authentication Options tab. Caching for transparent proxy traffic is always enabled.

The Authentication Mode setting (IP address or Cookie mode) is retained from the Transparent Proxy Authentication tab.

The Cache TTL value is retained from Transparent Proxy Authentication tab unless the value on the Global Authentication Options tab is not the default, in which case the customized value is used. The cache TTL value is in minutes.

IP addresses and ranges on the Global Authentication Options Multi-user IP Exclusions list are moved to the cookie cache IP address list.

If Cookie Mode Caching is enabled in a multiple realm rule, the source IP addresses from that rule are copied to the cookie cache IP address list.

Range-based IP spoofing

IP Spoofing is extended to support groupings of clients (IP addresses and IP address ranges) that are mapped to specified IP addresses for spoofing. This is called range-based IP spoofing.

Among other scenarios, range-based IP spoofing supports:

Website service differentiation by IP address. For example, to receive a web-hosted service, an organization might identify membership to the service via a shared IP address.

IP address-based authentication with an external service when a unique IP address represents a group of users.

A way to configure traditional IP spoofing for some clients (source IP addresses that don't match any group are spoofed with their own IP address), range-based IP spoofing for some clients, and standard proxy IP address substitution for some clients. The latter is done by creating a group that specifies the proxy IP address.

About IP Spoofing

IP Spoofing is supported with transparent proxy deployments only.

IP spoofing configures the proxy to use either the IP address of the client or a specified IP address (range-based IP spoofing) instead of the proxy IP address when communicating with the origin server. As a result, requests appear to come from the client or the specified IP address instead of the proxy.

IP spoofing is supported for HTTP and HTTPS traffic. When IP spoofing is enabled, it is applied to both protocols. It cannot be configured to apply to only one.

IP spoofing requires special return traffic routing configuration for all HTTP/S traffic (80 and 443) to deliver spoofed traffic back to the proxy for processing.

IP Spoofing does not support IPv6.

Range-based IP Spoofing is not supported on many older versions of Cisco IOS firmware. Update your Cisco device to the latest firmware.


	Warning Deploying IP spoofing requires precise control of the routing paths on your network, overriding the normal routing process for traffic running on TCP ports 80 and 443. With IP spoofing enabled, traditional debugging tools such as traceroute and ping have limited utility.

For complete information, see IP Spoofing in Content Gateway Help.

Policy Broker resiliency

Content Gateway receives several sets of important data from Web Security Policy Broker. One set of data includes the Web Security Scanning Options settings, including analytics settings, scanning exceptions, and SSL decryption bypass settings. In past releases, Content Gateway stored this information in memory only. If Policy Broker was unavailable when Content Gateway started or restarted, the Scanning Options settings could not be loaded or applied.

Content Gateway has been enhanced to keep a configuration file of Policy Broker data, including the Scanning Options settings. If Policy Broker becomes unavailable, Content Gateway continues to apply the most recent settings. If Content Gateway restarts and Policy Broker is unavailable, Content Gateway loads the locally stored settings until the connection with Policy Broker is restored and updates can be received. Whenever Policy Broker becomes unavailable after Content Gateway has started, an alarm is generated to inform the administrator.

If after Content Gateway is installed and started for the first time Policy Broker is not available, there are no pre-existing settings to load. An Alarm is generated to alert the administrator of the condition.

Filtering Service resiliency

Content Gateway works with Web Security Filtering Service to perform policy enforcement. If Filtering Service becomes unavailable, there can be substantial latency in traffic handling.

Content Gateway has been tuned to provide better performance when requests to Web Security Filtering Service timeout and when Filtering Service becomes unavailable.

Every request that Content Gateway sends to Filtering Service must be completed within the communication timeout period. If it is not, the request is either permitted or blocked based on the Action for Communication Errors setting on the Configure > My Proxy > Subscription > Scanning page. When a communication timeout occurs, a dedicated monitor process continues to test the connection. If it fails 5 consecutive times, Filtering Service is marked down and the communication errors setting is applied until the monitor process detects that Filtering Service is responding.

Secured by RSA® authentication

TRITON Unified Security Center has been extended to support Secured by RSA authentication for TRITON administrators. See the v7.8.1 Release Notes for TRITON Unified Security Center.

Secured by RSA is a form of two-factor authentication that:

Is configured for and applies to the TRITON Unified Security Center logon.

Can be made to apply to Content Gateway Manager by forcing administrators to log on to the TRITON console before accessing the Content Gateway manager through the Web Security manager.

Requires single sign-on (direct access) to be configured in Web Security manager for administrators allowed access to the Content Gateway manager.

Requires that the Content Gateway manager password logon capability be disabled to prevent administrators not configured for single sign-on from accessing the Content Gateway manager directly via its IP address. See Configuring Content Gateway for two-factor authentication in Content Gateway Manager Help. If Content Gateway is deployed on an appliance, password access is disabled with an appliance manager command. See Configuring two-factor authentication in V-Series Appliance Manager Help.

For information about configuring two-factor authentication in the TRITON console, see Logging on with RSA SecurID authentication in TRITON console Help.

FIPS 140-2 mode

The openssl library used in FIPS 140-2 mode has been updated to 1.0.1e from 0.9.8r.

All of the cryptographic libraries used in Content Gateway version 7.8.1 have been submitted to the Cryptographic Module Validation Program (CMVP) for FIPS 140-2 certification. Visit the CMVP validation page for more information.

When Content Gateway is in FIPS 140-2 mode, cryptography within Content Gateway and on the HTTPS channel from the client to the proxy and from the proxy to the origin server, is performed with algorithms that conform to the FIPS 140-2 standard. However, where Content Gateway interfaces with some other Websense components there can be a FIPS 140-2 boundary.

In Web Security Gateway Anywhere, traffic that flows through the cloud does not use FIPS 140-2.

ThreatScope traffic does not use FIPS 140-2.

Websense Data Security does not use FIPS 140-2.

TRITON Mobile Security does not use FIPS 140-2.

When RSA SecurID is configured for the TRITON console logon, the connection to RSA SecurID is not FIPS 140-2.


	Important Due to a system limitation, FIPS 140-2 mode cannot be used with NTLM user authentication (IWA fallback to NTLM or Legacy NTLM).

For more information about FIPS 140-2 mode in Content Gateway, see FIPS 140-2 Mode.

Office 365

Support for cloud-hosted and on-premises Microsoft Office 365.

When there is access to the Microsoft cloud, documents are synchronized with Microsoft Office 365 in the cloud. When there is no access to the cloud, Microsoft Office 365 applications are available locally.

On-premises support includes:

Access in explicit and transparent SSL proxy deployments

SSL decryption bypass

Integrated Windows Authentication (IWA) and Legacy NTLM user authentication

Integration with WebDLP and outbound Data Security (with Web Security Gateway Anywhere)

On-premises Office 365 application support includes:

SkyDrive and Sharepoint:

Open file from Word/Excel/PowerPoint/OneNote/Publisher/Access

Save file from Word/Excel/PowerPoint/OneNote/Publisher/Access

Outlook:Share document through email

SkyDrive Pro: Verify synchronization from cloud to local host

Upload files through Office Upload Center

Lync Online

Cloud-hosted support includes:

Access in explicit and transparent SSL proxy deployments

SSL decryption bypass

Integrated Windows Authentication (IWA) and Legacy NTLM user authentication

Integration with WebDLP and outbound Data Security (with Web Security Gateway Anywhere)

Cloud hosted Office 365 application support includes:

Create directory

Create, Open, Edit, Save: Word/Excel/PowerPoint/OneNote

WCCP

Synchronize in the Cluster

When several instances of Content Gateway are deployed in a cluster, use the Synchronize in the Cluster option to control whether the WCCP configuration is propagated around the cluster. (The value of Synchronize in the Cluster is always synchronized in the cluster.)

When this option is enabled, the WCCP configuration (stored in wccp.config) is synchronized in the cluster and configuration changes can be made on any node.

When this option is disabled, the WCCP configuration is not synchronized in the cluster and changes to the WCCP configuration must be made individually on each node. A common use case for this is to control which service groups are enabled/disabled on each node, and to use proportional load distribution with weight. An efficient way to set up WCCP in this scenario might be to enable Synchronize in the Cluster while establishing the basic WCCP configuration, and then disable it when you're ready to control service group enable/disable (or other WCCP configuration values) on each node.

If after being disabled this option is enabled, the configuration of the node on which it is enabled is used to synchronize all members of the cluster.

Use this option with caution: When Synchronize in the Cluster is disabled, you must visit each node in the cluster to examine and maintain your WCCP configuration. In addition to the added maintenance burden, it can make WCCP troubleshooting more difficult.

Lifts 7.7.x limits

When Synchronize in the Cluster is set to Disabled it effectively eliminates a limitation in which you cannot configure the following service group attributes separately for each node in the cluster:

Service group Status enabled/disabled

Service group Network Interface value (eth#)

Service group Weight (Advanced setting)

Japanese language embedded Help

Japanese language embedded Help is included in version 7.8.1. To select Japanese, go to Configure > My Proxy > UI Setup > General, locate the Default Help Language drop down list and select Japanese (the selection is presented in Japanese). The setting does not apply to all nodes in a cluster. Each node must be configured separately.

The setting does not apply to any TRITON manager embedded Help language options.

Performance graphs

Two new Content Gateway performance graphs that monitor DNS activity. In the Content Gateway manager go to Monitor > Performance > Overview.

DNS Lookup Latency shows the average time in milliseconds to fulfill a DNS request.

DNS Cache Usage shows the number of DNS requests handled by Content Gateway, including those served by the DNS cache.

Removed: Support for the Microsoft ISA plugin

With the transition to 64-bit Content Gateway, support for 32-bit Microsoft ISA server in a proxy chain is deprecated.

Content Gateway continues to support 64-bit Microsoft Forefront TMG.

For more information, see Chaining Content Gateway with other proxies.