Configuring Standalone Sentry for AppTunnel

NOTE:

If you configure AppTunnel on a Standalone Sentry that was already configured for ActiveSync, and you change the device authentication options, ensure that the associated Exchange profile matches the device authentication options.

Before you begin

You must have installed Standalone Sentry. See the Standalone Sentry Installation Guide.

Ensure that you have the required certificate setup in your UEM. AppTunnel uses either an Identity certificate or Kerberos for device authentication.

Procedure

In the Admin Portal, go to Services > Sentry.

Select Add New > Standalone Sentry or click the Edit icon for an existing Standalone Sentry entry.

Complete the fields to configure Standalone Sentry for AppTunnel.

Click Save.

Perform these steps if the Standalone Sentry uses a self-signed certificate:

Go to Services > Sentry.

For the Sentry configured for app tunneling, click the View Certificate link.

This makes the certificate for Sentry’ known to MobileIron Core.

Standalone Sentry connectivity settings

The following table describes the fields for configuring the connectivity settings for Standalone Sentry.

Table 1. Standalone Sentry connectivity settings
Item	Description
Sentry Host / IP	Enter the host name or IP address of the server on which the Standalone Sentry is installed.
Sentry Port	Enter the port that MobileIron Core will use to access the Standalone Sentry. The default is 9090.

Enable AppTunnel

In the Standalone Sentry form, select Enable AppTunnel. The AppTunnel Configuration section displays.

Device authentication

The Device Authentication setting, in the Standalone Sentry form, determines how users attempting to connect to the ActiveSync server or backend resource authenticate with Standalone Sentry.

See Device and Server Authentication for information on selecting and configuring a method of device authentication.

See Multiple trusted root certificates for device authentication for information on uploading multiple trusted root certificates for device authentication.

Context headers

As an administrator you may require your corporate backend resources to further validate the devices accessing the resources. In these cases, Standalone Sentry forwards context information in the header. Context headers is a global setting. It is applied to all services except ActiveSync. Context headers are added to all HTTP requests, including HTTP tunnels and IP tunnels. Context Headers are also added to the CONNECT requests for TCP Tunnel and non-HTTP requests sent through IP tunnels.

Context Headers are supported primarily for HTTP Tunnels. However for TCP & IP Tunnels, context headers are supported for the following cases:

HTTP traffic (port 80)
HTTP CONNECT request when explicit proxy is configured

NOTE:

You can add context headers to TCP_ANY or IP_ANY traffic only if the HTTP request is directed to proxy.

The following table describes the context information available in headers.

Table 2. Context information in headers
Header Name	Description
X-MobileIron-DEVICE-UUID	Device UUID The Device UUID can be used in API calls to MobileIron Core to collect more information about the device.
X-MobileIron-USER-UPN	User Principal name
X-MobileIron-USER-DN	User DN (if available)
X-MobileIron-USER-CERT	User Identity certificate The certificate is represented in a Privacy Enhanced Mail (PEM) encoding without the header or the trailer information.

The following table describes the field for enabling context headers.

Table 3. Field description for context headers

Item

Description

Add Context Headers

Select the check box to forward additional device context information to your corporate backend resource.

This allows your corporate backend resources to further validate the device.

NOTE:

If server-side explicit proxy is configured, the request to the proxy (HTTP CONNECT) includes the context headers.

Enable DFS

The following provides a description of the field for enabling DFS.

Table 4. Field description for enable DFS
Item	Description
Enable DFS	Select the check box if you are configuring a DFS site in Docs@Work. See the Docs@Work Guide for information on how to set up a DFS site in Docs@Work.

Advanced Traffic Control and server-side explicit proxy

Standalone Sentry supports advanced traffic control (ATC) and server-side explicit proxy. The following describe the support:

•

Advanced traffic control (ATC)

•

Server-side explicit proxy

•

Field descriptions for configuring ATC and server-side proxy

Advanced traffic control (ATC)

Advance traffic control (ATC) allows you to manage access to backend resources based on which app the traffic is coming from, OS platform, and the destination IP address or domain name. ATC provides administrators additional control and flexibility in how traffic to backend resources are managed. You can specify whether traffic to the backend resource is through a proxy server, allowed direct access, or blocked.

Example

You may want to direct Safari traffic to go through a certain proxy server and all other traffic to go directly to backend resources. In this case, you would configure the Safari bundle ID in the Application BundleID and select the proxy server to direct Safari traffic, and set the Default Action to Allow.

NOTE:

If you are using a Standalone Sentry version 7.0.1 or earlier, and configure ATC rule for a specific app on MobileIron Core, Standalone Sentry will ignore the rule.

Server-side explicit proxy

Standalone Sentry supports sending traffic through an HTTP proxy server to access corporate resources. The proxy server is located behind the firewall and sits between Sentry and corporate resources. This deployment allows you to access corporate resources without having to open the ports that Sentry would otherwise require.

Note The Following:

•

This configuration is only supported for AppTunnel traffic.

•

Proxy is configured for each AppTunnel service. You may configure proxy for some AppTunnel services and not for other AppTunnel services on the same Sentry.

•

The same proxy server may be configured on multiple Sentrys.

Standalone Sentry filters HTTP traffic through a TCP tunnel that uses server-side explicit proxy. For HTTP traffic through a TCP tunnel, if server-side explicit proxy is configured, Standalone Sentry will treat the explicit proxy as HTTP proxy. The HTTP request URL will be modified to include the target host.

In all other cases, Standalone Sentry treats the explicit proxy server as a TCP proxy server. Sentry will send a HTTP CONNECT request to the explicit proxy, followed by TCP data.

Traffic control rules

Traffic control rules specify whether traffic from an AppTunnel service or Tunnel to the backend resource is through a proxy server, allowed direct access, or blocked. Traffic control rules are applied to the following Services:

custom name
ANY
TCP_ANY
IP_ANY

Rules are matched based on the order in which they are listed. This is especially important for domain names with wildcards. For example, if the Block action is selected for *.company.com, and the Proxy action is selected for *.internal.company.com, and the rule for *.company.com is listed first, then all company.com domains will be blocked. Use the up and down arrows to order the rules.

Note The Following:

If AppTunnel traffic is blocked due to traffic control rules, the AppTunnel entry is not reported in the Apps > AppTunnels page in the Admin Portal.
To enable the traffic control rules for ANY and TCP_ANY services, you must select the <ANY> or <TCP_ANY> checkbox in the Proxy/ATC column of Services panel. See, AppTunnel service.
To enable the traffic control rules for IP_ANY services, you must select <IP_ANY> checkbox in the Proxy/ATC column of Services panel. See, AppTunnel service.

Traffic control rules for ANY and TCP_ANY services

Sentry parses custom, ANY, TCP_ANY service traffic for the destination host and the application ID. For HTTP traffic Sentry obtains the information from the host address. For HTTPS traffic Sentry obtains the information from the SNI. The information is used to match against domain-based ATC rules. If the information is not available or the information does not match a rule, the default rule is applied.

If the option Traffic Control rules for IP_ANY services is enabled, Sentry parses and obtains the destination host and application ID and applies the domain-based ATC rules. If Sentry cannot get the destination host and application ID information, then IP-based ATC rules are applied.

Traffic control rules for IP_ANY Service

Sentry uses the destination IP address for IP_ANY service traffic to match against an IP-based ATC rule. If the information is not available or the information does not match a rule, the default rule is applied.

Field descriptions for configuring ATC and server-side proxy

The following table describes the fields for configuring ATC and server-side proxy.

Table 5. Field descriptions for Advanced Traffic Control (ATC)

Item

Description

Advanced Traffic Control

Select the checkbox to enable advanced traffic control.

The Server-side Proxy section is replaced with the Advanced Traffic Control (ATC) section.

Server-side Proxy List

Traffic is directed to the proxy servers listed here based on the backend resource and action defined in Traffic Control Rules.

Name

Enter a unique name for the proxy server.

The name for the proxy server will be available for selection in the Proxy field.

Hostname

Enter the IP address or FQDN for the proxy server.

Port

Enter the port number for the proxy server.

Click to add a proxy server.

Traffic control rules for ANY and TCP_ANY Services

Traffic control rules for IP_ANY services

Select the check box to configure Destination Host, Application BundleID, and device Platform for IP_ANY services. This triggers the rules under ANY and TCP_ANY services. Configure an ATC rule using FQDN for the destination host and specify a bundle ID. Specify the device OS to which the ATC rule is applied.

NOTE:

This feature should be enabled ONLY after all Android clients are deployed with Android Tunnel 4.3. This features required Core 10.5.1 and Sentry 9.8.0.

Enter the text to search for the appropriate ATC rule or host based on domain, app identifier or other parameters listed in the ATC.

Destination Host

IP address or domain name: Enter the IP address or domain name of the backend resource: Port numbers are not supported. Wildcards are supported. Only the suffix after the * wildcard is matched.

Example: *.acme.com.

ANY_SHORT: Select ANY_SHORT to apply the traffic control rule to all short domain names entered by the device user.

Example: The device user can enter sharepoint1 instead of sharepoint1.mycompany.com. Traffic control rules are applied to sharepoint1.

ANY_IP: Select ANY_IP to apply traffic control rules to all IP addresses entered by the device user.

Example: A device user entering an IP address to access example.mycompany.com can bypass a traffic control rule that directs traffic to *.mycompany.com through a proxy server. If you set traffic control rules to block ANY _IP, then traffic using the IP address is blocked.

Application Bundle ID

Enter the app identifier. The app identifier is the bundle ID for iOS apps and the package name for Android apps.

The ID can include "*" for wildcard matching. The ID can be used in conjunction with Destination Host. If you are using the ID with a destination host, then the rule will be applied only to traffic from the app directed to the destination host.

Platform

You can also filter based on Platform such as iOS, macOS and Android. Windows is not supported.

Traffic control rules for IP_ANY Services

Destination IP Address / CIDR

IP address: Enter the IP address or the CIDR notation of the backend resource.

Common field description for ANY, TCP_ANY, and IP_ANY Services

Action

Select Proxy, Allow, or Block.

Proxy

If you selected Proxy for Action, then select the proxy server for the backend resource.

Click to add a backend resource.

Default Action

The default action is applied if traffic control rules is not defined for a backend resource.

Proxy

If you choose Proxy as the default action, select the proxy server for traffic to the backend resource.

Server-side Proxy

If Advanced Traffic Control (ATC) is enabled, the Server-side Proxy section is no longer available. If you had configured a proxy server, and you enable advanced traffic control, the proxy server is listed in the Server-side Proxy List as global. The Default Action is selected as Proxy and the default Proxy server is selected as global.

To configure Server-side Proxy, enter the HTTP proxy server information. Configuring an HTTP proxy server provides access to corporate resources without having to open the ports that Standalone Sentry would otherwise require.

Proxy Host Name / IP

Enter the FQDN of the proxy server.

Do not include a URI scheme, such as http:// or https://, in this field.

Proxy Port

Enter the port number for the proxy server.

Note The Following:

AppTunnel service

The following table describes the fields for configuring an AppTunnel service.

Table 6. Field descriptions for AppTunnel service

Item

Description

Services

To add a new AppTunnel service, click +.

Service Name

The Service Name identifies the AppTunnel service. The service name is referenced in the AppConnect app configuration for configuring tunneling for the AppConnect app. The app is restricted to accessing the backend resources listed in the Server List field. The service name is similarly used in:

•

the Web@Work setting for configuring tunneling for Web@Work for Android or iOS.

•

the Docs@Work setting for configuring tunneling for the Docs@Work app.

NOTE:

The order of the Service Name entries does not matter.

A service name cannot contain these characters: 'space' \ ; * ? < > " |.

Enter one of the following:

•

A unique name for the service that the app on the device accesses.

For example, some possible service names are:

SharePoint

Human Resources

•

A unique name with one of the following special prefixes:

For app tunnels that point to CIFS-based content servers, the service name must begin with CIFS_.

For TCP tunneling, the name must begin with TCP (case-insensitive).

Example: TCP_Finance

Service Name

•

<ANY>

Select <ANY> to allow tunneling to any URL that the app requests. Typically, you select <ANY> if an AppConnect app’s app configuration specifies a URL with wildcards for tunneling, such as *.myCompany.com. Sentry tunnels the data for any URL request that the app makes that matches the URL with wildcards.

Sentry tunnels the data to the backend resource that has the URL that the app specified. The Server List field is therefore not applicable when the Service Name is <ANY>.

For example, consider when the app requests URL myAppServer.mycompany.com, which matches *.mycompany.com in the app configuration. Sentry tunnels the data to myAppServer.myCompany.com.

Web@Work typically uses the <ANY> service, so that it can browse to any of your internal servers.

NOTE:

Do not select this option for tunneling to CIFS-based content servers. Select <CIFS_ANY> instead.

•

<TCP_ANY>.

Select <TCP_ANY> to allow TCP tunneling to any backend resource that the app requests.

•

<CIFS_ANY>

Select <CIFS_ANY> to allow tunneling to any URL for a CIFS-based content server. Typically, you select <CIFS_ANY> if the URL for a CIFS-based content server contains wildcards for tunneling, such as *.myCompany.com.

•

<IP_ANY>

Select <IP_ANY> to allow IP tunneling. Use this service name as part of the Tunnel setup for Windows 10 or Android devices.

NOTE:

By default, Sentry uses 172.28.13.0/29 as the subnet mask for IP tunnels. If you are using the subnet internally, you must change the subnet Sentry uses. Contact MobileIron Support for instructions on how to change the default subnet mask that Standalone Sentry uses for IP tunneling.

•

<IP_ANY_WP8.1>

Select <IP_ANY_WP8.1> to allow IP tunneling for WP8.1 devices. Use this service name as part of the Tunnel setup for Windows Phone 8.1 (WP8.1) devices.

Server Auth

Select the authentication scheme for the Standalone Sentry to use to authenticate the user to the backend resource:

•

Pass Through

Sentry passes through the authentication credentials, such as the user ID and password (basic authentication) or NTLM, to the backend resource.

NOTE:

For TCP and IP tunneling, select Pass Through. Pass Through is the only option available when the service name begins with “TCP”. Sentry passes through all TCP or IP packets to the backend resource.

•

Kerberos

Sentry uses Kerberos Constrained Delegation (KCD). KCD supports Single Sign On (SSO). SSO means that the device user does not have to enter any credentials when the AppConnect app accesses the backend resource.

The Kerberos option is only available if:

You selected Identity Certificate for Device Authentication.

The service name is not a TCP service name; MobileIron does not support Kerberos for AppTunnel with TCP tunneling.

Server List

Enter the backend resource’s host name or IP address (usually an internal host name or IP address). Include the port number on the backend resource that Sentry can access.

Example:sharepoint1.companyname.com:443

Acceptable characters in a host name are letters, digits, and a hyphen. The name must begin with a letter or digit.

You can enter multiple resources. Standalone Sentry uses a round-robin distribution to load balance. That is, it sets up the first tunnel with the first resource, the next with the next resource, and so on. Separate each resource name with a semicolon.

Example: sharepoint1.companyname.com:443;sharepoint2.companyname.com:443.

NOTE:

The Server List field is not applicable when the service name is <ANY>, <TCP_ANY>, <IP_ANY>, or <CIFS_ANY>.

TLS Enabled

Select TLS Enabled if the servers listed in the Server List field require SSL.

This option is not applicable when the service name is <ANY>, <TCP_ANY>, <CIFS_ANY>, <IP_ANY>, or a TCP service.

NOTE:

Although port 443 is typically used for https and requires SSL, the backend resource can use other port numbers requiring SSL.

Proxy/ATC

Select if you want to direct the AppTunnel service traffic through the proxy server.

You must also have configured Server-side Proxy or Advanced Traffic Control (ATC).

Server SPN List

Enter the Service Principal Name (SPN) for each server, separated by semicolons.

Example: sharepoint1.company.com;sharepoint2.company.com.

The Server SPN List applies only when the Service Name is not <ANY> and the Server Auth is Kerberos.

If each server in the Server List has the same name as its SPN, you can leave the Server SPN List empty. However, if you include a Server SPN List, the number of SPNs listed must equal the number of servers listed in the Server List. The first server in the Server List corresponds to the first SPN in the Server SPN List, the second server in the Server List corresponds to the second server in the Server SPN List, and so on.

For a custom CIFS AppTunnel service, if you configured the FQDN of the CIFS server in the server list, and the FQDN is the same as the SPN, you do not need to configure the Server SPN List. A custom CIFS service is an AppTunnel service that is not CIFS_ANY. If you configured the IP address of the CIFS server in the server list, you must configure the corresponding SPN. The SPN must include the cifs prefix. Example: cifs/s01-dfs12-001.example.com. Any SPN configured for a CIFS service must inlcude the cifs prefix.

NOTE:

When the Service Name is <ANY> and the Server Auth is Kerberos, the Standalone Sentry assumes that the SPN is the same as the server name received from the device.

This field is not applicable for a TCP service.

Configured settings for managing multiple Sentrys

See Configured settings for managing multiple servers.

Advanced settings

See Advanced settings.