Troubleshooting Authentication Problems

The following sections contain some problem situations that you may run into and suggestions on how to resolve them. You should also see Chapter 9 for more troubleshooting hints. The troubleshooting headings are numbered for easy reference.

8.18 This Gateway Does Not Support X

When trying to log in as a specific user, the following error might appear:

This Gateway Does Not Support X

The X represents an authentication scheme (SecurID, RADIUS, and so on). This error message occurs for one of two reasons:

8.19 The Connection Is Closed by a Session Authentication Agent

If you are using Session Authentication with a protocol that opens lots of connections (like HTTP), you will see this error in your logs. In these cases, it is advisable to use Client Authentication with fully automatic authentication instead of using Session Authentication by itself.

8.20 Authentication Services Are Unavailable. Connection Refused.

This message occurs in one of two situations:

Fix these situations, reload the policy, restart FireWall-1, and try again.

8.21 Session Authentication Is Not Secure

This message means that communication between the firewall and the Session Authentication agent is cleartext. The same thing goes for User Authentication for Telnet, FTP, HTTP, and rlogin and Client Authentication?the password is not encrypted. If you are concerned with passwords being sniffed over the wire, use an OTP scheme like S/Key or SecurID. This way, even if the password is captured over the wire, it will not be useful.

You can also enable encrypted Session Authentication. In fact, you can force it by enabling the "Accept only if connection is encrypted" option in the Session Authentication Action Properties screen (see Figure 8.35 earlier in the chapter).

8.22 Using Session Authentication with Content Security

FireWall-1 does not support this because User Authentication can be used for any service for which Content Security is available.

8.23 Authenticating on Each URL

If FireWall-1 is used for User Authentication and the firewall is not set as the proxy in the client browser, you will be asked to authenticate at each new Web site to access because the Web browser will not use the previous authentication information entered as each new site is accessed. In these situations, you should use Client Authentication with partially automatic authentication or use Session Authentication.

8.24 No Client Auth Rules Available

This error appears when a user attempts to authenticate and there is no Client Authentication rule that matches. The source IP address, user's group, and the user's allowed sources must match the rule. The user should not have a "blank" in the allowed source or destination section.

8.25 Policy Install Logs Out Client Authentication Users

A policy install flushes certain tables, of which the client_auth table is one. Although this is not generally recommended for security reasons, you can open $FWDIR/lib/table.def on the management console and modify the following entry:

client_auth = dynamic sync expires AUTH_TIMEOUT kbuf 3  \
                          expcall KFUNC_CLIENT_AUTH_EXPIRE;

keep needs to be added to this line after sync. It should read:

client_auth = dynamic sync keep expires AUTH_TIMEOUT kbuf 3  \
                          expcall KFUNC_CLIENT_AUTH_EXPIRE;

The keep prevents the client_auth table from being flushed on a policy install. You must reinstall the security policy in order for this change to take effect. The only way to flush this table is to bounce FireWall-1 (cprestart).

8.26 Partially Automatic Client Authentication Redirects Site to an IP Address

The HTTP Security Server needs to be instructed to use the HTTP host header instead of the IP address. To do that, perform the following commands in dbedit or make the appropriate change in the GUIdbedit tool:

dbedit> modify properties firewall_properties
               http_use_host_h_as_dst true
dbedit> update properties firewall_properties

See FAQ 4.2 in Chapter 4 for instructions on how to modify objects_5_0.C.

8.27 Users Are Not Being Prompted for Authentication

The likely reason for this problem is that one of the rules is less restrictive than the User Authentication rule actually matched. Long logging on all rules should allow you to discover which rule is the cause. Make this rule less restrictive, and/or reorder the rules to resolve this problem.

8.28 Request to Proxy Other Than Next Proxy Resource http://proxy.foo.com

This message is a result of trying to filter traffic going to a proxy server. You need to set the HTTP Next Proxy server and port as described in FAQ 8.6. You can go to only one proxy server per firewall because it is impossible to set more than one server in the Use Next Proxy setting.

8.29 Cannot Telnet to the Firewall

Sometimes while trying to Telnet to the firewall with User Authentication, you get the Check Point Telnet banner, you authenticate successfully, but then you lose the connection. If you are attempting to allow users to Telnet to the firewall for the purpose of proxy authentication, make sure prompt_for_destination is set to true in objects_5_0.C. If you want to allow people to Telnet to the firewall to log on to the firewall itself, you need to make sure that the Telnet daemon is running on the firewall box. Check /etc/inetd.conf to see if the Telnet daemon was commented out by FireWall-1 upon installation. If it was, uncomment it, and send the inetd process a hangup (HUP) signal.

WARNING!

It is not recommended that you allow users to Telnet to your firewall directly. For enhanced security, use an encrypted login mechanism like SSH.

8.30 When Accessing Certain Sites via HTTP, the Connections Are Dropped with Various Error Messages

Check Point's HTTP Security Server disallows some HTTP behaviors. As a result, some sites do not function when accessed through the HTTP Security Server. FAQ 9.9 gives some suggested settings for objects_5_0.C to eliminate these errors.

8.31 SecurID Authentication Fails after One Try

In this situation, SecurID authentication is set up, but after one successful authentication attempt, all future attempts fails. You might see the error message "[LOG_ERR] ACEAGENT: The message entry does not exist for message ID: 100x" when this occurs.

The ACE agent inside of FireWall-1 embeds a hash of its IP address in the authentication request packet before passing it to the ACE/Server. The ACE/Server will run a hash on the expected source IP of the ACE agent and compare it to the received hash. The ACE/Server uses the defined primary host agent IP to derive this hash. If the two hashes do not match, the authentication request is denied.

This method is problematic when an ACE agent is multihomed. The ACE agent may derive a hash from one of its other IP addresses. When this behavior occurs, it is necessary to create an sdopts.rec file in the /var/ace directory. The sdopts.rec file forces the ACE agent to use a specific IP address to derive its hash. Follow these steps.