In This Section: |
To manage your users and their access to resources, make sure to:
For handheld devices to connect to the gateway, these certificates must be properly configured:
Check Point Mobile Apps for mobile devices can use certificate-only authentication or two-factor authentication with client certificates and username/password. The certificate is signed by the internal CA of the Security Management Server that manages the Mobile Access Security Gateway.
Manage client certificates in Security Policies > Access Control > Access Tools > Client Certificates..
The page has two panes.
Note - If you use LDAP or AD, creation of client certificates does not change the LDAP or AD server. If you get an error message regarding LDAP/AD write access, ignore it and close the window to continue.
To create and distribute certificates with the client certificate wizard:
The Certificate Creation and Distribution wizard opens.
You can click Edit to view and change its details.
The Users page opens.
A progress window shows. If errors occur, an error report opens.
If the status of a certificate is Pending Enrollment, after you revoke it, the certificate does not show in the Client Certificate list.
To revoke one or more certificates:
After you revoke a certificate, it does not show in the Client Certificate list.
To create or edit an email template:
To edit a template: In the Email Templates for Certificate Distribution pane, double-click a template.
The Email Template opens.
For each link type, you select which elements will be added to the mail template:
You can select both QR Code and HTML link to include both in the email.
The text in Display Text is the text that shows on the link.
a. Certificate and Site Creation - For users who already have a Check Point app installed. When users scan the CR code or go to the link, it creates the site and registers the certificate.
b. Download Application - Direct users to download a Check Point App for their mobile devices.
Clone an email template to create a template that is similar to one that already exists.
To create a clone of an email template:
Remote Wipe removes the offline data cached on the user's mobile device.
When the administrator revokes the internal CA certificate, a Remote Wipe push notification is sent, if the Remote Wipe configuration for the client enables Remote Wipe by Push Notification. Remote Wipe is triggered when the device gets the push notification.
Note: Remote Wipe by Push Notification works by best effort. There is no guarantee that the gateway will send the notification, or that the client will get it successfully.
If the device does not get the Remote Wipe push notification, Remote Wipe is triggered when the client does an activity that requires connection to the gateway while using a revoked internal CA certificate.
Remote Wipe send logs:
This feature is supported in R77.10 and higher.
To configure Remote Wipe:
Syntax: cvpnd_settings <conf_file_path> {set|listAdd|listRemove}
<name> <value>
[expert@hostname:0]#
cvpnd_settings $CVPNDIR/conf/cvpnd.C set RemoteWipeEnabled {true|false}
Remote Wipe is enabled by default.
[expert@hostname:0]#
cvpnd_settings $CVPNDIR/conf/cvpnd.C set RemoteWipePushEnabled {true|false}
The Remote Wipe Push Notifications feature is enabled by default. For supported clients, see sk95587.
[expert@hostname:0]# cvpnd_settings $CVPNDIR/conf/cvpnd.C listAdd RemoteWipePushSupportedClientOS {iOS | Android}
[expert@hostname:0]# cvpnrestart
You must restart the cvpn service to apply the changes.
To see that your changes are applied, open the $CVPNDIR/conf/cvpnd.C
file in Read-Only mode.
To trigger Remote Wipe on a device:
cvpnd.C
is configured for Remote Wipe and, if you want, for Push Notifications.If you change the file, run: [expert@hostname:0]# cvpnrestart
To see Remote Wipe logs:
"Remote Wipe" AND blade:"Mobile Access" action:"Failed Log In"
You can filter these results for user DN, device ID, or certificate serial number.
For Capsule Workspace, many settings that affect the user experience on mobile devices come from the Mobile Profile. Each Mobile Access user group has an assigned Mobile Profile. By default, all users get the Default Profile.
The settings in the Mobile Profile include:
Manage the Mobile Profiles in Mobile Access tab > Capsule Workspace Settings.
To create or edit a Mobile Profile:
SmartDashboard opens and shows the Mobile Access tab.
The Mobile Profile opens.
A passcode lock protects Capsule Workspace in mobile devices. In each Mobile Profile, configure which Passcode Profile it uses. The profile includes the passcode requirements, expiration, and number of failed attempts allowed. The default passcode profiles are Normal, Permissive, and Restrictive. You can edit the default profiles and create new profiles.
To manage Passcode Profiles:
SmartDashboard opens and shows the Mobile Access tab.
A Passcode Profile includes these settings:
This feature sends push notifications for incoming emails and meeting requests on handheld devices, while the Mobile Mail app is in the background. The app icon shows the number of new, unhandled notifications. One user can get notifications for multiple devices.
Push notifications are disabled by default, but enabled when you run the Mobile Access First Time Wizard.
To use push notifications, the gateway must have connectivity to these URLs on ports 443 and 80:
Notes -
|
To enable push notifications:
Enable push notifications from the Mobile Access Wizard or from the Gateway Properties of each gateway.
Customize push notifications from the mobile profile in the Mobile Access tab > Capsule Workspace Settings.
You can customize templates for Mail and Meeting notifications.
To see the default notifications or change the notifications:
Make sure that the Exchange server can access the Mobile Access Portal.
On R77.20 and higher gateways, all confidential information between the Exchange server and the gateway uses encrypted SSL tunnels. Non-confidential information can use unencrypted HTTP connections.
You can configure all push notification communication to use SSL tunnels.
By default, Kerberos authentication is not enabled for Push Notification registration to the Exchange server. To enable it, follow the instructions in sk110629.
To force all push notification communication to go through SSL tunnels:
On R77.10 gateways, if the certificate on the Security Gateway is not trusted, import the certificate to the Exchange Server. This is not necessary on R77.20 and higher gateways. For details about how to get the gateway certificate, see sk98203.
To import a certificate to the Exchange server:
Add or Remove Snap-ins window opens.
The certificate is stored in Local computer and in Current user stores.
Use the Push Notification Status Utility to understand if your environment is configured correctly for push notifications.
Run $CVPNDIR/bin/PushReport
to generate a report that contains this data:
Output Example
[admin@gw-105 bin]# PushReport
This is your configuration status:
==================================
Topic Status Description
-----------------------------------------------------------------------------
License OK You are not using an evaluation license
Configuration OK Push is enabled in configuation
Connectivity OK You have connectivity to cloud
Callback URL OK Your callback push url is: http://
198.51.100.2/ExchangeRegistration. Make sure you have internal connectivity to this URL.
Use the fwpush commands to monitor, debug, and troubleshoot push notification activity.
Note - Users must first install the latest version of the Capsule Workspace app from the app store and connect to the site created on the gateway. |
To see failed batches, expired push notifications, and delayed push notifications, see: $FWDIR/log/pushd_failed_posts
Legal disclaimer on product functionality
Check Point uses Apple and Google services to deliver push notifications to iOS and Android devices. This is consistent with industry practice and similar to other applications vendors. Accordingly, Check Point assumes no liability in the event a notification is not sent or is not successfully pushed.
Information which is sent as a push notification passes through Check Point’s push service and the Apple or Google push service (according to the user’s device). Check Point does not keep, filter, or read any information that passes through. Check Point may review basic information to determine if a push notification reached its destination.
Check Point provides configuration options for the information sent as a push notification. The administrator can choose whether to set the subject, the sender, or the importance of any email, and can send the meeting location for meeting invitations.
Check Point will not be held liable for any loss of information that may result during the push notification process.
Hand-held devices cannot run Endpoint Security on Demand (ESOD) components. By default, ESOD is disabled for smartphones and tablets.
If your organization has ESOD enabled, mobile apps cannot access ESOD enforced applications.
Note - Mobile apps are not recognized by their HTTP User-Agent header. |
To change the ESOD setting on the Security Gateway:
cvpnd_settings $CVPNDIR/conf/cvpnd.C set MobileAppBypassESODforApps "true"
or "false"
cvpnrestart
$CVPNDIR/conf/cvpnd.C
file to all cluster members and restart the services on each.Support for Mobile Device Management (MDM) through third-party vendors enforces a unified security policy for devices that access internal resources. Only managed devices that comply with the organizational security policy can successfully connect and access your business resources.
This feature is supported in R77.10 and higher.
Check Point Apps establish a secure VPN connection to the corporate network through a Check Point Security Gateway. The Security Gateway queries the policy of the MDM server. The MDM server verifies the compliance level of employees' mobile devices when the VPN connection is established. The Security Gateway uses the MDM results to allow or block access, according to the device security and the user's permissions.
This feature is supported by Check Point Capsule Connect and Capsule Workspace clients.
For the most updated vendor information see sk98201.
To configure MDM Cooperative Enforcement with iOS 7, see sk98447.
Overview of the MDM Enforcement workflow:
Enable MDM Enforcement in a configuration file on the gateway. Then define global options and vendor-specific options.
To configure Mobile Device Management on a Security Gateway:
$FWDIR/conf/mdm.conf
MDM is disabled by default. You must change enabled
to 1
.
Global Options
mdm.conf Options |
Description |
---|---|
|
|
|
|
|
Defines behavior for cases of uncertainty, when an error occurs while checking MDM status. 0 - Drop VPN connections when an error occurs while checking MDM compliance status. 1 - Allow VPN connections when an error occurs while checking MDM compliance status. |
|
Maximum seconds allowed to determine device compliance status between the gateway and the MDM cloud service. Starts at device login. If passed, the action of |
|
Name of active third-party vendor, to test MDM compliance. You can configure multiple MDM vendors, but only one can be active. |
|
|
|
|
|
Local path on gateway of known CA certificate files. You can add more certificates to those that come with installation. Recommended: keep default. |
|
Allowed ciphers for HTTPS between gateway and MDM cloud services. Recommended: keep default. |
|
To use TLSv1 or SSL for HTTPS between gateway and MDM cloud services. Recommended: keep default. |
In mdm.conf, there is a block of options for each vendor. You can add more, if you have an understanding of the vendor's API and expertise with PHP programming. See Advanced Vendor Support.
For the most updated vendor information see sk98201.
If the global property password_is_obscured is enabled, obscure all parameters named password
in the Vendor Configuration blocks.
To get an obscured password string from your password:
[expert@hostname:0]# obfuscate_password
<password>The output is a string. For example: 33542b323a3528343640
password
value.You can add more vendors. This requires PHP programming skills and an understanding of the third-party MDM vendor's cloud API.
In these steps, we use "BestMDM" as the name of a fictional MDM vendor. BestMDM's API requires an XML request to be sent to their URL that includes credentials and the ID of the device. It returns an XML response with the device status and reason.
Example Request:
<request> <username>api_username</username> <password>api_password</password> <device>device_id</device> </request > |
Example Response:
<response> <status>compliance_status_code</status> <reason>reason</reason> </response > |
Example URL: https://bestmdm.com/api
We use these examples in the steps.
To add support for a new third-party vendor:
$CVPNDIR/phpincs/MDMVendors.php
For example:
|
For example:
|
Status Codes:
$mdm_data
as an array of data from mdm.conf and the device ID.
|
Important Notes:
password
parameter, and password_is_obscured=1
, the password is decrypted automatically. The function gets the clear text password.Example of $mdm_data:
With mdm.conf: |
$mdm_data value: |
---|---|
|
|
MDMVendors.php
.$FWDIR/conf/mdm.conf
.For example:
|
For example: :active_vendor (BestMDM)
To make sure that MDM functionality is configured correctly:
The Compliance Check, Information, and Reason values in the details of the device login, show data about MDM compliance status and requirements.
You can make sure the MDM configuration works without a device in hand, but it requires expert knowledge. You log in to a test web page and enter the WiFi MAC address of a real device. For security, the MDM test page is disabled by default.
To enable the test page:
$CVPNDIR/conf/includes/Login.location.conf
.Login.location.conf
to edit.[expert@hostname:0]# cvpnrestart
/Login/MDMProxy
path.For example: https://<gateway_hostname>/sslvpn/Login/MDMProxy
If there are issues for that device to access the third-party MDM vendor, the page shows diagnostics.
Login.location.conf
to the backup file.[expert@hostname:0]# cvpnrestart
To prevent security risks, always revert and close the test page.
Example Diagnostics:
Username
or Password
) are not configured correctly in $FWDIR/conf/mdm.conf
.This section describes system specific configuration required for iPhones, iPads, and Android devices. In some instances, end-user configuration is also required.
When you allow access to an ActiveSync application, users see the ActiveSync Setup item and can install the ActiveSync profile. This gives users access to their corporate email.
Note - If your ActiveSync application requires a client certificate to connect, the ActiveSync profile will work only if a client certificate is also required for Capsule Workspace.
The next procedure is for end users to configure on their devices. For all end user configuration procedures, see Instructions for End Users.
To connect to corporate email:
To resolve issues with client devices, tell the users to send you the logs. The iPhone or iPad must have an email account set up.
The next procedure is for end users to configure on their devices. For all end user configuration procedures, see Instructions for End Users.
To configure logs:
Before login, this is on the top right. After login, this is on the bottom right.
If you do not have an email account configured on the iPhone, a message shows that one must be configured. After this is done, you must open Check Point Mobile Access again.
When an email account is configured, the email page opens. The logs are attached.
Note - The email account that the iPhone uses to send the email is the default account. This might not be your organization's ActiveSync account. |
If the iPhone is not configured for a destination email address for logs, the email that opens has an empty To field. You can enter the destination address now, or set up a default destination address for Check Point Mobile logs.
Single Sign On (SSO) lets users in a session connect to the Mobile Access gateway, without authenticating when the client starts. If a user cannot access the gateway while SSO is enabled, disable it.
The next procedure is for end users to configure on their devices. For all end user configuration procedures, see Instructions for End Users.
To disable SSO on a client:
When browsing from the Android app to a server with an untrusted server certificate, you are denied access and you get this message:
"Some resources on this page reside on an untrusted host."
In some cases, such as in a staging or demo environment, you can enable browsing to servers with untrusted certificates.
Important - Disabling the server certificate validation in the client app is forbidden for production setups since it allows any 3rd-party to intercept the SSL traffic. |
For Androids, idle timeout cannot be modified or enforced by the device or the gateway.
The only timeout setting that applies to the device is the active session timeout. It is configured in SmartDashboard: Mobile Access Software Blade > Additional Settings > Session > Re-authenticate users every x minutes option. This setting indicates the maximum session length. When this period is reached, the user must log in again. For example, if re-authentication is set to 120 minutes, a user will need to log in again after 2 hours in an active session.
To resolve issues with client devices, tell the users to send you the logs.
The next procedure is for end users to configure on their devices. For all end user configuration procedures, see Instructions for End Users.
To send logs:
Give these instructions to end users to configure their mobile devices to work with Mobile Access.
Do these procedures on your iPhone/iPad so you can work with Mobile Access.
Before you start, make sure that your administrator gives you:
Important - Do only the procedures that your network administrator has instructed you to do. |
To connect to the corporate site:
To connect to corporate email:
To configure logs:
Before login, this is on the top right. After login, this is on the bottom right.
If you do not have an email account configured on the iPhone, a message shows that one must be configured. After this is done, you must open Check Point Mobile Access again.
When an email account is configured, the email page opens. The logs are attached.
Note - The email account that the iPhone uses to send the email is the default account. This might not be your organization's ActiveSync account. |
If the iPhone is not configured for a destination email address for logs, the email that opens has an empty To field. You can enter the destination address now, or set up a default destination address for Check Point Mobile logs.
To disable SSO on a client:
To disable the server certificate validation for Web applications:
To disable the server certificate validation for Web applications:
Do these procedures on your Android device so you can work with Mobile Access.
Before you start, make sure that your administrator gives you:
Important - Do only the procedures that your network administrator has instructed you to do. |
To connect to the corporate site:
To send logs:
To transfer the client certificate to the 3rd party mail client:
If the Export Certificate option is disabled, contact the system administrator.
A window shows: Export succeeded. Certificate password is: _______
You can customize client authentication, device requirements, certificate details, and ActiveSync behavior. Use the CLI commands explained here to change the configuration file:$CVPNDIR/conf/cvpnd.C
Note - Disable Link Translation Domain on Mobile Access gateways before you connect to them with the Android client. |
To apply changes:
Restart the Mobile Access services: cvpnrestart
If you use a cluster, copy the $CVPNDIR/conf/cvpnd.C
file to all cluster members and restart the services on each.
To set Mobile Access attributes:
cvpnd_settings set <attribute_name> "<value>"
To get the current value of an attribute:
cvpnd_settings get <attribute_name>
Attribute |
Description |
|
---|---|---|
ActiveSyncAllowed (true) |
If access to ActiveSync applications is allowed. |
|
ActiveSyncExchangeServerAuthentication |
Method of forwarding authentication from the Mobile Access gateway to the internal Exchange server. Valid values: |
|
MobileAppAllowActiveSyncProfileConfig (true) |
Make the automatic ActiveSync Profile configuration for iPhones and iPads available to users. |
|
MobileAppMinRequiredClientOSVersion (3.1) |
Minimum operating system version for iPhones and iPads. If a client fails this requirement, user sees |
|
MobileAppAndroidMinRequiredClient |
Minimum operating system version for Android. If a client fails this requirement, user sees |
|
MobileAppMinRecommendedClient |
Recommended operating system version for iPhones and iPads. If a client fails this recommendation, user sees a message but usage continues. |
|
MobileAppAndroidMinRecommendedClient |
Recommended operating system version for Android. If a client fails this recommendation, user sees a message but usage continues. |
|
MobileAppMinRequiredClientAppVersion (1.3) |
Minimum App version required for iPhones and iPads. |
|
MobileAppAndroidMinRequiredClient |
Minimum App version required for Android. |
|
MobileAppMinRecommendedClient |
Recommended App version for iPhones and iPads. |
|
MobileAppAndroidMinRecommendedClient |
Recommended App version for Android. |
|
MobileAppMinClientOSVersionForProfile |
Minimum operating system version for iPhone and iPad to configure ActiveSync with the app. If you want data encryption, change this value from the default to |
|
MobileAppAndroidMinClientOSVersionFor |
Minimum operating system version for Android to configure ActiveSync with the app. |
|
MobileAppBypassESODforApps (false) |
When true, mobile apps are allowed access to MAB applications whose protection level requires ESOD compliance. Mobile apps can always access the MAB portal. |
|
MobileAppAllowClientCertExport (false) |
When true, allows mobile app clients to export their client certificates to other apps and devices. See Using 3rd Party Android Mail Clients. |