|
|
|
|
Configuration Options > Security > Access Control
|
|
Updates the table to display the most up-to-date rules in the filter.config file.
|
|||
|
Opens the configuration file editor for the filter.config file.
|
|||
|
Lists the rules currently stored in filter.config. Select a rule to edit it. The buttons on the left of the box allow you to delete or move the selected rule up or down in the list.
|
|||
|
Select allow to allow particular URL requests to bypass authentication.
Select deny to deny requests for objects from specific destinations. When a request is denied, the client receives an access denied message.
Select keep_hdr to specify which client request header information you want to keep.
Select strip_hdr to specify which client request header information you want to strip.
Select add_hdr to cause a custom header to be added to the request. This rule type requires that values be defined for Custom Header and Header Value. Add custom headers to satisfy specific requirements of a destination domain. See Filtering Rules.
The radius rule type is not supported.
|
|||
|
dest_domain is a requested domain name.
dest_host is a requested host name.
dest_ip is a requested IP address.
url_regex is a regular expression to be found in a URL.
|
|||
|
Specifies the value of the Primary Destination Type. For example, if the Primary Destination Type is dest_ip, the value for this field might be 123.456.78.9.
|
|||
|
For use when the rule type is add_hdr. Specifies the custom header name that the destination domain expects to find in the request.
|
|||
|
For use when the rule type is add_hdr. Specifies the custom header value that the destination domain expects to be paired with the custom header.
|
|||
|
|||
|
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.
Important: When user authentication is rule-based with a domain list:
Important: 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.
|
|||||
|
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.
|
|||||
|
Note: The name and password are used only during the join and are not stored.
|
|
|
IMPORTANT: Once the domain is joined the hostname cannot be changed. If it is, IWA will immediately stop working until the domain is unjoined and then rejoined with the new hostname.
|
|
|
Specifies a password for the user identified in the Bind_DN field.
|
|
|
If you are using Active Directory 2008, you must include the netbios_name or use SMB port 445.
|
|
|
Note: When multiple domain controllers are specified, even if load balancing is disabled, when the load on the primary domain controller reaches the maximum number of connections allowed, new requests are sent to a secondary domain controller as a short-term failover provision, until such time that the primary domain controller can accept new connections.
|
|
|
If you have never configured rule-based authentication, see Rule-Based Authentication, for complete information.
|
|
Use the Edit button to change some attributes associated with the domain.
|
|
|
Use the New Domain button to add a domain to the Domains list. The screen is expanded to allow for specification of the domain.
|
|
|
New Domain action
|
|
|
Important: You cannot change the domain identifier after it has been added to the list. To change the name, delete the entry from the list and re-add it with the new name.
|
|
|
Important: You cannot change the authentication method after you add the domain to the list. To change the authentication method, delete the entry from the list and re-add the domain specifying the new authentication method.
|
|
|
Note: The name and password are used only during the join and are not stored.
|
|
|
Warning: Once the domain is joined the hostname cannot be changed. If it is, IWA will immediately stop working until the domain is unjoined and then rejoined with the new hostname.
|
|
|
Note: When multiple domain controllers are specified, even if load balancing is disabled, when the load on the primary domain controller reaches the maximum number of connections allowed, new requests are sent to a secondary domain controller as a short-term failover provision, until such time that the primary domain controller can accept new connections.
|
|
|
If you have never configured rule-based authentication, see Rule-Based Authentication, for complete information.
|
|
Updates the table to display the current rules in the auth_rules.config file.
|
|||||
|
Warning: Do not edit rules directly in the configuration file.
|
|||||
|
Specifies the inbound port for traffic when Content Gateway is deployed as an explicit proxy. If undefined, all ports match, as configured on Configure > Protocols > HTTP > General. Transparent proxy deployment should leave this field undefined.
|
|||||
|
Select a domain from the Domains drop down list (populated from the Domains List), and click Include to add it to the list.
Best practice: If you know what domain a set of users belongs to, create a rule just for that group.
Best practice: Place the rule with the largest number of users authenticating with known domain membership at the top of the list. These are the fastest authentications.
Best practice: If you don't know what domain a set of users belongs to, specify the fewest number of domains needed to authenticate the users in the set.
Best practice: It is always better to create targeted rules because attempting to authenticate against a large set of domains can introduce noticeable latency.
Important: When user authentication is rule-based with a domain list:
For Fail Open:
|
|||||
|
Click Enabled (7.8.3) or Enabled for HTTPS/HTTP Authentication page (beginning with 7.8.4) to redirect users to a customizable web portal page for authentication.
See Authentication using Captive Portal for details.
|
|||||
|
Important: If the rule specifies a regex for User-Agent, the regex is validated when Apply is clicked. If the regex is not valid, the rule is deleted and must be recreated.
|
|||||
|
|
|
|
|
Configuration Options > Security > Access Control
|
