VPN for Remote Access Considerations

In This Section: Policy Definition for Remote Access User Certificate Creation Methods when Using the ICA Multiple Certificates per User Internal User Database vs. External User Database NT Group/RADIUS Class Authentication Feature Granting User Access Using RADIUS Server Groups Associating a RADIUS Server with a Security Gateway

When designing Remote Access VPN, consider the following issues:

Policy Definition for Remote Access

There must be a rule in the Security Policy Rule Base that grants remote users access to the LAN. Consider which services are allowed. Restrict those services that need to be restricted with an explicit rule in the Security Policy Rule Base.

User Certificate Creation Methods when Using the ICA

Check Point's Internal Certificate Authority (ICA) offers two ways to create and transfer certificates to remote users:

1. The administrator generates a certificate in the Security Management Server for the remote user, saves it to removable media, and transfers it to the client "out-of-band."
2. The administrator initiates the certificate process on the Security Management Server (or ICA management tool), and is given a registration key. The administrator transfers the registration key to the user "out-of-band." The client establishes an SSL connection to the ICA (using the CMC protocol) and completes the certificate generation process using the registration key. In this way:
   • Private keys are generated on the client.
   • The created certificate can be stored as a file on the machines hard-drive, on a CAPI storage device, or on a hardware token.

   This method is especially suitable for geographically spaced-remote users.

Multiple Certificates per User

Check Point VPN lets you define many certificates for each user. This lets users connect from different devices without the necessity to copy or move certificates from one device to another. Users can also connect from different devices at the same time.

Internal User Database vs. External User Database

Remote Access functionality includes a flexible user management scheme. Users are managed in a number of ways:

• INTERNAL - A Security Gateway can store a static password in its local user database for each user configured in Security Management Server. No additional software is needed.
• LDAP - LDAP is an open industry standard that is used by multiple vendors. Check Point products integrate LDAP with Check Point User Directory. Manage the users externally on the LDAP server, and changes are reflected on the SmartDashboard. Security Gateways query the User Directory data for authentication.
• RADIUS - Remote Authentication Dial-In User Service (RADIUS) is an external authentication scheme that provides security and scalability by separating the authentication function from the access server.

  When employing RADIUS as an authentication scheme, the Security Gateway forwards authentication requests by remote users to the RADIUS server. The RADIUS server, which stores user account information, authenticates the users. The RADIUS protocol uses UDP for communications with the Security Gateway. RADIUS Servers and RADIUS Server Group objects are defined in SmartDashboard.

• SecurID Token Management ACE/Server - Developed by RSA Security, 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 ACE/Server, 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 every minute or so. When a user attempts to authenticate to a protected resource, that one-time-use code must be validated by the ACE/Server.

  When employing SecurID as an authentication scheme, the Security Gateway forwards authentication requests by remote users to the ACE/Server. ACE manages the database of RSA users and their assigned hard or soft tokens. The VPN module acts as an ACE/Agent 5.0, which means that it directs all access requests to the RSA ACE/Server for authentication. For agent configuration see ACE/Server documentation.

The differences between user management on the internal database, and User Directory:

• User Directory is done externally and not locally.
• If you change User Directory templates the change is applied to users dynamically, immediately.

NT Group/RADIUS Class Authentication Feature

Authentication can take place according to NT groups or RADIUS classes. In this way, remote access users are authenticated according to the remote access community group they belong to.

Note - Only NT groups are supported, not Active Directory.

Granting User Access Using RADIUS Server Groups

The Security Gateway enables you to control access for authenticated RADIUS users, based on the administrator's assignment of users to RADIUS groups. These groups are used in the Security Rule Base to restrict or give users access to specified resources. Users are unaware of the groups to which they belong.

To use RADIUS groups, you must define a return attribute in the RADIUS user profile of the RADIUS server. This attribute is returned to the Security Gateway and contains the group name (for example, RAD_<group to which the RADIUS users belong>) to which the users belong.

Use these RADIUS attributes (refer to RFC 2865):

• For SecurePlatform - attribute "Class" (25)
• For other operating systems, including Gaia, Windows, and IPSO- attribute "Vendor-Specific" (26)

To give access through RADIUS server groups:

1. In SmartDashboard, go to Manage > Server and OPSEC Applications.

   Servers and OPSEC Applications window opens.

2. Click New > RADIUS.

   The RADIUS Server Properties window opens.

3. Configure new server properties:
   1. Name the RADIUS Server object.
   2. Click New to create a new Host Object.

      Host Node window opens.

   3. Enter the Name and the IP Address of the new RADIUS Host object, and click OK.
   4. Select the Service - RADIUS (on port 1645) or NEW-RADIUS (on port 1812 service).

      Note - The default setting is RADIUS, however the RADIUS standards group recommends using NEW-RADIUS, because port 1645 can conflict with the datametrics service running on the same port.

   5. Enter the Shared Secret that you configured on the RADIUS server.
   6. Select the version - RADIUS Ver. 1.0 Compatible (RFC 2138 compliant) or RADIUS Ver. 2.0 Compatible (RFC 2865 compliant).
   7. Select the Priority, if you use more than one RADIUS Authentication server.
   8. Click OK.
   9. Click Close.
4. Create a generic* External User Profile:
   1. Go to Manage > Users and Administrators.

      Users and Administrators window opens.

   2. Go to New > External User Profile > Match all users.

      External User Profile Properties window opens.

   3. In the Authentication tab, select RADIUS as the Authentication Scheme.
   4. Select the created RADIUS server (not the node) from the drop-down list.
   5. Click OK.
   6. Click Close.
5. Define the RADIUS user groups
   1. Go to Manage > Users & Administrators.

      Users and Administrators window opens.

   2. Go to New > User Group.

      Group Properties window opens.

   3. Enter the name of the group in this format: RAD_<group to which the RADIUS users belong>. Make sure the group is empty.
   4. Click OK.
   5. Click Close.
6. Create the required Rule Base rules to allow access to RADIUS users.
7. Save the changes.
8. Close all SmartConsole windows.
9. Connect with GuiDBedit Tool (see sk13009) to Security Management Server.
10. Change the value of the add_radius_groups attribute from false to true.
11. Save the changes.
12. Close GuiDBedit Tool.
13. Open SmartDashboard.
14. Install the policy.
15. On the RADIUS server, edit the RADIUS users to include a class RADIUS attribute on the users Return list that corresponds to the user group that they access.

To use a different attribute instead of the class attribute:

1. Close all SmartConsole windows.
2. Connect with GuiDBedit Tool (see sk13009) to Security Management Server.
3. In the firewall_properties, modify the value of the attribute radius_groups_attr to the new RADIUS attribute.
4. Save the changes.
5. Close GuiDBedit Tool.
6. Open SmartDashboard.
7. Install the policy.
8. On the RADIUS server, make sure that you use the same RADIUS attribute on users' Return lists that corresponds to the Firewall user group that they access.

Associating a RADIUS Server with a Security Gateway

You can associate users with the RADIUS authentication server in the User Properties > Authentication tab. You can override that association and associate a gateway with a RADIUS server.

To configure RADIUS association, run the dbedit command (see skI3301).

To associate one or more RADIUS servers to a gateway:

modify network_objects <gateway obj> radius_server servers:<radius obj>

To turn off the RADIUS-gateway association:

modify users <user obj> use_fw_radius_if_exist false