User Authentication in Mobile Access

In This Section:

User Authentication to the Mobile Access Portal

To enter the Mobile Access portal and get access to its applications, users defined in SmartDashboard must authenticate to the Security Gateway. Authentication ensures that a user is who he or she claims to be. Users authenticate using one of these Authentication schemes:

Check Point Password - Users are challenged to enter a password and user name that are stored in the internal Security Gateway database.
Personal Certificates - Digital Certificates are issued by the Internal Certificate Authority or by a third party OPSEC certified Certificate Authority.
RADIUS Server - Remote Authentication Dial-In User Service (RADIUS) is an external 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 gateway. RADIUS Servers and RADIUS Server Group objects are defined in SmartDashboard.
For more about configuring a Security Gateway to use a RADIUS server, see the R77 Security Gateway Technical Administration Guide.
SecurID - SecurID is a proprietary authentication method of RSA Security. An external SecurID server manages access by changing passwords every few seconds. Each user carries a SecurID token, a piece of hardware that is synchronized with the central server and displays the current password. The Security Gateway forwards authentication requests by remote users to the ACE/Server.
For more about configuring a Security Gateway to use SecurID, see the R77 Security Gateway Technical Administration Guide.

A user who tries to authenticate with an authentication scheme that is not configured for the Mobile Access gateway will not be allowed to access resources through the gateway.

Optionally, two-factor authentication with DynamicID One Time Password can also be required as a secondary authentication method. When this is configured, users who successfully complete the first-phase authentication are challenged to enter an additional credential: a DynamicID One Time Password (OTP). The OTP is sent to their mobile communications device (such as a mobile phone) through SMS or directly to their email account.

Configuring Authentication

Permitted authentication schemes must be configured for each Security Gateway.

On the Security Gateway, you can configure authentication in one of two places:

In the Gateway Properties window of a gateway in Mobile Access > Authentication. If you select an authentication method on this page, that is the method that all users must use to authenticate to Mobile Access. You can configure other authentication methods that users must use for different blades on different pages.
On this page you can also configure per gateway settings for Two- Factor Authentication with a DynamicID One Time Password.

The default authentication scheme is Username and Password.
In the Gateway Properties window of a gateway in Legacy Authentication. In the Legacy Authentication page, you can allow access to users authenticating with different authentication methods. Authentication using Client Certificates from the Internal Certificate Authority is enabled by default in addition to the selected method.

In the Mobile Access tab, select Authentication to show an overview of the Mobile Access Security Gateways and their authentication schemes.

On this page you can also configure global settings for Two- Factor Authentication with a DynamicID One Time Password that will be used for all gateways that do not have their own DynamicID settings.

Requiring Certificates for Mobile Devices

You can configure a protection level for Mobile Access applications that only lets mobile devices use the application if they authenticate with a client certificate. It is necessary to define the Mobile Access Authentication settings on each Mobile Access Security Gateway. This feature has an effect on these applications:

ActiveSync applications
Capsule Workspace Mail

To require client certificates for mobile devices:

Double-click the Mobile Access Security Gateway.
From the navigation menu, select Mobile Access > Authentication.
Make sure that the Authentication Method is one of these options:
- Username and password
- RADIUS
- SecurID
Select Require client certificate when using ActiveSync applications or Capsule Workspace Mail.
Install the policy.

How the Gateway Searches for Users

If you configure authentication for a blade from the main Security Gateway Legacy Authentication page, the Security Gateway searches for users in a standard way when they try to authenticate. The gateway searches:

The internal users database.
If the specified user is not defined in this database, the gateway queries the User Directory (LDAP) servers defined in the Account Unit one at a time, and according to their priority.
If the information still cannot be found, the gateway uses the external users template to see if there is a match against the generic profile. This generic profile has the default attributes applied to the specified user.

If you configure an authentication method for a specific blade, the gateway searches for users according to the user groups that are used for authorization in that blade.

For example, in Mobile Access, the gateway looks at the Mobile Access policy to see which user groups are part of the policy. When the gateway tries to authenticate a user, it starts to search for users in the databases related to those user groups.

In IPsec VPN, the gateway looks at the Remote Access VPN Community to see which user groups are included. It starts to search for users in the databases related to those user groups.

A search based on the authentication scheme is faster, with better results. You can have users with the same user name in unrelated groups. The gateway will know which user is relevant for the blade based on the user groups.

Two-Factor Authentication with DynamicID

Two-factor authentication is a system where two different methods are used to authenticate users. Using two-factors as opposed to one delivers a higher level of authentication assurance.

In the first phase of the authentication, users must authenticate to the Mobile Access portal using either:

The authentication method configured in Gateway Properties > Mobile Access > Authentication. If an authentication method is configured on this page, users must use that method and not other methods configured on a different Authentication page of the Security Gateway.
One of the authentication methods that is enabled in the Gateway Properties > Other > Legacy Authentication page of the Security Gateway.

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.

How DynamicID Works

When logging in to the Mobile Access portal, users see an additional authentication challenge such as:

Please type the verification code sent to your phone.

Users enter the one time password that is sent to the configured phone number or email address and they are then admitted to the Mobile Access portal.

On the User Portal sign in screen, the I didn’t get the verification code link shows. If the user does not receive an SMS or email with the verification code within a short period of time, the user can click that button to receive options for resending the verification code.

Administrators can allow users to select a phone number or email address from a list. Only some of the phone number digits are revealed. Users can then select the correct phone number or email address from the list and click Send to resend the verification code. By default, users can request to resend the message three times before they are locked out of the Portal.

Match Word

The Match Word feature ensures that users can identify the correct DynamicID verification code in situations when they may receive multiple messages. Users are provided with a match word on the Login page that will also appear in the correct message. If users receive multiple SMS messages, they can identify the correct one, as it will contain the same match word.

The SMS Service Provider

The DynamicID messages are sent by the SMS service provider that Mobile Access is configured to work with. DynamicID can be configured to work with any SMS provider that is able to accept an HTTP request and translate it into an SMS and that can receive email messages.

If DynamicID is configured to work with email only, an SMS Service Provider is not necessary.

To access the SMS service provider, the proxy settings that are configured in the SmartDashboard Mobile Access tab, Additional Settings > Network Elements > HTTP Proxy page are used. If none is defined, no proxy is used.

Whichever provider you work with, in order for the SMS messages to be sent to users, valid account details must be obtained from the provider and be configured in Mobile Access.

SMS Authentication Granularity

Two-factor authentication with DynamicID can be made a requirement for logging in to the gateway. Alternatively, DynamicID authentication can be made a requirement for accessing particular applications. This flexibility allows for varying security clearance levels.

Making two-factor authentication with DynamicID a requirement for accessing specific applications is done by configuring a Protection Level to require two-factor authentication, and associating the Protection Level with Mobile Access applications.

In an environment with multiple Mobile Access gateways, making two-factor authentication a requirement for logging into a particular gateway is done by configuring two-factor authentication for that gateway.

Basic DynamicID Configuration for SMS or Email

The workflow for basic configuration of two-factor authentication via DynamicID is:

Obtaining the SMS provider credentials and/or email settings.
Configuring the Phone Directory
Basic SmartDashboard Configuration of DynamicID
Testing DynamicID Two-Factor Authentication

Obtaining the SMS Provider Credentials

Get these required SMS service provider settings from your SMS provider.

A URL in the format specified by the SMS provider or a valid email address.
Account credentials:
- User name
- Password
- API ID (optional and may be left empty)

Note - If DynamicID is configured to work with email only, an SMS Service Provider is not necessary.

Configuring the Phone Directory

The default phone number and email search method is that the gateway searches for phone numbers or email addresses in user records on the LDAP account unit, and then in the phone directory on the local gateway. If the phone number configured is actually an email address, an email will be sent instead of an SMS message. The phone number and email search method can be changed in the Phone Number or Email Retrieval section of the Two-Factor Authentication with DynamicID - Advanced window.

Configuring Phone Numbers or Email Addresses in LDAP

If users authenticate via LDAP, configure the list of phone numbers on LDAP by defining a phone number or email address for each user. By default, Mobile Access uses the Mobile field in the Telephones tab. If the phone number configured is actually an email address, an email will be sent instead of an SMS message.

Configuring Phone Numbers or Email Addresses on Each Security Gateway

Configure the list of phone numbers or email addresses on each Mobile Access gateway. For a Mobile Access cluster, configure the directory on each cluster member.

To configure a list of phone numbers on a gateway:

Log in to the Mobile Access gateway using a secure console connection.
Change to Expert mode: Type expert and then the expert mode password.
Backup $CVPNDIR/conf/SmsPhones.lst

Edit $CVPNDIR/conf/SmsPhones.lst, and add to it a list of user names and phone numbers, and/or email addresses. The list must be followed by a blank line. Use this syntax:


`<user name \| Full DN> <phone number \| email address>`
Parameter	Meaning
user name or Full DN	Either a user name or, for users that log in using a certificate, the full DN of the certificate.
phone number	All printable characters can be used in the phone number, excluding the space character, which is not allowed. Only the digits are relevant.
email address	A valid email address in the format user@domain.com

Example of acceptable ways to enter users and their phone numbers or email addresses in $CVPNDIR/conf/SmsPhones.lst

bob +044-888-8888
jane tom@domain.com
CN=tom,OU=users,O=example.com +044-7777777
CN=mary,OU=users,O=example.com +mary@domain.com

Configuring Multiple Phone Numbers

You can let users choose from multiple phone numbers when resending the verification code.

To configure choice of numbers:

Enter one number in the LDAP directory in the Mobile field and one or more in the gateway configuration file:
$CVPNDIR/conf/SmsPhones.lst
Enter multiple phone numbers separated by white space in the gateway configuration file:
$CVPNDIR/conf/SmsPhones.lst

For example, user_a 917-555-5555 603-444-4444

Basic SmartDashboard Configuration of DynamicID

Configure the Authentication settings to make two-factor authentication necessary for all mobile devices.

To configure DynamicID settings in SmartDashboard:

From the Mobile Access tab, select Authentication.
The Authentication page opens.
Select Challenge users to provide the DynamicID one time password.
Fill in the SMS Provider and Email Settings field using one of the following 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
The following 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.

In the SMS Provider Account Credentials section, enter the credentials received from the SMS provider:
- Username
- Password
- API ID (optional)
For additional configuration options, click Advanced.
Configure the Mobile Access Security Gateway to let computers and devices use DynamicID.
1. Double-click the Mobile Access Security Gateway.
2. From the navigation tree, select Mobile Access > Authentication.
3. In the Two-Factor Authentication section, configure these settings:
  - For a Security Gateway that uses the global authentication settings, select Global settings.
  - For a Security Gateway that uses different authentication settings, select Custom settings.
  - For mobile devices, select Allow DynamicID for mobile devices.
4. Click OK.
Install the policy.

Testing Two-Factor Authentication

To test the two-factor authentication via DynamicID, after completing the configuration:

Browse to the URL of the Mobile Access portal.
Log in as a user. Supply the gateway authentication credentials.
Wait to receive the DynamicID code on your mobile communication device or check your email.
Enter the DynamicID code in the portal.

You should now be logged in to the Mobile Access portal.

Advanced Two-Factor Authentication Configuration

Advanced options for two-factor authentication with DynamicID are available on the SmartDashboard Users and Authentication > Authentication > Authentication to gateway > Two-Factor Authentication with DynamicID -Advanced page.

You can also configure advanced options for two-factor authentication per gateway on the Mobile Access Gateway Properties window, in the Additional Settings Authentication > Advanced page.

The following sections explain the fields.

DynamicID Authentication Enforcement

Optional
Allow users to log in but deny access to applications that require DynamicID authentication: When users log in, they are given the option to "Skip" the two-factor authentication. Users who choose skip are allowed to log in, but are denied access to applications that require two-factor authentication.
Mandatory
Users must successfully authenticate using DynamicID in order to log in.

DynamicID Message

Message text to be sent to the user
By default, the text of the message is "Mobile Access DynamicID one time password:". The message can contain the template fields shown in the following table to include the user's name and prompt users to use enter a One Time Password.

For example, the message could say: $NAME, use the verification code $CODE to enter the portal.

Parameter	Meaning
`$NAME`	User name used in the first phase of authentication to the portal.
`$CODE`	Replaced with the One Time Password. By default, $CODE is added to the end of the message.

DynamicID Settings

Length of one time password is 6 digits by default
One time password expiration (in minutes) is 5 minutes by default. Ensure there is a reasonably sufficient time for the message to arrive at the mobile communication device or email account, for the user to retrieve the password, and to type it in.
Number of times users can attempt to enter the one time password before the entire authentication process restarts. By default the user has 3 tries.

Display User Details

In the portal, display the phone number or email address that received the DynamicID. By default, the phone number to which the SMS message was sent is not shown.

Country Code

Default country code for phone numbers that do not include country code. The default country code is added if the phone number stored on the LDAP server or on the local file on the gateway starts with 0.

Phone Number or Email Retrieval

Active Directory and Local File
Try to retrieve the user details from the Active Directory user record. If unsuccessful, retrieve from the local file on the gateway. The LDAP account unit is defined in the Users and Authentication > Authentication > LDAP Account Units page of the SmartDashboard Mobile Access tab. The phone directory on the local gateway is stored at $CVPNDIR/conf/SmsPhones.lst.
Active Directory Only
Retrieve phone numbers from Active Directory user record without using the local file on the gateway. The LDAP account unit is defined in the Users and Authentication > Authentication > LDAP Account Units page of the SmartDashboard Mobile Access tab.
Local File Only
Retrieve the user details from the local file on the gateway. The phone directory on the local gateway is stored at $CVPNDIR/conf/SmsPhones.lst.

Configuring Resend Verification and Match Word

The DynamicID troubleshooting and match word features are configured in GuiDBedit, Check Point’s database tool that is a standard component of the SmartConsole. To run GuiDBedit, access:

C:\%ProgramFiles%\CheckPoint\SmartConsole\R77\PROGRAM\GuiDBedit.exe

The GuiDBedit table to edit depends on the Two Factor Authentication with SMS One Time Password (OTP) setting that you configured in SmartDashboard in the Mobile Access Gateway Properties page > Authentication.

If your DynamicID One Time Password settings are global across all of your gateways (use the global settings configured in the Mobile Access tab is selected), in GuiDBedit select Other > Mobile Access Global Properties.
If your DynamicID One Time Password settings are configured for a specific gateway (This gateway has its own two-factor authentication settings is selected), in GuiDBedit select network_objects and then select the specific gateway you want to edit.

The following table shows the DynamicID features that can be configured, and where in GuiDBedit to configure them.

Configuring DynamicID Settings in GuiDBedit

Feature	Field Name/s to Edit	Value Options
Match Word	use_message_matching_helper	true: match word provided false: match word not provided (default)
Resend message	Enable_end_user_re_transmit_message	true: enable resend SMS feature (default) false: disable resend SMS feature
Display multiple phone numbers	enable_end_user_select_phone_num	true: enable option to choose from multiple phone numbers or email addresses when resending the verification code (default) false: one phone number or email address from the LDAP server or local file is used automatically without choice
Conceal displayed phone numbers	Edit both: reveal_partial_phone_num number_of_digits_revealed	true: conceal part of the phone number or email address (default) false: display the full phone number or email address 1-20: Choose the amount of digits to reveal (default is 4)

After editing the values in GuiDBedit, save the changes, connect to SmartDashboard, and install the policy.

Configuring the Number of Times Messages are Resent

By default, users can request to resend the verification code message three times by clicking the I didn’t get the verification code link before they are locked out of the Mobile Access Portal. The number of times the message can be resent is configured using the cvpnd_settings command from the Mobile Access CLI in expert mode.

The instructions below relate to actually resending the verification code message. The number of times users can try to input the verification code is configured in SmartDashboard in the Two Factor Authentication Advanced window.

To change the number of times the verification code message can be resent to 5, run:

cvpnd_settings $CVPNDIR/conf/cvpnd.C set smsMaxResendRetries 5

You can replace "5" with any other number to configure a different amount of retries.

After making the changes, run cvpnrestart to activate the settings.

If the Mobile Access gateway is part of a cluster, be sure to make the same changes on each cluster member.

Two-Factor Authentication per Gateway

Successful two-factor authentication can be made a requirement for logging on to some but not all Mobile Access gateways.

There are two possible approaches:

Globally on, with custom settings per gateway: Turn on two-factor authentication globally, and then for each Mobile Access gateway, configure custom settings: either turn off the feature, or configure gateway-specific settings.
Globally off, with custom settings per gateway: Turn off two-factor authentication globally, and then for selected Mobile Access gateways, turn it on, while configuring custom settings for those gateways.

You can also let mobile devices use two-factor authentication with DynamicID to connect to this Mobile Access Security Gateway.

To configure two-factor authentication Globally on, with custom settings per gateway:

Set up basic two-factor authentication.
For each Security Gateway, go to Gateway Properties > Mobile Access > Authentication.
Do one of these options:
- To use the global settings - Select Global settings and the global settings are used from the Authentication to Gateway page of the Mobile Access tab. This is the default.
- To turn off two-factor authentication for the gateway - Select Custom Settings for this Gateway and click Configure. In the window that opens, do not select the check box. This turns off two-factor authentication for this gateway.
- To activate two-factor authentication for the gateway with custom settings - Select Custom Settings for this Gateway and click Configure. In the window that opens, select the check box. You must then configure custom SMS Provider Credentials for this gateway. Optionally, configure Advanced options.
Repeat step 3 to step 4 for all other gateways.
Install the policy. Select Policy > Install.

Two-Factor Authentication per Application

Two-factor authentication can be made a requirement for accessing particular applications. This is done by configuring a Protection Level to require two-factor authentication, and associating the Protection Level with Mobile Access applications.

To configure two-factor authentication per application:

Configure basic two-factor authentication.
1. Configure the phone directory.
2. Configure the application settings in Mobile Access tab > Authentication.
3. Configure the Mobile Access Security Gateways to let the mobile devices use DynamicID.
Configure the Protection Level.
- In the Mobile Access tab > Authentication, select User must successfully authenticate via SMS.
Assign the protection level to Mobile Access applications that require two-factor authentication.
Install the policy.

Changing the SMS Provider Certificates and Protocol

By default, it is recommended to use a secure (https) protocol for communication with the SMS provider. Mobile Access also validates the provider server certificate using a predefined bundle of trusted CAs.

If your SMS provider uses a non-trusted server certificate you can do one of the following:

Add the server certificate issuer to the trusted CA bundle under $CVPNDIR/var/ssl/ca-bundle/ and run:
$CVPNDIR/bin/rehash_ca_bundle
Ignore the server certificate validation by editing $CVPNDIR/conf/cvpnd.C and replacing the SmsWebClientProcArgs value with ("-k").

If your SMS provider is working with the non-secure http protocol, edit the file $CVPNDIR/conf/cvpnd.C and replace the SmsWebClientProcArgs value with ("").

Two-Factor Authentication for Certain Authentication Methods

You can configure DynamicID to be enforced only if the primary authentication method was of a certain type. For example, you can configure DynamicID to be required if someone authenticates using a user name and password, but not if they use RADIUS authentication.

By default, DynamicID is enforced for all authentication types when it is configured in SmartDashboard. The default enforceSMSforAuthTypes parameter in the cvpnd.C configuration file is:

:enforceSMSforAuthTypes (
: (USER_PASS)
: (CERT)
: (RADIUS)
: (SECURID)
)

To enforce DynamicID only for specified authentication types, remove the authentication types for which DynamicID enforcement is not required. For example, to require DynamicID when a user authenticates with a certificate or user name and password, but not with SECURID or RADIUS authentication, edit the lines:

:enforceSMSforAuthTypes (
: (USER_PASS)
: (CERT)
)

DynamicID Authentication for Specific Methods and by Protection Level

If in SmartDashboard you configured a Protection Level to require two-factor authentication with DynamicID, the cvpnd.C configuration file settings override the Protection Level Authentication settings in SmartDashboard.

For example: You configured the Restrictive Protection Level to require DynamicID for Certificate authentication, but you removed CERT from the enforceSMSforAuthTypes parameter. DynamicID authentication will not be required for anyone using Certificate authentication, even when accessing an application assigned to the Restrictive Protection Level.

Multiple Realms

This feature gives support for multiple authentication realms in the Mobile Access Portal.

After installation, if you log in to the gateway portal, the login page appears as if there are no multiple realms. After you configure new realms, the login page will have a new drop-down list. Users will select the authentication realm they want to use.

Best Practice - We recommend that you:

Open SmartDashboard and configure authentication on this realm before you continue.
Review the built-in realms in GuiDBedit before you create a new realm.

Use GuiDBedit to add authentication realms. Open GuiDBedit on the Security Management Server, and configure each Mobile Access Security Gateway in the environment with the next procedures.

This feature is supported in R77.10 and higher.

Workflow

To use multiple authentication realms:

Configure multiple realms.
Apply configuration to Mobile Access gateways.
Optional: Set SMS secondary authentication on the Mobile Access-enabled gateway (see Two-Factor Authentication with DynamicID in the R77 Mobile Access Administration Guide).
Optional: Configure the SMS enforcement for each authentication realm.

Creating New Realms

These instructions are for GuiDBedit. Remember to do them for all Mobile Access Security Gateways.

To add multiple realms:

Open Tables > Network Objects > network_objects, and select a Mobile Access Security Gateway.
Find the realms_for_blades field.
It is easiest to find by searching for ssl_vpn realm.
Right-click realms_for_blades and select Add.
Enter a name for the new realm.
The realm name must not include spaces.

When you create a new realm, you cannot use a name that is used by a built-in realm. Reserved names for authentication realms are:
- ssl_vpn
- vpn
- mobile_realm
- active_sync_realm
- active_sync_secure_realm
Click OK.
The new authentication realm is in the realms_for_blades container.

Configuring Authentication Schemes

When you add an authentication realm, the most important property to customize is the authentication scheme. The fields of this property set the types of authentication, their order, and other basic values. For example, you can configure a realm to accept certificate authentication and username authentication, with certificates being first.

This procedure is done in GuiDBedit, after you add a new realm. Do it again for each authentication scheme that will be in the realm.

To configure an authentication scheme:

Expand realms_for_blades > the realm you added > authentication.
Right-click auth_schemes and select Add.

In the window that opens, set the basic properties of the authentication scheme.

Field

Value

Index

When you have multiple authentication schemes in one realm, this value sets the priorities. Zero (0) is first.

If certificate authentication is included in the authentication schemes, it must be first (Index = 0).
SMS cannot be included in the authentication schemes. Configure it in SmartDashboard. It will always be last.

Object

Must stay realm_auth_scheme

Name

Enter a name for the scheme.
It must not be the same name as a realm that exists and it must not include spaces.

Click OK.
The scheme comes into view as a new object, with its default fields.
Right-click the auth_scheme field and select Edit.
Enter a display name.

Choose an authentication scheme.

Field	If selected, follow up with:
certificate	Make sure Index is 0.
defined_on_user
radius	Edit radius_server and select the server.
securid
user_pass
os_password, tacacs	Do not select these schemes. They do not work with Mobile Access.

Enter a display name.
If the authentication scheme is certificate, right-click certificate_parsing_rules and set it to realm_certificate.

Defining Fetch Directories

If you use only the built-in realms, do not define fetch directories. These are automatically generated by the configuration of each Mobile Access Software Blade. If you make changes to the realms_for_blades > directory properties, your changes will be overwritten by the built-in automatic calculations.

If you create new realms, you can define fetch directory options. When you create a new realm, the fetch_type attribute is set to all by default. During authentication, the system will try to find the user in defined directories: internal, ldap, and generic. This is recommended for most environments, but you can change it.

To change the fetch directories:

Open the directory field.
Change the value of fetch_type to fetch_options.
Properties of the fetch_options attribute come into view. Each is a boolean for the user directory type.
Make sure the fetch_options value is realm_fetch_options.

Under fetch_options, set the associated fetch directory properties to true:

Valid Value

Description

If true, do:

do_ldap_fetch

Use LDAP user directories to lookup authentication credentials.

Edit ldap_au and choose the ldap account unit reference.

(You can use SmartDashboard to configure a new AU.)

do_internal_fetch

Use user accounts defined on SmartDashboard.

do_generic_fetch

User RADIUS servers named "generic" for external user directories.

Edit radius and choose the RADIUS server.

Edit the display_string.
This is the name of the authentication method that users will see. This attribute is mandatory.

Applying New Realms

After you create the realms and define the options for each Mobile Access Security Gateway, do this to apply the realms.

To apply new realms:

Save the changes.
Close GuiDBedit.
Open SmartDashboard.
Install the policy on the Mobile Access Security Gateways.
When the policy is installed, the gateways get the new realms and their configurations.
Add the new realms to the static configuration of each Mobile Access Security Gateway.

Adding Realms to Static Configuration of Gateways

You must configure the Mobile Access Security Gateways to complete the procedure of applying new realms. When you configure realms for the gateways, use the name of the realm that you created when you chose Add. Do not use the display name.

To add realms to gateway configuration:

In each gateway, in expert mode, run:
[expert@hostname:0]# cvpnd_settings $CVPNDIR/conf/cvpnd.C listAdd portalRealmNames <realm_name>

For example, to add a realm named my_new_realm:
[expert@hostname:0]# cvpnd_settings $CVPNDIR/conf/cvpnd.C listAdd portalRealmNames my_new_realm
Run: [expert@hostname:0]# cvpnrestart

Troubleshooting

Symptom

Cause and Solution

The ssl_vpn default realm is not displayed to the user.

If you add new realms, the default realm is not displayed as an authentication type.

To use the ssl_vpn realm with the new realms, add it to the static configuration of the Security Gateways.

Added realms are not displayed to users.

Make sure the change is applied:

Open $CVPNDIR/conf/cvpnd.C in a text editor.
Find portalRealmNames.
Make sure all the authentication realms for remote access are listed here.
Example:
:portalRealmNames (
: (my_new_realm)
: (my_new_realm_2)
: (etc…)
)

Users are not able to log in.

There may be a mismatch between realm lists on the gateways and the server.

Make sure cvpnd is running:
hostname> ps -ef | grep cvpnd
If cvpnd is not running, make sure that the list of realms in each Security Gateway $CVPNDIR/conf/cvpnd.C matches the list in $FWDIR/database/authentication_objects.C on the Security Management Server.

Two-Factor Authentication for Certain Authentication Methods

By default, DynamicID is enforced for all authentication types when it is configured in SmartDashboard. The default enforceSMSforAuthTypes parameter in the cvpnd.C configuration file is:

:enforceSMSforAuthTypes (
: (USER_PASS)
: (CERT)
: (RADIUS)
: (SECURID)
)

:enforceSMSforAuthTypes (
: (USER_PASS)
: (CERT)
)

DynamicID Authentication for Specific Methods and by Protection Level

Session Settings

Once authenticated, remote users are assigned a Mobile Access session. The session provides the context in which Mobile Access processes all subsequent requests until the user logs out or the session ends due to a time-out.

This section discusses Mobile Access settings and best practices for Mobile Access sessions. These settings are configured in SmartDashboard from the Mobile Access tab by selecting Additional Settings > Session.

Session Timeouts

Once authenticated, remote users work in a Mobile Access session until they log out or the session terminates. Security best practices provide for limiting the length of active and inactive Mobile Access sessions to prevent abuse of secure remote resources.

Note - Mobile Access uses the system time to keep track of session timeouts. Changing the system time may disrupt existing session timeouts. Therefore, it is recommended to change the system time during low activity hours.

Mobile Access provides two types of session timeouts, both of which are configured in SmartDashboard from the Mobile Access tab by selecting Additional Settings > Session.

Re-authenticate users every is the maximum session time. When this period is reached, the user must log in again. The default value is 60 minutes. Changing this timeout affects only future sessions, not current sessions.
Disconnect idle sessions after is the disconnection time-out if the connection remains idle. The default value is 15 minutes. When users connect via SSL Network Extender, this timeout does not apply.

Roaming

The Roaming option allows users to change their IP addresses during an active session.

Note - SSL Network Extender users can always change IP address while connected, regardless of the Roaming setting.

Tracking

Configure Mobile Access to log session activity, including login attempts, logouts, timeouts, activity states and license expiration warnings.

Securing Authentication Credentials

Having multiple users on the same machine accessing the Mobile Access portal can be a security hazard. A user logged in to the Mobile Access portal can open a new browser window and get the access of the earlier session. Then the user can browse directly to the Mobile Access portal without entering the login credentials again.

To make sure authentication credentials are not stolen by others, recommend to users that they log off or close all browser windows when done using a browser.

Simultaneous Logins to the Portal

Having a single user logged in to Mobile Access more than once, from two different locations for example, is a potential security issue.

Simultaneous login prevention enables a gateway to automatically disconnect a remote user who is logged more than once.

When simultaneous login prevention is enabled, and a user's authentication information used to log in from two different computers, only the later login is considered legitimate, and the earlier session is logged out.

Configuring Simultaneous Login Prevention

Simultaneous login prevention is configured in SmartDashboard from the Mobile Access tab by selecting Additional Settings > Session.

The options are:

User is allowed several simultaneous logins to the Portal
Simultaneous login detection is disabled. This is the default option.
User is allowed only a single login to the portal selected
Inform user before disconnecting his previous session not selected
The earlier user is disconnected and the later user is allowed. The earlier user is logged out. For Mobile Access portal users, the following message appears: "Your Mobile Access session has timed out. would you like to sign in again now?". The later user is not informed that an earlier user is logged in.
User is allowed only a single login to the portal selected
Inform user before disconnecting his previous session selected
The later user is informed that an earlier user is logged in, and is given the choice of canceling the login and retaining the existing session, or logging in and terminating the existing session. If the existing session is terminated, the user is logged out with the message: "Your Mobile Access session has timed out. would you like to sign in again now?".

Tracking of Simultaneous Logins

To track simultaneous login events, select All Events in the Tracking section of the Additional Settings > Session page.

When the gateway disconnects a user, the gateway records a log of the disconnection, containing the connection information of both logins.

All disconnect and connect events create a corresponding entry in the traffic log. The following values of the authentication status field relate to simultaneous logins:

Success - User successfully logged in. Existing active sessions were terminated.
Inactive - User successfully authenticated, but existing sessions need to be terminated prior to logging on.
Disconnected - An existing user session has been terminated because the same user has logged on to another session.

Simultaneous Login Issues

The following issues may arise in connection with simultaneous login:

Endpoint Connect- Simultaneous Login Issues

For Endpoint Connect users, Mobile Access does not prevent simultaneous login. This is equivalent to the User can have several simultaneous logins to the portal option. An Endpoint Connect user cannot log out another user with the same user name, and cannot be logged out by another user with the same user name.

SecureClient Mobile - Simultaneous Login Issues

With User can have only a single simultaneous login to the portal selected and Inform user before disconnecting previous sessions not selected SecureClient Mobile users can be logged off by another user, and can log off other users.

However, the Inform user before disconnecting his previous session option does not work, because no message can be sent to those users. User can be logged off, but cannot log off other users.

Other Simultaneous Login Issues

When a session is disconnected by another user and SSL Network Extender application mode client is being used, the SSL Network Extender window remains open, while the session is disconnected. Similarly, when a session is disconnected by another user and Secure Workspace is being used, Secure Workspace remains open, while the session is disconnected.
When a session is disconnected by another user and Citrix is being used, the Citrix window remains open, while the session is disconnected.
All current sessions are deleted when changing the section from User can have only a single login to the Portal to User is allowed several simultaneous logins to the Portal.

Top of Page

Download PDF

Send Feedback