Troubleshooting Multiple Realm Authentication

In multiple realm authentication, problems often present as:

Users are not challenged when a challenge is expected

Users are challenged when no challenge is expected

User authentication is performed against the wrong domain

These problems occur in one of the following phases of user authentication processing:

General user authentication logic (outlined below)

Realm rule definition and matching

User authentication protocol processing (IWA, NTLM, LDAP; for IWA troubleshooting, see Troubleshooting Integrated Windows Authentication.)

Multiple realm authentication logic

Multiple realm authentication always applies the following logic:

1.	The rules in filter.config are checked and applied. This action occurs as a first step in every type of Content Gateway user authentication. If a filtering rule is matched, the rule is applied and user authentication processing stops. See Filtering Rules.

2.

If no filtering rule matches, realm rule matching is performed. The requestor's IP address is checked, top-down, against the rule set. If the IP address matches a rule, the source port is checked, if the rule defines one. The first rule match is applied. If no rule matches, authentication is not attempted.

3.	If a rule is matched, the specified authentication protocol is applied against the specified domain. All rule configuration details are applied.

4.	If the user is authenticated, the request proceeds or is denied per Web Security policy.

5.	The transaction is logged.

To see how the logic is applied in a running environment, you can temporarily enable user authentication debug output. Among other details, the debug output shows the parsing of rules and matching. See Enabling and disabling user authentication debug output.

Troubleshooting

When multiple realm authentication doesn't produce the expected results, it is recommended that you troubleshoot the problem in the following order:

1.	Check Network Address Translation (NAT)

Confirm that there is no unexpected IP address NAT. Network address translation has the result that the original source IP address is changed to another address before user authentication is performed. In Content Gateway Manager, go to Configure > Networking > ARM > General and examine the rules in ipnat.config.

2.	Check the rules in filter.config

Confirm that there is no unexpected matching of a filter.config rule. Among other purposes, filter.config rules can be used to bypass user authentication. See Filtering Rules.

3.	Check realm rule matching

Using the IP address of a user who is or is not being challenged as expected, walk through each realm rule, top to bottom, examining the settings to find the first match. Be meticulous in your analysis. A common problem is that the IP address falls within a too-broad IP address range.

If the rule uses an alias, confirm that the alias is present in the User Service of the primary domain controller.

For explicit clients configured to send traffic to a specific port, check both the rule and the configuration of the client's browser.

4.	Check the domain

If you are getting the match you expect, verify that the domain is reachable and that the user is a member of the domain. If yes, troubleshoot the problem at the authentication protocol level. For IWA, see Troubleshooting Integrated Windows Authentication.

5.	When Content Gateway is in a proxy chain

If Content Gateway is a member of a proxy chain, verify that X-Forwarded-For headers are sent by the downstream proxy and read by Content Gateway.

Use a packet sniffer to inspect inbound packets from the downstream proxy. Look for properly formed X-Forwarded-For headers.

In Content Gateway Manager, go to Configure > My Proxy > Basic, scroll to the bottom of the page and verify that Read authentication from child proxy is enabled. If it's not, select On, click Apply, and then restart Content Gateway.

Enabling and disabling user authentication debug output

 

Warning  Debug output should not be left enabled. Debug output slows proxy performance and can fill the file system with log output.

Debug log information is written to: /opt/WCG/logs/content_gateway.out

To enable user authentication debug information, edit: /opt/WCG/config/records.config

(root)# vi /opt/WCG/config/records.config

Find and modify the following parameters and assign values as shown:

CONFIG proxy.config.diags.debug.enabled INT 1

CONFIG proxy.config.diags.debug.tags STRING
auth_* | winauth.* | ldap.* | ntlm.*

Save and close the file. Force Content Gateway to reread the file with the command:

(root)# /opt/WCG/bin/content_line -x

Follow the flow of debug information with the tail -f command:

(root)# tail -f /opt/WCG/logs/content_gateway.out

Use Ctrl+C to terminate the command.

When you have collected the debug output you want (after one or several user authentication processes is complete), disable debug output by editing records.config and modifying the parameter value as shown.

(root)# CONFIG proxy.config.diags.debug.enabled INT 0

Save and close the file. Force Content Gateway to reread the file with the command:

(root)# /opt/WCG/bin/content_line -x