User and Client Authentication for Remote Access

In This Section: Client-Security Gateway Authentication Schemes Multiple Login Options for R80.xx Gateways Internal User Database vs. External User Database Defining User and Authentication Methods in LDAP Managing User Certificates Using a Pre-Shared Secret NT Group/RADIUS Class Authentication Feature Configuring RADIUS Objects Working with RSA Hard and Soft Tokens Enabling Hybrid Mode and Methods of Authentication

Client-Security Gateway Authentication Schemes

Authentication is a key factor in establishing a secure communication channel among Security Gateways and remote clients. Various authentication methods are available, for example:

• Digital certificates
• Pre-shared secrets
• Other authentication methods

On R80.10 and higher Mobile Access and IPsec VPN gateways, you can configure multiple login options. The options can be different for each gateway and each Software Blade. Users select one of the available options to log in with a supported client.

See the documentation for each client to learn which authentication methods are supported.

Digital User Certificates

Digital Certificates are the most recommended and manageable method for authentication. Both parties present certificates as a means of proving their identity. Both parties verify that the peer's certificate is valid (i.e. that it was signed by a known and trusted CA, and that the certificate has not expired or been revoked).

Digital certificates are issued either by Check Point's Internal Certificate Authority or third-party PKI solutions. Check Point's ICA is tightly integrated with VPN and is the easiest way to configure a Remote Access VPN. The ICA can issue certificates both to Security Gateways (automatically) and to remote users (generated or initiated).

Generate digital certificates easily in SmartConsole > Security Policies > Access Tools > Client Certificates.

The administrator can also initiate a certificate generation on the ICA management tool. It is also possible to use third-party Certificate Authorities to create certificates for authentication between Security Gateways and remote users. The supported certificate formats are PKCS#12, CAPI, and Entrust.

Users can also be given a hardware token for storing certificates. This option offers the advantage of higher level of security, since the private key resides only on the hardware token.

As part of the certificate validation process during the IKE negotiation, both the client and the Security Gateway check the peer's certificate against the Certificate Revocation List (CRL) published by the CA which issued the certificate. If the client is unable to retrieve a CRL, the Security Gateway retrieves the CRL on the client's behalf and transfers the CRL to the client during the IKE negotiation (the CRL is digitally signed by the CA for security).

Pre-Shared Secret

This authentication method has the advantage of simplicity, but it is less secure than certificates.

Both parties agree upon a password before establishing the VPN. The password is exchanged "out-of-band", and reused multiple times. During the authentication process, both the client and Security Gateway verify that the other party knows the agreed-upon password.

Other Authentication Methods

These user authentication methods are supported for remote access.

• Security Gateway Password - Users enter their password that are on the Security Gateway.
• DynamicID One Time Password - Users enter the number shown in an SMS message to a specified cellphone number or by email.
• OS Password - Users enter their Operating System password.
• SecurID One Time Password - Users enter the number shown on a Security Dynamics SecurID card.

  SoftID (a software version of RSA's SecurID) and various other One Time Password cards and USB tokens are also supported.

• RADIUS - Users enter the correct response, as defined by the RADIUS server.
• TACACS - Users enter the correct response, as defined by the TACACS or TACACS+ server.
• SAA - SAA is an OPSEC API extension to Remote Access Clients that enables third party authentication methods, such as biometrics, to be used with Endpoint Security VPN, Check Point Mobile for Windows, and SecuRemote.

Multiple Login Options for R80.xx Gateways

On R80.10 and higher Mobile Access and IPsec VPN gateways, you can configure multiple login options. The options can be different for each gateway and each supported Software Blade, and for some client types. Users select one of the available options to log in with a supported client.

By default, all clients connect with the pre-R80.xx method. When you create new login options, newer clients can see them in addition to the pre-R80.xx option, but older clients cannot.

To see which clients support the new multiple login options, see sk111583.

Each configured login option is a global object that can be used with multiple gateways and the Mobile Access and IPsec VPNSoftware Blades.

Compatibility with Older Clients

By default, older clients connect with a single authentication method, based on settings available on pre-R80 gateways.

You can block older clients from connecting. After you do this, only clients that support multiple login options can connect to the gateway.

By default, Allow old clients to connect is selected in VPN Clients > Authentication. If you clear the option, older clients are blocked.

You can choose if newer clients that support multiple login options can connect with the authentication settings defined for older clients.

Configuring the Authentication Method for Newer Clients

To block newer clients from using the authentication method defined for older clients:

1. In the Gateway Properties, select VPN Clients > Authentication.
2. In the Compatibility with Older Clients section, click Settings.

   The Single Authentication Clients Settings window opens.

3. Clear Allow newer client that support Multiple Login Options to use this authentication method.
4. Click OK.
5. Install policy.

To let newer clients connect to the gateway with the authentication settings defined for older clients:

Select Allow newer client that support Multiple Login options to use this authentication method.

Configuring Authentication Settings for Older Clients

To let older clients connect to the R80.10 gateway:

1. In the Gateway Properties, select VPN Clients > Authentication.
2. Select Allow older clients to connect to this gateway.

   If this is not selected, older clients cannot connect to the gateway.

To change the authentication method for older clients:

1. In the Gateway Properties, select VPN Clients > Authentication.
2. In the Compatibility with Older Clients section, click Settings.

   The Single Authentication Clients Settings window opens.

3. Change the Display Name to change the way the authentication method is shown in SmartConsole.
4. Select an Authentication method.
5. Click Customize to change the description of fields that are shown to users in the Connect window. See Customize Display Settings.
6. Click OK.
7. Click OK.
8. Install policy on the gateway.

You can configure DynamicID for older clients manually in GuiDBedit Tool (see sk13009) or dbedit (see skI3301). See sk86240.

Configuring Multiple Log-in Options

Configure login options from: Gateway Properties > VPN Clients > Authentication

If Mobile Access is enabled, you can also configure login options from:

• In SmartConsole Gateway & Servers, double-click a gateway. From the Gateway Properties window > Mobile Access > Authentication
• In SmartDashboard > Mobile Access tab > Authentication

The login options selected for IPsec VPN clients, such as Endpoint Security VPN, Check Point Mobile for Windows, and SecuRemote, show in the VPN Clients > Authentication page in the Multiple Authentication Client Settings table.

The login options selected for Mobile Access clients, such as the Mobile Access portal and Capsule Workspace, show in the Mobile Access > Authentication page in the Multiple Authentication Client Settings table.

To configure multiple login options for IPsec VPN Clients:

1. From the Gateway Properties tree of a gateway, select VPN Clients > Authentication.
2. In the Multiple Authentication Clients Settings table, see a list of configured login options.

   The default login options are:

   • Personal_Certificate - Requires a user certificate.
   • Username_Password - Requires a username and password.
   • Cert_Username_Password - Require a username and password and a user certificate.
3. Click Add to create a new option or Edit to change an option. Each configured login option is a global object that can be used with multiple gateways and Software Blades.
4. For each login option select one or more Authentication Factors and relevant Authentication Settings.

   For example, if you select SecurID, select the SecurID Server and Token Card Type. If you select Personal Certificate, select which certificate field the gateway uses to fetch the username. See Certificate Parsing.

5. Select Customize Display to configure what users see when they log in with this option. See Customize Display Settings. Click OK.
6. Use the Up and Down arrows to set the order of the login options.

   Notes:

   • If you include Personal Certificates, it must be first.
   • If you include DynamicID, it cannot be first.
7. Click OK.

Customize Display Settings

Enter descriptive values to make sure that users understand what information to input. These fields must all be the same language but they do not need to be in English.

• Headline - The title of the login option, for example, Log in with a Certificate or Log in with your SecurID Pinpad.
• Username label - A description of the username that users must enter, for example, Email address or AD username.
• Password label - A description of the password that users must enter, for example, AD password.

Certificate Parsing

When you select Personal Certificate as a Login option, you can also configure what information the gateway sends to the LDAP server to parse the certificate. The default is the DN. You can configure the settings to use the user's email address or a serial number instead.

To change the certificate parsing:

1. In the Multiple Authentication Clients Settings table on the Authentication page, select a Personal_Certificate entry and click Edit.

   The Authentication Factor window opens.

2. In the Authentication Settings area in the Fetch Username from field, select the information that the gateway uses to parse the certificate.
3. Click OK.
4. Install policy.

Deleting Login Options

To permanently delete a Login option:

1. In SmartConsole, select Security Policies > Shared Policies > Mobile Access and click Open Mobile Access Policy in SmartDashboard.
2. In SmartDashboard go to the Mobile Access tab > Authentication page.
3. From the list of login options, select an option and click Delete.

Multi-Factor Authentication with DynamicID

Multi-factor authentication is a system where two or more different methods are used to authenticate users. Using more than one factor delivers a higher level of authentication assurance. DynamicID is one option for multi-factor authentication.

Users who successfully complete the first-phase authentication can be challenged to provide an additional credential: a DynamicID One Time Password (OTP). The OTP is sent to their mobile communications device (such as a mobile phone) via SMS or directly to their email account.

On R80.x and higher gateways, DynamicID is supported for all Mobile Access and IPsec VPN clients.

Configuring DynamicID

Basic DynamicID configuration is shown here. For Advanced configuration options, see the Mobile Access Administration Guide.

To configure global DynamicID settings that all gateways use:

1. In SmartConsole, select Security Policies > Shared Policies > Mobile Access and click Open Mobile Access Policy in SmartDashboard.

   SmartDashboard opens and shows the Mobile Access tab.

2. From the navigation tree, click Authentication.
3. From the Dynamic ID Settings section, click Edit.
4. Enter the DynamicID Settings.
5. Click OK.
6. Click Save and then close SmartDashboard.
7. From SmartConsole, install policy.

To configure DynamicID settings for a specified gateway:

1. In SmartConsole, in the Gateways & Servers view, double-click the Security Gateway.
2. From the navigation tree, select VPN Clients > Authentication.
3. From the Dynamic ID Settings section, clear the Use Global Settings option.
4. Click Edit.
5. Enter the DynamicID Settings.
6. Click OK.
7. Install the policy.

DynamicID Settings

This table explains parameters used in the SMS Provider and Email Settings field. The value of these parameters is automatically used when sending the SMS or email.

Parameter	Meaning
$APIID	The value of this parameter is the API ID.
$USERNAME	The value of this parameter is the username for the SMS provider.
$PASSWORD	The value of this parameter is the password for the SMS provider.
$PHONE	User phone number, as found in Active Directory or in the local file on the gateway, including digits only and without a + sign.
$EMAIL	The email address of the user as found in Active Directory or in the local SmsPhones.lst file on the gateway. If the email address should be different than the listed one, it can be written explicitly.
$MESSAGE	The value of this parameter is the message configured in the Advanced Two-Factor Authentication Configuration Options in SmartDashboard.
$RAWMESSAGE	The text from $Message but without HTTP encoding.

Enter this information in the DynamicID Setting window:

1. Fill in the Provider and Email Settings field using one of these formats:
   1. To let the DynamicID code to be delivered by SMS only, use the following syntax:

      https://api.example.com/http/sendmsg?api_id=$APIID&user=
$USERNAME&password=$PASSWORD&to=$PHONE&text=$MESSAGE

   2. To let the DynamicID code to be delivered by email only, without an SMS service provider, use the following syntax:

      mail:TO=$EMAIL;SMTPSERVER=smtp.example.com;FROM=sslvpn@example.com;
BODY=$RAWMESSAGE

   3. To let the DynamicID code to be delivered by SMS or email, use the following syntax:

      sms:https://api.example.com/sendsms.php?username=$USERNAME&password=
$PASSWORD&phone=$PHONE&smstext=$MESSAGE mail:TO=$EMAIL;
SMTPSERVER=smtp.example.com;FROM=sslvpn@example.com;
BODY=$RAWMESSAGE

2. In the SMS Provider Account Credentials section, enter the credentials received from the SMS provider:
   • Username
   • Password
   • API ID (optional)

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.

Defining User and Authentication Methods in LDAP

1. Obtain and install a license that enables the VPN module to retrieve information from an LDAP server.
2. Create an LDAP account unit.
3. Define users as LDAP users. A new network object for LDAP users is created on the Users tree. (The LDAP users also appear in the objects list window to the right.)

For more information see: LDAP and User Management in the R80.10 Security Management Server Administration Guide.

Managing User Certificates

Managing user certificates involves:

Tracing the status of the user's certificate

The status of a user's certificate can be traced at any time in the Certificates tab of the user's Properties window. The status is shown in the Certificate state field. If the certificate has not been generated by the user by the date specified in the Pending until field, the registration key is deleted.

If the user is defined in LDAP, then tracing is performed by the ICA management tool.

Automatically renewing a certificate

ICA certificates for users can be automatically renewed a number of days before they expire. The client initiates a certificate renewal operation with the CA before the expiration date is reached. If successful, the client receives an updated certificate.

To configure automatic certificate renewal:

1. From Menu, click Global Properties.
2. From the navigation tree, click Remote Access > Certificates.
3. Click Renew users internal CA certificates
4. Enter the number of days to Start the renewal process.

   This is the number of days before the certificate for the user expires and the client renews the certificate.

5. Click OK and publish the changes.
6. Install the Access Control Policy.
7. Tell the users to update the topology of the site.

Revoking certificates

The way in which certificates are revoked depends on whether they are managed internally or externally, using LDAP.

When a user is deleted, their certificate is automatically revoked. Certificates can be disabled or revoked at any time.

If the certificate is already active or was not completed by the user, you can revoke it by clicking Revoke in the Certificates tab of the User Properties window.

If users are managed in LDAP, certificates are revoked using the ICA management tool.

Tracing the Status of User's Certificate

The status of a user's certificate can be traced at any time in the Certificates tab of the user's Properties window. The status is shown in the Certificate state field. If the certificate has not been generated by the user by the date specified in the Pending until field, the registration key is deleted.

If the user is defined in LDAP, then tracing is performed by the ICA management tool.

Automatically Renewing a Users' Certificate

ICA certificates for users can be automatically renewed a number of days before they expire. The client initiates a certificate renewal operation with the CA before the expiration date is reached. If successful, the client receives an updated certificate.

To configure automatic certificate renewal:

1. From Menu, click Global Properties.
2. From the navigation tree, click Remote Access > Certificates.
3. Click Renew users internal CA certificates
4. Enter the number of days to Start the renewal process.

   This is the number of days before the certificate for the user expires and the client renews the certificate.

5. Click OK and publish the changes.
6. Install the Access Control Policy.
7. Tell the users to update the topology of the site.

Revoking Certificates

The way in which certificates are revoked depends on whether they are managed internally or externally, using LDAP.

For Internally Managed Users

When a user is deleted, their certificate is automatically revoked. Certificates can be disabled or revoked at any time.

If the certificate is already active or was not completed by the user, you can revoke it by clicking Revoke in the Certificates tab of the User Properties window.

For Users Managed in LDAP

If users are managed in LDAP, certificates are revoked using the ICA management tool.

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.

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.

Creating Remote Access VPN Certificates for Users

This section contains procedures for creating Remote VPN user certificates and sending them to end users.

There are two basic procedures for supplying remote access VPN certificates to users.

• Sending a P12 File:
  • The administrator creates a p12 certificate file and sends it to users.
  • The user saves the p12 file on the device and specifies the certificate using a remote VPN Client.
  • Users authenticate by entering a certificate password when starting a remote access VPN connection.
• Using a Registration key:
  • The administrator creates a registration key and sends it to the user.
  • The user enrolls the certificate by entering the registration key in a Remote Access VPN client. The user can optionally save the p12 file to the device. The user must do this in an administrator-defined period of time.
  • End users authenticate using this certificate. A password can also be required according to the security policy settings. If the user saves the p12 file to the device, a password is always necessary.

Enabling a User Certificate

To enable a user certificate:

1. In SmartConsole, from the Objects Bar click Users > Users.
2. Create a new user or double-click an existing user.

   The User Properties window opens.

3. From the navigation tree, click Encryption.
4. Click Edit.

   The IKE Phase 2 Properties window opens.

5. Click the Authentication tab and make sure that Public key is selected.
6. Click OK.
7. Publish the changes.

Creating a P12 Certificate File

After creating a user certificate, you must then make this certificate available to remote access users. Use this procedure to create a p12 certificate.

To create a p12 certificate file for remote access VPN users:

1. Create the user certificate.
2. In the User Properties window, from the navigation tree click Certificates.
3. In the Certificates page, click New.
4. Select Certificate file (.p12).
5. In the Certificate File (.P12) window, enter and confirm the certificate password.
6. Optional: Enter descriptive text in the Comment field.
7. Click OK and enter a path to save the p12 file.

   The new certificate shows in the Certificate. The status is set to Valid.

8. Click OK.
9. Send the .p12 file to the end user by secure email or other secure means.

Creating Certificate Registration Key

After creating a user certificate, you must then make this certificate available to remote access users. Use this procedure to create a certificate registration key that lets the user enroll the certificate for use with a device.

To create a certificate registration key:

1. Create the user certificate.
2. In the User Properties window, from the navigation tree click Certificates.
3. In the Certificates pane, click New.
4. Select Registration key for certificate enrollment.
5. In the Registration Key for Certificate Enrollment window, select the number of days before the certificate expires.
6. Click the email button to send the registration key to the user.
7. Optional: Enter descriptive text in the Comment field.
8. Click OK.

Instructions for End Users

Remote Access VPN users can use many different clients to connect to network resources. It is the administrator's responsibility to give appropriate instructions to end users to make sure that they successfully enroll the certificate.

The Creating Certificates section gives some general procedural guidelines that apply to many VPN clients. For detailed instructions, refer to the VPN client documentation.

Enrolling User Certificates - ICA Management Tool

To use the ICA Management to enroll a user certificate:

1. In SmartConsole, from the Objects Bar click Users > Users.
2. Create a new user or double-click an existing user.

   The User Properties window opens.

3. From the navigation tree click Encryption.
4. Click Edit.

   The IKE Phase 2 Properties window opens.

5. Click the Authentication tab, and select Public Key.
6. Click OK.
7. Publish the changes.
8. Enroll the user certificate using the ICA management tool.

Using Certificates Using Third Party PKI

Using third party PKI involves creating a certificate for the user and can also include a certificate for the Security Gateway.

You can use a third-party OPSEC PKI certificate authority that supports the PKCS#12, CAPI or Entrust standards to issue certificates for Security Gateways and users. The Security Gateway must trust the CA and have a certificate issued by the CA.

See Certificate Parsing to configure which information the gateway sends to the LDAP server to parse the certificate.

By default, for users managed on an LDAP server, the full distinguished name (DN) which appears on the certificate is the same as the user's name. But if the user is managed on the internal database, the user name and DN on the certificate will not match. For this reason, the user name in the internal database must be either the full DN which appears on the certificate or just the name which appears in the CN portion of the certificate. For example, if the DN which appears on the certificate is:

CN=John, OU=Finance, O=Widget Enterprises, C=US

The name of the user on the internal database must be either:

• John, or:
• CN=John, OU=Finance, O=Widget Enterprises, C=US

Note - The DN on the certificate must include the user's LDAP branch. Some PKI solutions do not include (by default) the whole branch information in the subject DN, for example the DN only includes the common name. This can be rectified in the CA configuration.

Configuring Third-Party PKI Certificates

To use a third-party PKI solution:

1. In SmartConsole, from the Objects Bar click Users > Users.
2. Create a new user or double-click an existing user.

   The User Properties window opens.

3. From the navigation tree, click Encryption.
4. Click Edit.

   The IKE Phase 2 Properties window opens.

5. Click the Authentication tab and select Public key.
6. Define the third party Certificate Authority as an object in SmartDashboard.
7. Optional - Generate a certificate for your Security Gateway from the third party CA.
8. Generate a certificate for the remote user from the third party CA. (Refer to relevant third party documentation for details.)
9. Transfer the certificate to the user.
10. In Global Properties > Authentication window, add or disable suffix matching.

    For users with certificates, it is possible to specify that only certificates with a specified suffix in their DN are accepted. This feature is enabled by default, and is required only if:

    • Users are defined in the internal database, and
    • The user names are not the full DN.

All certificates DN's are checked against this suffix.

Note - If an hierarchy of Certificate Authorities is used, the chain certificate of the user must reach the same root CA that the Security Gateway trusts.

Using a Pre-Shared Secret

When using pre-shared secrets, the remote user and Security Gateway authenticate each other by verifying that the other party knows the shared secret: the user's password.

To enable authentication with pre-shared secrets:

1. From Menu, click Global Properties.
2. From the navigation tree, click Remote Access >VPN Authentication.
3. In the Support authentication methods section, select Pre-Shared Secret (For SecuRemote client / SecureClient users).
4. Click OK.
5. Configure the Authentication settings for each applicable user:
   1. From the Objects Bar, double-click the user.

      The User Properties window opens.

   2. From the navigation tree, click Encryption.
   3. Select IKE and click Edit.

      The IKE Phase 2 Properties window opens.

   4. From the Authentication tab, click Password (Pre-Shared Secret).
   5. Enter and Confirm the Password (Pre-shared secret).
   6. Click OK.
6. Publish the changes.
7. Give the password to the user.

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 lets you control access privileges 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)

Sample workflow for RADIUS authentication configuration:

1. Create a RADIUS host object.
2. Configure the RADIUS server object settings.
3. Configure gateways to use RADIUS authentication.
4. Define user groups.
5. Configure RADIUS authentication settings for user.
6. Complete the RADIUS authentication configuration.

Configuring Authentication for NT groups and RADIUS Classes

To enable this group authentication feature:

1. Set the add_radius_groups property in objects.C to true.
2. Define a generic* profile, with RADIUS as the authentication method.
3. Create a rule in the Policy Rule Base whose "source" is this group of remote users that authenticate using NT Server or RADIUS.

Office Mode IP assignment file

This method also works for Office Mode. The group listed in the ipassignment.conf file points to the group that authenticates using NT group authentication or RADIUS classes.

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

Configuring RADIUS Objects

To create a new RADIUS host object:

1. In SmartConsole, the Objects tab, click New > Host.

   The New Host window opens.

2. Enter the Object Name and the IP Address of the new RADIUS host object, and click OK.
3. Install policy.

To configure the RADIUS server object settings:

1. In SmartConsole, the Objects tab, click New > More > Server > More > RADIUS.

   The RADIUS Server Properties window opens.

2. Configure new server properties:
   • Enter the Name of the RADIUS server object.
   • Select the RADIUS Host object.
   • Select the Service - RADIUS (on port 1645) or NEW-RADIUS (on port 1812 service).

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

   • Enter the Shared Secret that you configured on the RADIUS server
   • Select the version - RADIUS Ver. 1.0 Compatible (RFC 2138 compliant) or RADIUS Ver. 2.0 Compatible (RFC 2865 compliant)
   • Select the peer authentication Protocol - PAP or MS-CHAP v2
   • If you use more than one RADIUS authentication server, select the Priority
3. Click OK.

To configure a Security Gateway to use RADIUS authentication:

1. In SmartConsole, go to the Gateways & Servers view, right-click a Security Gateway object and select Edit.
2. In the gateway property window that opens, select Other > Legacy Authentication.
3. In the Enabled Authentication Schemes section, select RADIUS.
4. Click OK.

Configuring RADIUS Settings for Users

To define a RADIUS user group:

1. In SmartConsole, the Objects tab, click New > More > Users > User Group.

   The New User Group window opens.

2. Enter the name of the group in this format: RAD_<group_name>.

   Make sure the group is empty.

3. Click OK.
4. Install policy.

To configure RADIUS authentication settings for users with Security Gateway user accounts:

1. Create new internal user profile for each user. In SmartConsole, click Objects > New > More > User > User.

   The User Properties window opens.

2. In the General Properties tab, configure these settings:
   • Enter a User Name for the RADIUS server.
   • Set the Expiration Date.
3. In the Authentication tab, configure these settings:
   • Select RADIUS from the Authentication method list
   • From the RADIUS Server list, select the RADIUS object that you configured earlier
4. Click OK.

To configure RADIUS authentication settings for users without Security Gateway user accounts:

Create a new external user profile for each user in SmartDashboard, which opens from SmartConsole.

1. Open SmartDashboard:
   1. In SmartConsole, go to the Manage & Settings tab.
   2. Click Blades .
   3. Click one of the links for Configure in >SmartDashboard.
2. From the Network object tree, click the Users icon.
3. Right-click External User Profiles and select New External User Profile > Match all users (or Match by domain).

   If you support more than one external authentication scheme, set up External User Profiles with the Match By Domain setting.

   The External User Profile Properties window opens.

4. In the General Properties tab, configure these settings:
   • Enter a User Name for the RADIUS server. (When configuring Match all users as an External User Profile, the name "generic*" is automatically assigned)
   • Set the Expiration Date.
5. In the Authentication tab, configure these settings:
   • Select RADIUS from the Authentication Scheme list.
   • From the Select a RADIUS Server or Group of Servers list, select the RADIUS object that you configured earlier
6. Click OK.
7. Close SmartDashboard.
8. Install policy in SmartConsole.

Completing RADIUS Authentication Configuration

To complete the RADIUS authentication configuration:

1. In SmartConsole, create the required Access Control rules to allow access to users authenticated through the RADIUS server.
2. Make sure that communication between the firewall and the server is not NATed in the Address Translation Rule Base.
3. Save the changes.
4. Close all SmartConsole windows.
5. Use GuiDBedit Tool (see sk13009) to change the value of the add_radius_groups attribute from false to true.
6. Save and then close GuiDBedit Tool.
7. Open SmartConsole.
8. Install the policy.
9. 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 and clients.
2. Use GuiDBedit Tool (see sk13009) to modify the value of the firewall_properties attribute radius_groups_attr to the new RADIUS attribute.
3. Save the changes.
4. Close GuiDBedit Tool.
5. Open SmartConsole.
6. Install the policy.
7. 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.

Working with RSA Hard and Soft Tokens

If you use SecurID for authentication, you must manage the users on RSA's ACE management server. ACE manages the database of RSA users and their assigned hard or soft tokens. The client contacts the site's Security Gateway. The Security Gateway contacts the ACE Server for user authentication information. This means:

• The remote users must be defined as RSA users on the ACE Server.
• On the Security Gateway, the SecurID users must be placed into a group with an external user profile account that specifies SecurID as the authentication method.

SecurID Authentication Devices

Several versions of SecurID devices are available. The older format is a small device that displays a numeric code, called a tokencode, and time bars. The token code changes every sixty seconds, and provides the basis for authentication. To authenticate, the user must add to the beginning of the tokencode a special password called a PIN number. The time bar indicates how much time is left before the next tokencode is generated. The remote user is requested to enter both the PIN number and tokencode into the client connection window.

The newer format resembles a credit card, and displays the tokencode, time bars and a numeric pad for typing in the PIN number. This type of device mixes the tokencode with the entered PIN number to create a Passcode. The client requests only the passcode.

SoftID operates the same as the passcode device but consists only of software that sits on the desktop.

The Advanced view displays the tokencode and passcode with COPY buttons, allowing the user to cut and paste between softID and the client:

Enabling Hybrid Mode and Methods of Authentication

Hybrid mode allows the Security Gateway and remote access client to use different methods of authentication.

To enable Hybrid Mode:

1. From Menu, click Global Properties.
2. From the navigation tree, click Remote Access > VPN Authentication.
3. In the Support authentication methods section, click Support Legacy Authentication for SC (hybrid mode), L2TP (PAP), and Nokia clients (CRACK).
4. Click OK.
5. Publish the changes.

Defining User Authentication Methods in Hybrid Mode

To define the Hybrid Mode authentication for a user:

1. From the Objects Bar, double-click the user.

   The User Properties window opens.

2. From the navigation tree, click Authentication.
3. Select the Authentication Scheme.
4. Configure the necessary settings.
5. Click OK.
6. Publish the changes.
7. Give these credentials to the user.