In This Section: |
Giving remote users access to the internal network exposes the network to external threats. A balance needs to be struck between connectivity and security. In all cases, strict authentication and authorization is needed to ensure that only the right people gain access to the corporate network. Defining an application requires deciding which internal LAN applications to expose to what kind of remote user.
Mobile Access provides the remote user with access to the various corporate applications, including, Web applications, file shares, Citrix services, Web mail, and native applications.
A file share is a collection of files, made available across the network by means of a protocol that enables actions on files, including opening, reading, writing, and deleting files across the network.
To create a new File Share Application:
The File Share Application window opens.
Go to the General Properties page of the File Share Application object. Name is the name of the SmartDashboard object.
This page lets you configure the file shares that users are authorized to access. These settings take effect whenever a user attempts access, no matter what interface is used, whether by manually typing a path in the portal, browsing using the file viewer, clicking a user-defined file favorite, or clicking the predefined file favorite path defined by the administrator in the Link in Portal page.
My_Share
. Use only the name of a share, such as My_share
, $$user
, or My_share$
, without any slashes. Do not specify a subdirectory inside a share. The $$user
variable represents the name of the currently logged-in user. This variable provides personalized authorization for users. If $$user
is defined as a file share, then if the user currently logged-in is alice,
alice
will be allowed access to the share named alice
defined on the server, such as \\myserver\alice
. If you configure two or more overlapping file share applications (for example, one for Any Share and one for a specific share on the same host), the application settings that are in effect are undefined.
This page allows you to configure one predefined favorite link. This link is displayed in the Mobile Access portal. By clicking the link the user is able to directly access the specified path. Note that you must authorize access to this location in the Authorized Locations page.
$$user
, which represents the user name of the currently logged-in user. If more than one link is configured with the same (case insensitive) name, only one of them will be shown in the portal.$$user
, which represents the user name of the currently logged-in user. For example, a path that is defined as \\host\Pub\users\$$user
appears for user alice
as \\host\Pub\users\alice
and for user Bob
as \\host\Pub\users\Bob
.Note - The host
defined here is the same host that is defined in the Authorized Locations page. The IP address of the host is resolved by the DNS Server that is defined on Mobile Access (not by the Mobile Access management).
$$user
, which represents the user name of the currently logged-in user. The text appears automatically when the user holds the cursor over the link. It disappears when the user clicks a mouse button or moves the cursor away from the link.To configure Single Sign On:
Prompt the users for their credentials and store them for future use
Security Requirements for Accessing this Application allows you to:
You can configure personalized user locations that use the login name of the currently logged in user. To do this, use the $$user
variable wherever you need to specify the name of the user. The $$user
variable is resolved during the Mobile Access session to the login name of the currently logged-in user.
For example, a UNC file path that is defined as \\host\Pub\$$user
is resolved for user Alice as \\host\Pub\Alice
and for user Bob as \\host\Pub\Bob
.
Protection Levels are predefined sets of security settings that offer a balance between connectivity and security. Protection Levels allow Mobile Access administrators to define application protections for groups of applications with similar requirements.
Mobile Access comes with three default Protection Levels - Normal, Restrictive, and Permissive. You can create additional Protection Levels and change the protections for existing Protection Levels.
You can include Protection Levels in the definition of most Mobile Access application types. Each application can have a Protection Level associated with it. A single Protection Level can be assigned for all native applications.
When you define an application, in the Protection Level page of the application object, you can choose:
Security Requirements for Accessing this Application:
To access the Protection Level page from the Mobile Access tab:
SmartDashboard opens and shows the Mobile Access tab.
The Protection Levels window opens, and shows the General Properties page.
To access the Protection Level page from a Mobile Access application:
The Protection Levels window opens, and shows the General Properties page.
To configure the settings for a Protection Level:
A Web application can be defined as a set of URLs that are used in the same context and are accessed via a Web browser, for example, inventory management or human resource management.
Mobile Access supports browsing to websites that use HTML and JavaScript.
Browsing to websites with VBScript, Java, or Flash elements that contain embedded links is supported using SSL Network Extender, by defining the application as a native application.
Additionally, some sites will only work through a default browser, and therefore cannot be defined as a Web application. If that is the case, use a native application.
It is possible to configure a Web Application with a specific type as iNotes (Domino Web Access) application or as an Outlook Web Access application.
IBM iNotes (previously called Lotus Domino Web Access) is a Web application that provides access to a number of services including mail, contacts, calendar, scheduling, and collaboration services.
Domino Web Access requires its files to be temporarily cached by the client-side browser. As a result, the endpoint machine browser caching settings of the Mobile Access Protection Level do not apply to these files. To allow connectivity, the cross site scripting, command injection and SQL injection Web Intelligence protections are disabled for Domino Web Access.
Note - To make iNotes work through the Mobile Access portal, you must work with Hostname Translation. |
These iNotes features are not supported:
Outlook Web Access (OWA) is a Web-based mail service, with the look, feel and functionality of Microsoft Outlook. Mobile Access supports Outlook Web Access versions 2000, 2003 SP1, 2007, 2010, 2013, and 2016.
You can use SmartConsole to create and configure the settings for all the Mobile Access application objects. However, there are some Mobile Access settings that you can configure only from SmartDashboard.
To create a new Mobile application in SmartDashboard:
SmartConsole opens and shows the Mobile Access tab.
To create a new Mobile application in SmartConsole:
The Mobile application window opens.
Use the General Properties page to configure the basic settings for the Web Application.
Domino Web Access requires its files to be temporarily cached by the client-side browser. As a result, the endpoint machine browser caching settings of the Mobile Access Endpoint Compliance Profile do not apply to these files.
To allow connectivity, the cross site scripting, command injection and SQL injection Web Intelligence protections are disabled for Domino Web Access.
Use the Authorized Locations page to define the locations that can access the Web Application.
For an application that is defined as an Outlook Web Access application, the following are set as the allowed directories:
When two or more overlapping applications are configured (for example, one for any directory and one for a specific directory on the same host), it is undefined which application settings take effect. If one of the overlapping applications is OWA or iNotes, it will take precedence.
/finance/data/
. The paths can include $$user, which is the name of the currently logged-in user. On R77.20 and higher gateways you can select which SSL version to use with HTTPS. Select an option from the list. The default is Automatic.
Use the Link in Portal page to configure a link to the Web Application in the Mobile Access user portal.
$$user
, which represents the user name of the currently logged-in user. If more than one link is configured with the same (case insensitive) name, only one of them will be shown in the portal.$$user
, which represents the user name of the currently logged-in user. For example, a URL that is defined as http://host/$$user
appears for user aa
as http://host/aa
and for user bb
as http://host/bb
.$$user
, which represents the user name of the currently logged-in user. The text appears automatically when the user holds the cursor over the link. It disappears when the user clicks a mouse button or moves the cursor away from the link.Use the Protection Level page to choose the protection level for Web applications, and configure how browser caching is configured.
Security Requirements for Accessing this Application:
Browser Caching on the Endpoint Machine - Control caching of web application content in the remote user's browser.
Protection Levels let administrators prevent browsers from caching Web content. The caching feature in most browsers presents a security risk because cache contents are easily accessible to hackers.
When the Prevent caching of all content option is enabled, users may not be able to open files that require an external viewer application (for example, a Word or PDF file). This requires the user to first save the file locally.
To let users open external files:
cvpnstop
$CVPNDIR/conf/http.conf
CvpnCacheGroups
directives related to Microsoft Office documents.cvpnstart
Use the Link Translation page to configure how the Web Application converts the internal URLs to valid links for the Internet.
Mobile Access applications can be configured to differ depending on the user name of the currently logged-in user. For example, portal links can include the name of the user, and a file-share can include the user's home directory. For this purpose, the $$user
directive is used. During a Mobile Access session, $$user
resolves to the login name of the currently logged-in user.
For such personalized configurations, insert the $$user
string into the relevant location in the definitions of Web applications, file shares, and native applications.
For example, a Web application URL that is defined as http://host/$$user
appears for user aa
as http://host/aa
and for user bb
as http://host/bb
.
If the user authenticates with a certificate, $$user
resolves during the user's login process to the user name that is extracted from the certificate and authorized by the directory server.
For its use in configuring File Shares, see Using the $$user Variable in File Shares.
To complete the configuration, add the Web application to a policy rule and install policy from SmartConsole.
For unified Access Control policy, see Configuring Mobile Access in the Unified Policy.
For legacy policy, see Creating Mobile Access Rules in the Legacy Policy.
It is possible to define an HTTP or HTTPS proxy server per Web application. This configuration allows additional control of access to Web resources allowed to users. For configuration details see sk34810.
For proprietary Web applications that do not support a standard HTTP authentication method, the CvpnAddHeader
directive can be used to forward end-user credentials (user name and IP address) that are carried in the HTTP header.
To configure Mobile Access to automatically forward a customized HTTP header, with a specified value, such as the user name or the client IP address:
$CVPNDIR/conf/http.conf
. For a Mobile Access cluster, edit all members.CvpnAddHeader
according to the following syntax:CvpnAddHeader "customized_header_name" "customized_header_value"
You can use the following two macros for the customized_header_value
string:
$CLIENTIP
, which is resolved to the actual IP address of the end-user's client machine.$USER NAME
which is resolved to the user name entered as a credential in the login pageExamples:
CvpnAddHeader "CustomHTTPHeaderName" "MyCustomHTTPHeaderValue"
CvpnAddHeader "CustomIPHeader" "$CLIENTIP"
CvpnAddHeader "CustomUsernameHeader" "$USER NAME"
Mobile Access contains various features to make working with Web Applications efficient and secure. Some of these are described in the following sections.
The Reuse TCP Connections feature enhances performance by letting the network reuse TCP connections that would otherwise be closed. To enable Reuse TCP Connections, make a change to the gateway configuration files.
Best Practice - We strongly recommend that you back up configuration files before you make changes. |
In the General Properties page of a Web application, there is a section called Application Type. In this section, you can define the application as having a specific type, either Domino Web Access or Outlook Web Access.
In previous versions, if you chose one of these Application Type options, the TCP connections for the application are closed after each request. However, if you enable Reuse TCP Connections, the connections are reused. This leads to a boost in performance as the three-way handshake does not have to be renewed and the optimized authorization cache feature can be fully utilized.
By default, Reuse TCP Connections is enabled.
To turn off Reuse TCP Connections:
$CVPNDIR/conf/http.conf
configuration file from:
|
to:
|
cvpnrestart
to activate the settings.If your Mobile Access gateway is part of a cluster, make the same changes on each cluster member.
Mobile Access lets you validate website security certificates, and either warn the user about problems, ignore any problems, or block websites with certificate problems.
By default, Website Certificate Verification is set to “monitor” this means that a record is entered in SmartLog and there is no effect on end-users. The setting can also be set to "warn" so that users are alerted to any potential security issues and can then decide what steps to take. The setting can also be set to “block,” which blocks any website that has a problem with its SSL server certificate, or “ignore", to ignore any issues with a website’s security. All settings create a record in SmartLog except for "ignore".
You must restart Mobile Access services after changing the website certificate verification setting.
You can configure Website Certificate Verification per gateway and per application.
Website Certificate Verification is configured in GuiDBedit Tool (see sk13009).
To change the Website Certificate Verification default behavior for Web applications on the gateway:
The default setting is monitor.
If your internal web servers do not use a commonly known certificate (such as an internal CA), then either change the default setting, or add a trusted Certificate Authority for Website certification to Mobile Access.
If the Mobile Access gateway is part of a cluster, be sure to make the same changes on the cluster object table.
To change the Website Certificate Verification default behavior per Web application:
You can add specific Certificate Authorities that Mobile Access does not recognize by default, such as your organization’s internal CA, to your trusted certificates. The list of default Certificate Authorities recognized by Mobile Access is the same as the list recognized by common browsers. To add CAs to this list, copy the certificate to a .pem
file and then move the file to your Mobile Access gateway. If your Mobile Access gateway is part of a cluster, be sure to make the same changes on each cluster member.
The procedure for saving a trusted certificate as a .pem file is similar for all browsers and versions with slight differences. Below is an example procedure, using Internet Explorer 7.0.
To save a trusted certificate in .pem format using Internet Explorer 7.0:
The Certificate Export Wizard opens.
To move the CA Certificate to the Mobile Access Gateway:
$CVPNDIR/var/ssl/ca-bundle/
rehash_ca_bundle
The Certificate Authority should now be accepted by the Mobile Access gateway without any warnings. You do not need to restart Mobile Access services for the change to take effect.
To delete a Certificate Authority from your trusted Certificate Authorities:
$CVPNDIR/var/ssl/ca-bundle/
file of the Mobile Access gateway.rehash_ca_bundle
You do not need to restart Mobile Access services for the change to take effect.
Link Translation is the process by which Mobile Access converts internal URLs to public URLs that are valid on the Internet. In this way internal resources become accessible through all internet browsers.
Mobile Access converts HTTP requests into secure HTTPS requests and changes the port to 443. To accomplish this, Mobile Access translates the source URL into an HTTPS URL that routes traffic to its destination through the Mobile Access gateway. The translated URL is returned to the browser and is shown to users.
Mobile Access supports different methods of Link Translation:
A translated URL appears to users in their browser differently, for the different Link Translation methods.
Method |
Translated |
---|---|
UT |
|
HT |
Note that the seemingly random character string, |
PT |
|
Client-side |
|
You can configure Link Translation to meet the requirements of the application (a web application or a Citrix service) or of the gateway through which the applications are accessed. For example, you can configure one Mobile Access application to work with URL Translation, while all other applications supplied by the gateway use Path Translation.
Path Translation (PT) is selected by default for newly installed gateways.
To configure PT as default method for gateways:
The gateway properties window opens and shows the General Properties page.
To configure PT as default method for an application:
The Web Application window opens.
The Link Translation page of the Mobile Access application opens.
URL Translation is supported by all versions of gateways.
To configure UT as default method for gateways:
The gateway properties window opens and shows the General Properties page.
To configure UT as default method for an application:
The Web Application window opens.
The Link Translation page of the Mobile Access application opens.
Hostname Translation enhances security by replacing the destination host name with a seemingly random character string in the URL, as it appears in the client browser.
You must configure the DNS server to resolve wildcard hostnames, to enable HT.
Warning - If the DNS server is not configured to resolve wildcard Mobile Access host names, users will be unable to connect to Mobile Access, because the portal changes to a sub-domain: If you use Hostname Translation as your method for link translation, users must enter an FQDN as the portal URL and not an IP address. |
To configure the DNS server for HT:
*.domain
For example, assume ssl.example.com
is the gateway. Configure the DNS to resolve *.ssl.example.com
to the gateway IP address. This wildcard includes all sub-domains of the parent domain, such as a.ssl.example.com
and b.ssl.example.com
.
ssl.example.com
) as a separate DNS record, to resolve Mobile Access IP address.This lets users access the Mobile Access portal directly, with its FQDN.
To configure HT as default method for gateways:
The gateway properties window opens and shows the General Properties page.
If this message appears, clear Hostname Translation, for now:
Hostname Translation requires Portal URL to be defined in the following format: 'https://hostname/'
To configure HT as default method for an application:
The Web Application window opens.
The Link Translation page of the Mobile Access application opens.
A Link Translation domain for Web applications:
Configure which domains use link translation in SmartDashboard > Mobile Access tab > Additional Settings > Link Translation > Link Translation Domains.
For R77.30 gateways, to enable this feature, you must install the R77.30 Add-on.
This option is not supported in gateways lower than R77.30.
To manually configure domains to translate:
The options are:
With Client-Side Link Translation with wrapped applications, Check Point Mobile App clients are responsible for link translation for specified, wrapped applications. These applications are wrapped in a security container that gives them secure access to network resources and prevents data leakage.
Wrapped applications are only available with mobile devices and do not show in the Mobile Access portal.
To use Client-Side Link Translation with wrapped applications, see the App Wrapping Guide.
These Link Translation configuration tips apply to Web applications.
document.cookie=Name=Value; domain=.example.com,
The client browser cannot send the cookie to Mobile Access and the Web server if Mobile Access is not located under the domain .example.com.
Note that domain cookies created in HTTP headers are supported, if they are not manipulated by JavaScript code.
https://<obscured destination host name>.<Mobile Access FQDN>/path
The maximum number of characters in each part of the host name (between https:// and the /path) is limited to 63 (see RFC 1034 - Domain names - concepts and facilities). Therefore, the entire internal host name, including the protocol and the port, must not exceed 63 characters.
Unticketed Mode
In the recommended Unticketed Mode scenario:
Ticketed Mode
In the Ticketed Mode scenario:
The user logs into the Citrix Web Interface server and is assigned a secure ticket by the Secure Ticket Authority. This ticket allows the user to access the Presentation server once it is verified by the Mobile Access Web Security Gateway.
You do not need to use Secure Ticketing authority (STA) servers because Mobile Access implements its own STA engine.
To configure a new Citrix Service:
The Citrix Services window opens.
The server certificate for Mobile Access must be based on a FQDN (Fully Qualified Domain Name) and issued to the Mobile Access FQDN. For example www.sample.com.
Before you configure Citrix Services, change the Mobile Access server certificate to one that was issued to the FQDN. This is necessary to comply with the Citrix standards for server certificates. Additionally, end-users must browse to Mobile Access using the FQDN that is routable from their network.
Note - Make sure that the certificate is installed on the server. |
If your Web Interface server is configured to deploy ICA Web clients and the Mobile Access server certificate is issued by a private CA, the certificate's public key must be installed on the client side browser for the ICA Web Client to function properly. The Mobile Access certificate public key is located under: $CVPNDIR/var/ssl/server.crt
http
or https
, as required. Other services are NOT supported.Note - Mobile Access implements its own Secure Ticketing authority (STA) engine. STA servers are not necessary. |
To get the host name or IP address:
To get the STA ID:
The STA ID is shown in the Enter the STA ID field.
Go to the MetaFrame servers page of the Citrix Service object. In this page you can allow access to all Presentation Servers, or restrict access to defined MetaFrame servers.
If you select Restrict access to these servers only:
Use the XenApp Servers page to configure access to the XenApp Servers.
Note - If you select Restrict access to these servers only,
If you do not, Mobile Access may not authorize the connection. (The XenApp server configuration affects one of the parameters in the ICA file that is received by the client).
Single Sign On increases application security.
To configure Single Sign On:
Configure the sign on method for the application.
Security Requirements for Accessing this Application lets you:
Note - The Citrix architecture requires ICA files and ActiveX executables to be temporarily cached by the client-side browser. As a result, Mobile Access's Protection Level settings do not apply to these files.
Note - Mobile Access implements its own Secure Ticketing authority (STA) engine. STA servers are not necessary.
To get the hostname or IP address:
To get the STA ID:
The STA ID is shown in the Enter the STA ID field.
To complete the configuration, add the Citrix Service to a policy rule and install policy from SmartConsole.
For unified Access Control policy, see Configuring Mobile Access in the Unified Policy.
For legacy policy, see Creating Mobile Access Rules in the Legacy Policy.
Mobile Access supports built-in Web mail. Web mail provides a simple way for remote users, through a web browser interface, to access their email. Employees can access their email from any computer that has access to the Internet, such as a computer in a library, or Internet cafe. There is no need to install special email or remote access software. This is helpful for employees who work outside the office on a regular basis.
Note - The traffic log does not show actions done by the user through the Web mail interface. |
Mobile Access also supports the IBM Lotus Domino Web Access (DWA, formerly known as iNotes) and Outlook Web Access (OWA). DWA and OWA are configured in Mobile Access as Web Applications.
Remote users login to Mobile Access and authenticate themselves in order to gain access to the portal. They can then click a link to access the Web mail application. Mobile Access can be configured to reuse the login credentials when authenticating to the IMAP account on the mail server. If the reused credentials are incorrect, Mobile Access again presents the user with a login page. Valid credentials are saved for future logins.
Once authenticated to the mail application, users can:
Mobile Access provides a Web front-end for any email application that uses the IMAP protocol for incoming mail, and SMTP for outgoing mail.
Email stored on the IMAP server is manipulated through the browser interface without having to transfer the messages back and forth. Users can connect to several mail servers depending on their authorization.
To configure a new Web Mail application:
The Web mail service window opens.
Configure the Single Sign On settings for the Web Mail Service.
Security Requirements for Accessing this Application lets you:
To complete the configuration, add the Web Mail application to a policy rule and install policy from SmartConsole.
For unified Access Control policy, see Configuring Mobile Access in the Unified Policy.
For legacy policy, see Creating Mobile Access Rules in the Legacy Policy.
By default, the contact search in Web Mail applications works only for internal users that are defined on the Mobile Access gateway. To enable search on contacts that are defined on an LDAP server, see sk34997.
Native applications are not clientless. They require the SSL Network Extender client on the endpoint machine.
If an internal application is hosted on a server inside the organization, using a DNS Name object in the definition of the Mobile Access application makes it possible to change the IP address of the server without having to change the definition of the host object in the Mobile Access application.
For example, if "myhost.example.com" is used in the definition of a Mobile Access application, Mobile Access resolves the IP address of "myhost" when authorizing access to the application.
If an internal application is hosted on multiple replicated servers, a single DNS Name object can be used in the definition of the Mobile Access application, instead of having to individually define each host.
The DNS server that is specified on Mobile Access resolves the DNS names. To set or change the DNS server, use the sysconfig
command.
A DNS name can have a number of aliases. For example, www.example.com
, www.example.co.uk
and www.example.co.fr
could be aliases of the same DNS name.
In the definition of the DNS Name object, use the format "a.b
… x.y.z
", where each section of the DNS name is demarcated by a period. For example, mail.example.com
or www.example.co.uk
.
Wildcards can be used at the beginning of a domain name, but not at the end. For example, *.example.com
includes www.example.com
and mail.example.com
. On the other hand, www.example.*
is NOT valid.
DNS objects are used when defining hosts for Mobile Access Web applications, file share applications, Citrix services, and Web mail services. They are also used when configuring support for Hostname Translation.
DNS Name objects cannot be used in the Security Rule Base.
The DNS server that resolves the IP addresses of the DNS Name objects must be defined in one of these locations:
|
Using the Console |
Using the Web User Interface |
---|---|---|
SecurePlatform |
Run Select Domain Name Servers. Configure the DNS. |
Go to the SecurePlatform Administration Portal in your browser. Go to the Network > DNS page. Configure the DNS. |
Gaia |
Run Optional: Run Run |
Connect your browser to the Gaia WebUI. Go to the Interface Management > Hosts and DNS page. Configure the DNS. |
To create a new DNS Name object:
SmartDashboard opens and shows the Mobile Access tab.
The DNS Names window opens.
The DNS Name window opens.
The DNS Names window opens.
The Edit DNS Name window opens.
The DNS Name window closes.
Mobile Access applications can be configured to differ depending on the user name of the currently logged-in user. For example, portal links can include the name of the user, and a file-share can include the user's home directory. For this purpose, the $$user
directive is used. During a Mobile Access session, $$user
resolves to the login name of the currently logged-in user.
For such personalized configurations, insert the $$user
string into the relevant location in the definitions of Web applications, file shares, and native applications.
For example, a Web application URL that is defined as http://host/$$user
appears for user aa
as http://host/aa
and for user bb
as http://host/bb
.
If the user authenticates with a certificate, $$user
resolves during the user's login process to the user name that is extracted from the certificate and authorized by the directory server.
For its use in configuring File Shares, see Using the $$user Variable in File Shares.
WebSockets support in the Mobile Access Software Blade gives remote terminal access from a browser, without a pre-installed RDP/VDI client.
This feature is supported in R77.10 and higher.
For WebSockets system requirements, see sk95311.
Check Point appliances can support hundreds of concurrent WebSocket users. The amount depends on the power of the appliance and their deployment (Load Sharing an appliance cluster can support more users). To get the best appliance that best suits your needs, contact your Check Point sales engineer.
To use WebSockets support:
Create a regular Web application to the WebSocket server.
To monitor WebSocket connections:
[expert@hostname:0]# PingerAdmin report type ws
Or, to see all connections currently handled by the Pinger daemon (such as ActiveSync push), run: [expert@hostname:0]# PingerAdmin report all