Rule-Based Authentication

Help | Content Gateway | Version 8.1.x

Related topics:

Global authentication options

Rule-based authentication Domain list

Creating an authentication rule

Working with existing authentication rules

Rule-based authentication use cases

Authentication based on User-Agent

Authentication using Captive Portal

Troubleshooting authentication rules

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:

How to match a user.

By:

IP address

Inbound proxy port (explicit proxy only)

User-Agent value

A combination of the above

The domain or ordered list of domains to authenticate against.

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.

Whether a customizable web portal page should be used for authentication.

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:

Members of the realm (untrusted domain) by IP address or proxy port

The realm (domain) they belong to

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 If all the users in your network can be authenticated by domain controllers that share trust relationships, you probably don't need rule-based authentication. However, the option is well suited to single domain environments that may benefit from multiple rules based on IP addresses, inbound proxy port (explicit proxy), and/or User-Agent values.

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, 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 identify users (clients) by IP address, inbound proxy port (explicit proxy only), and/or User-Agent values, and attempt to authenticate the user against a specified domain or list of domains.

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

When a request for web content is received:

A top-down rule list traversal 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 (407 or 401).

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

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.

Content Gateway then uses the basic credentials with each 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 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.

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. See Security (in the Statistics section).


	Important Content Gateway must be configured with a DNS server that can resolve the fully qualified domain name (FQDN) of Content Gateway for every realm used by IWA. If this isn't done, IWA fails to work. How to configure the DNS server is up to the network administrator. One option is to configure a DNS transfer zone (Sub Zone) between the primary DNS server of Content Gateway and the DNS server of each authentication realm (isolated domain).

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

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

To specify a domain in a rule, it must be a member of the Domain List.

Active Directory domains used with IWA must be joined.

Handling of unknown users:


	Important In rule-based authentication, Content Gateway may authenticate users that are outside the User Service primary domain. In these cases, Content Gateway can be configured to send an "alias" user name that User Service knows about. Or, you can send no name, in which case standard Filtering Service precedence is applied to determine the correct policy. (See Enforcement order in Administrator Help for the Web module.) This specification is made for each domain in the Domain list. For more information, see Unknown users and the 'alias' option, below.

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

If you don't need rules, don't use rule-based authentication. Deploying a single authentication method should provide the best performance.

Use the fewest number of rules needed to satisfy your requirements.

Do not use a domain list in a rule if it's not needed.

When a domain list is used

If there is an IWA or NTLM domain, make it first in the list.

If there is more than one IWA or NTLM domain, place the domain with the most active members first in the list. In other words, make the first domain the one that will most often authenticate users.

Note that if an IWA domain is first in the list and the user is not joined to that domain, the user will be prompted for credentials.

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

If the domain list includes an IWA domain, the Captive Portal option is disabled.