Working with Authentication

Authentication Schemes

Authentication schemes employ user names and passwords to identify valid users.

Some schemes are maintained locally, storing user names and passwords on the VSX GatewayClosed Physical server that hosts VSX virtual networks, including all Virtual Devices that provide the functionality of physical network devices. It holds at least one Virtual System, which is called VS0., while others store authentication information on an external authentication server.

Some schemes, such as SecurID, are based on providing a one-time password.

For more information, see the R81.10 Security Management Administration Guide > Section Configuring Authentication Methods for Users.

Check Point password is a static password that is configured in SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on.. For administrators, the password is stored in the local database on the Security Management ServerClosed Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server.. For users, it is stored on the local database on the Security GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources.. No additional software is required.

OS Password is stored on the operating system of the computer on which the Security Gateway(for users) or Security Management ServerClosed Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server. (for administrators) is installed. You can also use passwords that are stored in a Windows domain. No additional software is required.

Remote Authentication Dial-In User Service (RADIUS) is an external authentication method that provides security and scalability by separating the authentication function from the access server.

Using RADIUS, the Security Gateway forwards authentication requests by remote users to the RADIUS server. For administrators, the Security Management Server forwards the authentication requests. The RADIUS server, which stores user account information, does the authentication.

The RADIUS protocol uses UDP to communicate with the gateway or the Security Management Server.

RADIUS servers and RADIUS server group objects are defined in SmartConsole.

Terminal Access Controller Access Control System (TACACS) provides access control for routers, network access servers and other networked devices through one or more centralized servers.

TACACS is an external authentication method that provides verification services. Using TACACS, the Security Gateway forwards authentication requests by remote users to the TACACS server. For administrators, it is the Security Management Server that forwards the requests. The TACACS server, which stores user account information, authenticates users. The system supports physical card key devices or token cards and KerberosClosed An authentication server for Microsoft Windows Active Directory Federation Services (ADFS). secret key authentication. TACACS encrypts the user name, password, authentication services and accounting information of all authentication requests to ensure secure communication.

SecurID requires users to both possess a token authenticator and to supply a PIN or password. Token authenticators generate one-time passwords that are synchronized to an RSA Authentication Manager (AM) and may come in the form of hardware or software. Hardware tokens are key-ring or credit card-sized devices, while software tokens reside on the PC or device from which the user wants to authenticate. All tokens generate a random, one-time use access code that changes approximately every minute. When a user attempts to authenticate to a protected resource, the one-time use code must be validated by the AM.

Using SecurID, the Security Gateway forwards authentication requests by remote users to the AM. For administrators, it is the Security Management Server that forwards the requests. The AM manages the database of RSA users and their assigned hard or soft tokens. The Security Gateway or the Security Management Server act as an AM agent and direct all access requests to the RSA AM for authentication. For additional information on agent configuration, refer to RSA Authentication Manager documentation.

There are no specific parameters required for the SecurID authentication method. Authentication requests can be sent over SDK-supported API or through REST API.

There are no specific parameters required for the SecurID authentication method.

Configuring RADIUS or TACACS Authentication

These are the options to enable connectivity between Virtual Systems and a RADIUS or TACACS/TACACS+ server:

Option

Description

Shared configuration

All Virtual Systems connect to the RADIUS or TACACS/TACACS+ authentication servers through the VSXClosed Virtual System Extension. Check Point virtual networking solution, hosted on a computer or cluster with virtual abstractions of Check Point Security Gateways and other network devices. These Virtual Devices provide the same functionality as their physical counterparts. Gateway.

This is the default option.

Private configuration

All Virtual Systems connect to the RADIUS or TACACS/TACACS+ authentication servers directly.

The Virtual Systems use the Virtual SystemClosed Virtual Device on a VSX Gateway or VSX Cluster Member that implements the functionality of a Security Gateway. Acronym: VS. clusterClosed Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. IP address as the source address.

For Multi-Domain ServerClosed Dedicated Check Point server that runs Check Point software to host virtual Security Management Servers called Domain Management Servers. Synonym: Multi-Domain Security Management Server. Acronym: MDS. configurations, make sure that you configure the authentication settings on the Domain Management Server that manages the Virtual Systems.

Configure shared authentication so that all the Virtual Systems on the VSX Gateway authenticate to the remote RADIUS or TACACS/TACACS+ server.

To configure shared authentication for RADIUS or TACACS/TACACS+:

  1. Configure shared authentication on the Virtual Systems.

    1. Connect with SmartConsole to the Management Server.

    2. From the left navigation panel, click Gateways & Servers.

    3. Double-click the Virtual System object.

      The Virtual Systems General Properties window opens.

    4. From the navigation tree, select Other > Authentication.

    5. Make sure that RADIUS or TACACS and Shared are selected.

    6. Click OK.

    7. Install the policy on the Virtual Systems.

    Repeat these Steps for each Virtual System.

  2. For a VSX Cluster:

    On the Management Server that manages this VSX Cluster, make sure that Hide NAT is disabled.

    On Multi-Domain Server, work in the context of the Target Domain Management Server that manages the Virtual System.

    1. Edit the applicable table.def file. See sk98339.

    2. Make sure that the no_hide_services_ports parameter contains the UDP ports for RADIUS or TACACS, or the TCP ports for TACACS+.

      The default ports are:

      • RADIUS - 1645

      • TACACS/TACACS+ - 49

      Sample RADIUS parameter with Hide NAT disabled:

      no_hide_services_ports = { <49, 6>, <49, 17>, <500, 17>, <259, 17>, <1701, 17>, <123, 17>, <1645, 17> };

    3. Save the changes in the file and exit the editor.

    4. In SmartConsole, install the policy on the Virtual Systems.

For private configurations, the active and standby Virtual Systems use the same encryption key to authenticate to the remote RADIUS or TACACS/TACACS+ server.

For High Availability configurations, make sure that the Active and Standby Virtual Systems on each VSX Cluster MemberClosed Security Gateway that is part of a cluster. use the same VIP address.

To configure private authentication:

  1. Configure private authentication on the VSX Gateway and the Virtual Systems.

    1. Connect with SmartConsole to the Management Server.

    2. From the left navigation panel, click Gateways & Servers.

    3. Double-click the VSX Gateway object.

      The General Properties view opens.

    4. From the navigation tree, select Other > Legacy Authentication.

    5. Make sure that RADIUS or TACACS are selected.

    6. Click OK.

    7. From SmartConsole, install the Access Control Policy on the Virtual System.

    Repeat these steps for each Virtual System.

  2. For VSX Cluster:

    On the Management Server that manages this VSX Cluster, make sure that Hide NAT is enabled.

    For Multi-Domain Server, use the Domain Management Server that manages the Virtual System.

    1. Edit the applicable table.def file (see sk98339) in a plain-text editor.

    2. Make sure that the no_hide_services_ports parameter DOES NOT contain the UDP ports for RADIUS or TACACS, or the TCP ports for TACACS+.

      The default ports are:

      • RADIUS - 1645

      • TACACS/TACACS+ - 49

      Sample parameter with Hide NAT enabled:

      no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17> };

    3. Save the changes in the file and exit the editor.

    4. From SmartConsole, install the Access Control Policy on each Virtual System.

Configuring RSA SecurID Authentication

See the R81.10 Security Management Administration Guide > Chapter Managing User and Administrator Accounts > Section Managing User Accounts > Section SecurID Authentication for Security Gateway.

These are the options to enable connectivity between Virtual Systems and a SecurID ACE/Server (RSA Authentication Manager):

Option

Description

Shared configuration

All Virtual Systems on the VSX Gateway / VSX Cluster Member use the same encryption key file "sdconf.rec" to authenticate to the remote SecurID ACE/Server (RSA Authentication Manager).

In a VSX Cluster, each VSX Cluster Member uses a different encryption key file "sdconf.rec" and node secret file "securid".

For the MIP (Member IP) address, use the IP address of a VSX Gateway / VSX Cluster Member interface that connects to the SecurID ACE/Server (RSA Authentication Manager).

Private configuration

Each Virtual System uses unique encryption key file "sdconf.rec" and node secret file "securid" to authenticate to the remote SecurID ACE/Server (RSA Authentication Manager).

On a VSX Gateway - for the MIP (Member IP) address, use the IP address of the Virtual System interface that connects to the SecurID ACE/Server (RSA Authentication Manager).

On a VSX Cluster - for the MIP (Member IP) address, use the VIP (Virtual IP) address of the Virtual System interface that connects to the SecurID ACE/Server (RSA Authentication Manager).

On a Multi-Domain Server, make sure that you configure the authentication settings on the Domain Management Server that manages the Virtual Systems.

Part 1 - On the SecurID ACE/Server (RSA Authentication Manager), generate the "sdconf.rec" files:

On the SecurID ACE/Server (RSA Authentication Manager), generate the "sdconf.rec" file with the MIP of the VSX Gateway / each VSX Cluster Member.

For example, if a VSX Cluster has three VSX Cluster Members, and each VSX Cluster Member has five Virtual Systems, then generate three "sdconf.rec" files - one file for each VSX Cluster Member.

Part 2 - Configure the shared authentication for each Virtual System:

  1. Configure shared authentication in each Virtual System object:

    1. Connect with SmartConsole to the Management Server.

    2. From the left navigation panel, click Gateways & Servers.

    3. Double-click the applicable Virtual System object.

    4. From the left navigation tree, select Other> Legacy Authentication.

    5. Select SecurID and Shared.

    6. Click OK.

    7. Install the Access Control policy on the Virtual System.

  2. For each Virtual System, create the "sdopts.rec" file that contains the required MIP address.

    1. Connect to the command line on the VSX Gateway / each VSX Cluster Member.

      On a (Undefined variable: Vars_ScalablePlatforms.tp_sp), connect to the Security Group.

    2. Log in to the Expert mode..

    3. Change the context to the Virtual System 0:

      • On a VSX Gateway / each VSX Cluster Member:

        vsenv 0

      • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

        g_all vsenv 0

    4. Create the "/var/ace/sdopts.rec" file:

      • On a VSX Gateway / each VSX Cluster Member:

        touch /var/ace/sdopts.rec

      • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

        g_all touch /var/ace/sdopts.rec

    5. Edit the "/var/ace/sdopts.rec" file:

      vi /var/ace/sdopts.rec

    6. Add this line to the "/var/ace/sdopts.rec" file:

      CLIENT_IP=<IP Address of interface on VSX Gateway / each VSX Cluster Member>

    7. Save the changes in the file and exit the editor.

    8. On a (Undefined variable: Vars_ScalablePlatforms.tp_sp), copy the updated "/var/ace/sdopts.rec" file to all (Undefined variable: Vars_ScalablePlatforms.tp_sg_mbs):

      asg_cp2blades /var/ace/sdopts.rec

    9. Copy the "/var/ace/sdopts.rec" file to each Virtual System:

      1. Change the context to the Virtual System:

        • On a VSX Gateway / each VSX Cluster Member:

          vsenv <VSID>

        • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

          g_all vsenv <VSID>

      2. Copy the "/var/ace/sdopts.rec" file:

        • On a VSX Gateway / each VSX Cluster Member:

          cp -v /var/ace/sdopts.rec $FWDIR/conf/

        • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

          g_all cp -v /var/ace/sdopts.rec $FWDIR/conf/

  3. Copy the same encryption key file sdconf.rec from the SecurID ACE/Server (RSA Authentication Manager) to the required directory on the VSX Gateway / each VSX Cluster Member / Security Group:

    • For Virtual System 0, copy the "sdconf.rec" file to the "/var/ace/" directory on the VSX Gateway / each VSX Cluster Member / Security Group.

    • For other Virtual Systems, copy the file to the "$FWDIR/conf/" directory in the context of each Virtual System:

      1. Copy the "sdconf.rec" file to some temporary directory on the VSX Gateway / each VSX Cluster Member / Security Group.

        For example: /var/tmp/

      2. On a (Undefined variable: Vars_ScalablePlatforms.tp_sp), copy the "sdconf.rec" file in the temporary directory to all (Undefined variable: Vars_ScalablePlatforms.tp_sg_mbs):

        asg_cp2blades /var/tmp/sdconf.rec

      3. Change the context to the Virtual System:

        • On a VSX Gateway / each VSX Cluster Member:

          vsenv <VSID>

        • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

          g_all vsenv <VSID>

      4. Copy the "sdconf.rec" file from the temporary directory to the "$FWDIR/conf/" directory in the context of each Virtual System

        • On a VSX Gateway / each VSX Cluster Member:

          cp -v /var/tmp/sdconf.rec $FWDIR/conf/

        • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

          g_all cp -v /var/tmp/sdconf.rec $FWDIR/conf/

  4. If this is a VSX Cluster, then configure the required settings for the Cluster Hide NAT for traffic on the UDP port 5500:

    1. Connect to the command line on the Management Server.

    2. Log in to the Expert mode.

    3. Edit the applicable table.def file.

      vi /Path/To/Required/table.def

      For the exact path, see the section "Location of 'table.def' Files on the Management Server" in:

    4. Make sure the "no_hide_services_ports" parameter contains the correct ports:

      • If the SecurID ACE/Server (RSA Authentication Manager) expects the connection from each VSX Cluster Member (and not from the VSX Cluster Virtual IP address), then the "no_hide_services_ports" parameter must contain the port 5500 and protocol 17 (<5500, 17>):

        Example:

        no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17>, <5500, 17> };

      • If the SecurID ACE/Server (RSA Authentication Manager) expects the connection from the VSX Cluster Virtual IP address, then the "no_hide_services_ports" parameter must not contain the port 5500 and protocol 17 (<5500, 17>):

        Example:

        no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17> };

    5. Save the changes in the file and exit the editor.

    6. In SmartConsole, install the Access Control on the Virtual Systems.

Part 3 - Distribute the node secret to the Virtual Systems:

The first time a VSX Gateway / VSX Cluster Member connects to the SecurID ACE/Server (RSA Authentication Manager), the server sends the node secret file (securid) to that VSX Gateway. It is necessary to copy this node file to all Virtual Systems.

  1. Authenticate to the VSX Gateway with a SecurID ACE/Server (RSA Authentication Manager) user account.

    The SecurID ACE/Server (RSA Authentication Manager) sends the node secret file "securid" to the VSX Gateway / VSX Cluster Member.

  2. Search for the file called "securid":

    find /var/ace/ -name securid -type f

  3. On a (Undefined variable: Vars_ScalablePlatforms.tp_sp), copy the "securid" file to all (Undefined variable: Vars_ScalablePlatforms.tp_sg_mbs):

    asg_cp2blades /var/ace/securid

  4. Copy the "securid" file to the "$FWDIR/conf/" directory in the context of each Virtual System:

    1. Change the context to the Virtual System:

      • On a VSX Gateway / each VSX Cluster Member:

        vsenv <VSID>

      • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

        g_all vsenv <VSID>

    2. Copy the "securid" file to Virtual Systems:

      • On a VSX Gateway / each VSX Cluster Member:

        cp -v /var/ace/securid $FWDIR/conf/

      • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

        g_all cp -v /var/ace/securid $FWDIR/conf/

  5. If this is a VSX Cluster, then on each VSX Cluster Member:

    • Locate a Virtual System that is Active on that VSX Cluster Member and do the all the previous steps in this Part 3.

    • If there are no Virtual Systems in the Active state on that VSX Cluster Member, fail-over to the applicable VSX Cluster Member and then do the all the previous steps in this Part 3.

Part 1 - On the SecurID ACE/Server (RSA Authentication Manager), generate the "sdconf.rec" files:

On the SecurID ACE/Server (RSA Authentication Manager), generate the "sdconf.rec" file with the MIP of the Virtual System.

For example, if a VSX Cluster has three VSX Cluster Members, and each VSX Cluster Member has five Virtual Systems, then generate five "sdconf.rec" files - one file for each Virtual System.

Part 2 - Configure the private authentication for each Virtual System:

  1. Configure shared authentication in each Virtual System object:

    1. Connect with SmartConsole to the Management Server.

    2. From the left navigation panel, click Gateways & Servers.

    3. Double-click the applicable Virtual System object.

    4. From the left navigation tree, select Other> Legacy Authentication.

    5. Select SecurID and Private.

    6. Click OK.

    7. Install the Access Control policy on the Virtual System.

  2. For each Virtual System, create the "sdopts.rec" file that contains the required MIP address.

    1. Connect to the command line on the VSX Gateway / each VSX Cluster Member.

      On a (Undefined variable: Vars_ScalablePlatforms.tp_sp), connect to the Security Group.

    2. Log in to the Expert mode..

    3. Change the context to the Virtual System:

      • On a VSX Gateway / each VSX Cluster Member:

        vsenv <VSID>

      • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

        g_all vsenv <VSID>

    4. Create the "$FWDIR/conf/sdopts.rec" file:

      touch $FWDIR/conf/sdopts.rec

    5. Edit the "$FWDIR/conf/sdopts.rec" file:

      vi $FWDIR/conf/sdopts.rec

    6. Add this line to the "$FWDIR/conf/sdopts.rec" file:

      CLIENT_IP=<IP Address of interface on Virtual System>

    7. Save the changes in the file and exit the editor.

    8. On a (Undefined variable: Vars_ScalablePlatforms.tp_sp), copy the updated "$FWDIR/conf/sdopts.rec" file to all (Undefined variable: Vars_ScalablePlatforms.tp_sg_mbs):

      asg_cp2blades $FWDIR/conf/sdopts.rec

  3. Copy the unique encryption key file sdconf.rec from the SecurID ACE/Server (RSA Authentication Manager) to the "$FWDIR/conf/" directory in the context of the required Virtual System on the VSX Gateway / each VSX Cluster Member / Security Group:

    1. Copy the "sdconf.rec" file to some temporary directory on the VSX Gateway / each VSX Cluster Member / Security Group.

      For example: /var/tmp/

    2. On a (Undefined variable: Vars_ScalablePlatforms.tp_sp), copy the "sdconf.rec" file in the temporary directory to all (Undefined variable: Vars_ScalablePlatforms.tp_sg_mbs):

      asg_cp2blades /var/tmp/sdconf.rec

    3. Change the context to the required Virtual System:

      • On a VSX Gateway / each VSX Cluster Member:

        vsenv <VSID>

      • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

        g_all vsenv <VSID>

    4. Copy the "sdconf.rec" file from the temporary directory to the "$FWDIR/conf/" directory in the context of the required Virtual System

      • On a VSX Gateway / each VSX Cluster Member:

        cp -v /var/tmp/sdconf.rec $FWDIR/conf/

      • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

        g_all cp -v /var/tmp/sdconf.rec $FWDIR/conf/

  4. If this is a VSX Cluster, then configure the required settings for the Cluster Hide NAT for traffic on the UDP port 5500:

    1. Connect to the command line on the Management Server.

    2. Log in to the Expert mode.

    3. Edit the applicable table.def file.

      vi /Path/To/Required/table.def

      For the exact path, see the section "Location of 'table.def' Files on the Management Server" in:

    4. Make sure the "no_hide_services_ports" parameter contains the correct ports:

      • If the SecurID ACE/Server (RSA Authentication Manager) expects the connection from each Virtual System (and not from the Virtual System Virtual IP address), then the "no_hide_services_ports" parameter must contain the port 5500 and protocol 17 (<5500, 17>):

        Example:

        no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17>, <5500, 17> };

      • If the SecurID ACE/Server (RSA Authentication Manager) expects the connection from the Virtual System Virtual IP address, then the "no_hide_services_ports" parameter must not contain the port 5500 and protocol 17 (<5500, 17>):

        Example:

        no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17> };

    5. Save the changes in the file and exit the editor.

    6. In SmartConsole, install the Access Control on the Virtual System.

Part 3 - Distribute the node secret to the Virtual Systems:

The first time a VSX Gateway / VSX Cluster Member connects to the SecurID ACE/Server (RSA Authentication Manager), the server sends the node secret file (securid) to that VSX Gateway. It is necessary to copy this node file to all Virtual Systems.

  1. Authenticate to the VSX Gateway with a SecurID ACE/Server (RSA Authentication Manager) user account.

    The SecurID ACE/Server (RSA Authentication Manager) sends the node secret file "securid" to the VSX Gateway / VSX Cluster Member.

  2. Search for the file called "securid":

    find /var/ace/ -name securid -type f

  3. On a (Undefined variable: Vars_ScalablePlatforms.tp_sp), copy the "securid" file to all (Undefined variable: Vars_ScalablePlatforms.tp_sg_mbs):

    asg_cp2blades /var/ace/securid

  4. Copy the "securid" file to the "$FWDIR/conf/" directory in the context of each Virtual System:

    1. Change the context to the Virtual System:

      • On a VSX Gateway / each VSX Cluster Member:

        vsenv <VSID>

      • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

        g_all vsenv <VSID>

    2. Copy the "securid" file to Virtual Systems:

      • On a VSX Gateway / each VSX Cluster Member:

        cp -v /var/ace/securid $FWDIR/conf/

      • On a (Undefined variable: Vars_ScalablePlatforms.tp_sp):

        g_all cp -v /var/ace/securid $FWDIR/conf/

  5. If this is a VSX Cluster, then on each VSX Cluster Member:

    • Locate a Virtual System that is Active on that VSX Cluster Member and do the all the previous steps in this Part 3.

    • If there are no Virtual Systems in the Active state on that VSX Cluster Member, fail-over to the applicable VSX Cluster Member and then do the all the previous steps in this Part 3.