> Source: [sk41222](https://support.checkpoint.com/results/sk/sk41222)

# sk41222 - FireWall-1 support for RADIUS, SecurID, AssureNet and ActiveCard authentication using RADIUS

| Property | Value |
|----------|-------|
| Solution ID | sk41222 |
| Date Created | 2009-04-19 |
| Last Modified | 2016-03-20 |
| Technical Level | General |
| Products | Security Gateway |
| Versions | R82.10, R82, R81.20 |

## Solution

IPSO does not support Axent Pathways Defender authentication except via RADIUS authentication. All other authentication mechanisms are explained below. To use either RADIUS, SecurID, ActiveCard or AssureNet authentication, the configuration steps (covered in the Check Point documentation) are:

1. The FireWall-1 User Database would use the generic\* user definition to represent all authentication attempts. This user definition would use either the RADIUS or SecurID method of authentication.  

2. If the generic\* user's Authentication Method is RADIUS:  

   * The Radius server is defined under the �Manage-\>Servers and OPSEC Applications� pull down menu in the FireWall-1 Security Policy Editor.  

   * A user defined in the RADIUS database would have to be configured to use an Auth-Type of SecurID or AssureNet. Good information about Radius is available from Livingston Enterprises.  

If the generic\* user's Authentication Method is SecurID:

1. **WARNING:** If you are planning to use SecurID with the NG Feature Pack 1 or 2 release on IPSO, you cannot use native SecurID mode to communicate with the SecurID server. The ACE server also provides a RADIUS front-end, which must be enabled. You then configure FireWall-1 as if it were talking to a RADIUS server instead of a SecurID server. Native SecurID support is available in NG FP3 and later.
2. The sdconf.rec file from the SecurID's ACE server must be copied into /var/ace (which must be created) on VPN-1/FW-1 Gateway. FireWall-1 must be restarted (*fwstop;fwstart*). Follow the instructions that come with the ACE server.

<br />

An ACE server may be configured to interact with both DES and SDI ACE Clients.

The default encryption for the ACE Server is DES, which they are able to export outside of the US and Canada. In order to support clients using SDI encryption, such as FireWall-1 (FWZ), the ACE server must be configured to use SDI for sole purpose of creating a sdconf.rec file for the FireWall-1 (FWZ) system.   
You should rename the *sdconf.rec* created in the *%ACE_ROOT%\\data* directory to sdconf.sdi.rec. You then must set the ACE server back to DES, which will create a new sdconf.rec file. You now have two *sdconf.rec* files and then may interact with DES and SDI clients.

* It is important that the ACE server itself can resolve proper hostnames to all the IP addresses of the firewall. Authentication has been known to fail because of this.  

* There is only ONE way to properly define an ACE client in the ACE Server database relative to the IP address and the Secondary Nodes descriptions.The IP address in the ACE client definition must be the primary IP address of the firewall. (The primary IP address is that which the system name resolves to. This is set in the Host Address Assignment page in Voyager.)The Secondary Nodes are the other IP addresses assigned to the firewall's network interfaces. **If you set this up any other way, the ACE server will log that the password is incorrect. Do not define any VRRP v2 or Monitored Circuit IP addresses as Secondary Nodes.**   

* In a case where a Lucent Technologies product was used as a SecurID server, there is no concept of secondary nodes.It was necessary, then, to go back to Host Address Assignment in Voyager and associate the system name of the firewall with the IP address that the SecurID server sees in the source field of the packet header in packets coming from the firewall.  

* FireWall-1 works with an ACE server in Native Mode. However, in ACE Server 5.0 or later, you must configure FireWall-1 nodes as "legacy mode" clients, i.e. a primary and secondaryACE server must be explicitly defined for these clients. If you fail to do this, SecurID authentication will fail. (See below under Known Problems)
* Make sure that you do not apply Network Address Translation rules to the IP addresses of the firewall or the internal ACE server may see a request coming from an IP address that is not defined as a client.

A user defined in the ACE server database who is in New PIN mode will likely require three authentication attempts to change the current PIN to a new user-defined PIN. Look at the Authentication window carefully.  

Be careful with the rules in your security policy. If the network connection you are authenticating is HTTP, make sure you look at the Action field Properties. Use your right mouse button to display the menu for this field. Select Properties at the top of the menu. You have a choice between Predefined HTTP Servers and All HTTP Servers:   

* Predefined Servers - Use this if you are authenticating external HTTP access to your own internal WWW servers. You must explicitly define these servers in the Properties -\> Servers window.
* AllServers - Use this if you are authenticating internal HTTP access to the Internet.

You may find that you have to explicitly allow services of type SecurID to pass between the firewall and the ACE server.  

For VRRP or IP Cluster, avoid using the cluster IP address by adding the following entry to *$FWDIR/lib/table.def* file on the SmartCenter Server:   

*no_hide_services_ports = {.., \<service_port, IP_protocol\> };*

For example for RSA traffic this entry should look like

*no_hide_services_ports = {.., \<5500, 17\> };*

where 5500 is a service port number and 17 means UDP

**WARNING:** When Security Management Server is upgraded, the changes made to the table.def file will be lost.

**Note:** A FireWall-1 log entry with an Info field that includes "Not allowed by Rule Base" is an indication that the HTTP connection is not going to an allowed destination. Either you have not correctly selected All Servers, or you have correctly select Predefined Servers, but the server is not yet defined.  

A FireWall-1 log entry with an Info field that includes "Access Denied by SecurID" is an indication that authentication has failed, but it will also be displayed following the "Not allowed by Rule Base" message, so it is not used consistently.

Known Problems
--------------

<br />

**Config steps for RSA Ace Server version 5.0.1**   

When running into problems configuring SecureID authentication, always test with RADIUS authentication to confirm the firewall can talk to the ACE server.

<br />

* The 'Agent host' name should be DNS resolvable.
* The *sdconf.rec* is usually generated following these steps: Agent host -\> Generate Configuration File
* In order for FireWall-1 to work with RSA Ace Server version 5.0.1, follow these additional steps:   

  * In "RSA Database Administrator" application menu, select "Agent Host-\>Edit Agent Host"
  * Once on that menu:   
    * Select "Double click on the FireWall-1 host name and click on the "Assign Acting Servers".
    * In the "Master:" selection list, choose the ACE/Server hostname.
    * Click on "Generate Config File .." button and save the "*sdconf.rec* " to a file.   
      Make sure the sdconf.rec file that is generated is an older build and not 5.0.
    * Place the "*sdconf.rec* " file on the FireWall-1 machine in */var/ace*.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content