User Authentication in Mobile Access

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.

  For more about User Certificates, see the R76 VPN Administration Guide.

• 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 R76 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 SecureID, see the R76 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
• Secure Container Mail

To require client certificates for mobile devices:

1. Double-click the Mobile Access Security Gateway.
2. From the navigation menu, select Mobile Access > Authentication.
3. Make sure that the Authentication Method is one of these options:
   • Username and password
   • RADIUS
   • SecurID
4. Select Require client certificate when using ActiveSync applications or Secure Container Mail.
5. 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:

1. The internal users database.
2. 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.
3. 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:

1. Obtaining the SMS provider credentials and/or email settings.
2. Configuring the Phone Directory
3. Basic SmartDashboard Configuration of DynamicID
4. 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)

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:

1. Log in to the Mobile Access gateway using a secure console connection.
2. Change to Expert mode: Type expert and then the expert mode password.
3. Backup $CVPNDIR/conf/SmsPhones.lst
4. 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:

1. From the Mobile Access tab, select Authentication.

   The Authentication page opens.

2. Select Challenge users to provide the DynamicID one time password.
3. 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.checkpoint.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.checkpoint.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.

1. In the SMS Provider Account Credentials section, enter the credentials received from the SMS provider:
   • Username
   • Password
   • API ID (optional)
2. For additional configuration options, click Advanced.
3. 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.
4. Install the policy.

Testing Two-Factor Authentication

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

1. Browse to the URL of the Mobile Access portal.
2. Log in as a user. Supply the gateway authentication credentials.
3. Wait to receive the DynamicID code on your mobile communication device or check your email.
4. 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.

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:

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

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:

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:

1. Set up basic two-factor authentication.
2. For each Security Gateway, go to Gateway Properties > Mobile Access > Authentication.
3. 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.
4. Repeat step 3 to step 4 for all other gateways.
5. 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:

1. 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.
2. Configure the Protection Level.
   • In the Mobile Access tab > Authentication, select User must successfully authenticate via SMS.
3. Assign the protection level to Mobile Access applications that require two-factor authentication.
4. 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, once configured in SmartDashboard, DynamicID is enforced for all authentication types. Therefore the default enforceSMSforAuthTypes parameter in the cvpnd.C configuration file is:

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

DynamicID Authentication for Certain Methods and by Protection Level

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

For example: You have configured the Restrictive Protection Level to require DynamicID for users authenticating with Certificate authentication, but you have removed CERT from the enforceSMSforAuthTypes parameter. In this case, DynamicID authentication will not be required for anyone using Certificate authentication, even when accessing an application assigned to the Restrictive 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.

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. By default, user requests are denied if sent from a different IP address than that used for login.

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

1. 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.
2. When a session is disconnected by another user and Citrix is being used, the Citrix window remains open, while the session is disconnected.
3. 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.