In This Section: |
Authentication is a key factor in establishing a secure communication channel among Security Gateways and remote clients. Various authentication methods are available, for example:
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 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).
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.
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.
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:
The User Properties window opens.
The IKE Phase 2 Properties window opens.
Hybrid mode allows the Security Gateway and remote access client to use different methods of authentication.
To enable Hybrid Mode:
To define the Hybrid Mode authentication for a user:
The User Properties window opens.
These user authentication methods are supported for remote access.
SoftID (a software version of RSA's SecurID) and various other One Time Password cards and USB tokens are also supported.
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:
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:
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.
Step 1: Create a RADIUS host object.
Step 2: Configure the RADIUS server object settings.
Step 3: Configure gateways to use RADIUS authentication.
Step 4: Define user groups.
Step 5: Configure RADIUS authentication settings for the user.
Step 6: Complete the RADIUS authentication configuration.
Step |
Description |
---|---|
1 |
Create a RADIUS host object.
|
2 |
Configure the RADIUS server object settings.
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. |
3 |
Configure gateways to use RADIUS authentication.
|
4 |
Define user groups.
|
5 |
Configure RADIUS authentication settings for the user. |
5a |
For users with Security Gateway user accounts: Create new internal user profile for each user.
|
5b |
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.
|
6 |
Complete the RADIUS authentication configuration.
|
To use a different attribute instead of the class attribute:
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):
To enable this group authentication feature:
add_radius_groups
property in objects.C
to true
.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
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.
For more information see: LDAP and User Management in the R80.20 Security Management Administration Guide.
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.
To let older clients connect to the R80.10 gateway:
If this is not selected, older clients cannot connect to the gateway.
To change the authentication method for older clients:
The Single Authentication Clients Settings window opens.
You can configure DynamicID for older clients manually in GuiDBedit Tool (see sk13009) or dbedit (see skI3301). See sk86240.
To block newer clients from using the authentication method defined for older clients:
The Single Authentication Clients Settings window opens.
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.
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.
Basic DynamicID configuration is shown here. For Advanced configuration options, see the R80.20 Mobile Access Administration Guide.
To configure global DynamicID settings that all gateways use:
SmartDashboard opens and shows the Mobile Access tab.
To configure DynamicID settings for a specified gateway:
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. |
The email address of the user as found in Active Directory or in the local |
|
$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:
https://api.example.com/http/sendmsg?api_id=$APIID&user=
$USERNAME&password=$PASSWORD&to=$PHONE&text=$MESSAGE
mail:TO=$EMAIL;SMTPSERVER=smtp.example.com;FROM=sslvpn@example.com;
BODY=$RAWMESSAGE
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
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:
This is the number of days before the certificate for the user expires and the client renews the certificate.
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.
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.
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:
This is the number of days before the certificate for the user expires and the client renews the certificate.
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.
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.
Check Point's Internal Certificate Authority (ICA) offers two ways to create and transfer certificates to remote users:
This method is especially suitable for geographically spaced-remote 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.
To enable a user certificate:
The User Properties window opens.
The IKE Phase 2 Properties window opens.
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:
The new certificate shows in the Certificate. The status is set to Valid.
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:
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.
To use the ICA Management to enroll a user certificate:
The User Properties window opens.
The IKE Phase 2 Properties window opens.
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:
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.
To use a third-party PKI solution:
The User Properties window opens.
The IKE Phase 2 Properties window opens.
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:
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.
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 VPN Software Blades.
Configure login options from: Gateway Properties > VPN Clients > Authentication
If Mobile Access is enabled, you can also configure login options from:
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:
The default login options are:
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.
Notes:
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.
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:
The Authentication Factor window opens.
To permanently delete a Login option: