Go to the table of contents Go to the previous page Go to the next page View or print as PDF
Rule-Based Authentication
Help | Content Gateway | v8.5.x
 
Related topics:
Using an ordered list of authentication rules, rule-based authentication provides support for multiple realm, multiple domain, and other special authentication requirements. When a request is processed, the rule list is traversed top to bottom, and the first match is applied.
Authentication rules specify:
1.
By:
*
*
*
*
2.
With a list of domains, the first successful authentication is cached and used in subsequent authentications. If IP address caching is configured, the IP address is cached. If Cookie Mode is configured, the cookie (user) is cached.
3.
In rule-based authentication, only the first matching rule is tried. If authentication is unsuccessful, no further authentication is attempted.
Rule-based authentication is designed to meet these special requirements:
*
Multiple realm networks: Rule-based authentication supports multiple realm networks in which domains do not share trust relationships and therefore require that each domain's members be authenticated by a domain controller within their domain. In this environment rules are created that specify:
*
*
 
*
Authentication when domain membership is unknown: Some organizations do not always know what domain a user belongs to. For example, this can happen when organizations acquire new businesses and directory services are not mapped or consolidated. The unknown domain membership problem can be handled in rule-based authentication by creating a rule for IP address lists or ranges that specifies an ordered list of domains to attempt to authenticate against. The first successful authentication is remembered and used in later authentications. If authentication is not successful or the browser times out, no authentication is performed.
*
Authentication based on User-Agent value: One or more User-Agent value can be specified in an authentication rule. Often this is a list of browsers. When the User-Agent value matches a rule, authentication is performed against the specified domain(s). If the User-Agent value doesn't match any rule and no rule matches based on other values, no authentication is performed (this is always true in rule-based authentication; if no rule matches, no authentication is performed).
For use case examples see Rule-based authentication use cases.
 
Note 
Rule-based authentication structure and logic
Structure:
*
When a domain is added to the list, the authentication method is specified: IWA, Legacy NTLM, or LDAP. RADIUS is not supported.
Only domains on the domain list can be specified in authentication rules.
The domain list is created and maintained on the Configure > Security > Access Control > Domains tab. The domain list is stored in the auth_domains.config file.
*
Authentication rules are defined on the Configure > Security > Access Control > Authentication Rules tab. Rules are stored in the auth_rules.config file.
 
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.
See Credential Caching for more information.
Logic:
*
One or more rules are defined for clients and domains (Configure > Security > Access Control > Authentication Rules).
*
*
*
*
*
*
Exception: When Content Gateway is an explicit proxy, the first and second domains are IWA, and the client has a ticket from the authentication domain, there is no prompt for basic credentials. Instead, Content Gateway uses the Kerberos ticket provided by the client to attempt to authenticate with the second domain. If the attempt fails and the fallback to NTLM authentication fails, the user is prompted for credentials.
When Content Gateway is a transparent proxy the standard behavior applies. This is because when 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.
*
*
*
If authentication fails with all domains and the Fail Open (Configuration > Security > Access Control > Global Authentication Options) setting is:
Enabled only for critical service failures, the proxy assumes that the user mis-entered their credentials, prompts again for basic credentials, and attempts, again, to authenticate sequentially against the list.
Enabled for all authentication failures, including incorrect password, fail open is applied.
*
*
*
 
Important 
Rule-based authentication configuration summary
1.
 
Important 
2.
Configure Global authentication options (Configure > Security > Access Control > Global Authentication Options).
3.
Create a domain list (Configure > Security > Access Control > Domains).
*
*
Handling of unknown users:
 
Important 
4.
Create authentication rules (Configure > Security > Access Control > Authentication Rules).
5. Restart Content Gateway to make the new rules take effect.
Rule-based authentication best practices
*
*
*
When a domain list is used
*
*
*
*
*
With v8.5.4, the Captive Portal option is enabled.
*
If client certificate authentication is enabled with Use the next selected authentication method if Client Certificate authentication fails option selected, the domain list cannot be empty.

Go to the table of contents Go to the previous page Go to the next page View or print as PDF
Copyright 2020 Forcepoint. All rights reserved.