Configure > Security > Access Control > Global Configuration Options

Use this page to specify global options for:

The fail open/fail closed action to take when user authentication fails
Credential caching
For transparent proxy, an alternate hostname for the proxy that all clients on the network can resolve. Required.
Cookie sharing

For more information, see Global authentication options.

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).

Global Configuration Options

Fail Open	Disabled – Prevents requests from proceeding to the Internet when an authentication failure occurs. Enabled only for critical service failures (default) – Allows requests to proceed if authentication fails because there is no response from the domain controller or because the client is sending badly formatted messages. Enabled for all authentication failures – Allows requests to proceed for all authentication failures, including password failures. When a fail open setting is enabled, if a Forcepoint Web Security transparent user identification agent is configured an attempt is made to identify the requester and apply user-based policy. Otherwise, if a policy has been assigned to the client’s IP address, that policy is applied. Otherwise, the Default policy is applied. Important: When user authentication is rule-based with a domain list: If Enabled only for critical service failures is selected, when a critical service failure occurs fail open is not applied. An error always results in fail closed. If Enabled for all authentication failures, including incorrect password is selected, after trying basic credentials with every domain in the list, fail open is applied. The Fail Open setting does not apply when IWA is the authentication method and the client fails to retrieve a kerberos ticket from the domain controller (DC) because the DC is down. The Fail Open setting does apply with IWA when IWA falls back to NTLM and authentication fails.
Credential Caching: Caching Method	Cache using IP address only – specifies that all credentials are cached with IP address surrogates. This is the recommended method when all clients have unique IP addresses. Cache using Cookies only – specifies that all credentials are cached with cookie surrogates. This is recommended when all clients share IP addresses, as with multi-host servers such as Citrix servers, or when traffic is NATed by a device that is forwarding traffic to Content Gateway. Cache using both IP addresses and Cookies – specifies to use cookie surrogates for the IP addresses listed in the cookie caching list, and to use IP address surrogates for all other IP addresses. This is recommended when the network has a mix of clients, some with unique IP addresses and some using multi- user hosts or that are subject to NATing. The cookie caching list is a comma separated list that can contain up to: 64 IPv4 addresses 32 IPv4 address ranges 24 IPv6 addresses 12 IPv6 address ranges For a description of surrogate credentials, see Surrogate credentials. Cookie mode caching does not work with applications that do not support cookies, or with browsers in which cookie support has been disabled. When the browser is Internet Explorer, the full proxy hostname in the form “http:// host.domain.com” must be added to the Local intranet zone. When the browser is Chrome, it must be configured to allow third-party cookies or configured for an exception to allow cookies from the proxy hostname in the form “host.domain.com”. When the IP address is set for cookie mode and the request method is CONNECT, no caching is performed. Cookie mode caching is not performed for FTP requests. Cookie mode caching is supported with Captive Portal and client certificate authentication. For explicit proxy, cookie-based authentication is not supported for HTTPS. IP-address authentication is used.
Credential Caching: Time-To-Live	Specifies the duration, in minutes, that an entry in the cache is retained. When the TTL expires, the entry is removed and the next time that the user submits a request, the user is authenticated. If the authentication succeeds, an entry is placed in the cache.
Cookie Expiration	Specifies whether a user is allowed to re-access the system without authentication until the cookie is no longer valid. When enabled, cookies expire when the user ends a session
Purge LDAP cache on authentication failure	Specifies that when an LDAP user authentication failure occurs, Content Gateway will delete the authorization record for that client from the LDAP cache.
Redirect Hostname	For transparent proxy, specifies an alternate hostname for the proxy that all clients on the network can resolve. Required. Valid characters for Redirect HostName are: A-Z, a-z,0-9 and - . For complete information see Redirect Options.
Cookie Sharing	When cookie caching is enabled, cookie surrogates can be shared across all nodes in a cluster. Select and import both private and public keys and then make a backup of them. Used with load balancing, the entry in Redirect Hostname must be the FQDN of the load balancer. Note: Cookie caching limitations also apply to cookie sharing. Therefore, since cookie caching is not supported for CONNECT requests, cookie sharing is not supported. Custom keys must be imported manually. Custom Keys are not synchronized across the cluster. Cookie sharing is not supported with client certificate authentication. Keys must be PKCS#1 RSA public keys. For more information, see Cookie Sharing.