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.

Procedure

In MobileIron Cloud, go to Admin > Sentry.
Click +Add Sentry Profile or click on an existing profile to Edit.
Depending on the device authentication you will configure, select one of the following:
- ActiveSync and/or App Tunnel with certificates
- ActiveSync and/or App Tunnel with Kerberos
Use the guidelines provided in the following sections to configure Standalone Sentry for AppTunnel.
Click Save.
Assign the profile to a registered Standalone Sentry.
Only one profile can be assigned to a Standalone Sentry.

Standalone Sentry connectivity global settings

See Configuring Standalone Sentry connectivity settings.

Device Authentication

Device authentication determines how users attempting to connect to the ActiveSync server or backend resource authenticate with Standalone Sentry. AppTunnel setup requires an Identity certificate or a Kerberos setup.

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

Default unmanaged devices behavior

By default, Sentry blocks unregistered devices from accessing backend resources.

See Default unmanaged devices behavior.

Passive health check options

These settings determine when a server is marked as ‘dead’.

See Passive health check options.

Scheduling options

The options provide additional flexibility in managing multiple Sentrys.

See Scheduling options.

Default HTTP/TCP timeouts

WARNING:

Do not make changes to the settings unless specifically instructed in the documentation or by MobileIron Professional Services.

See Default HTTP/TCP timeouts.

Sentry server configuration

Configure the Sentry port, certificate, protocols and cipher suites.

See Sentry server configuration.

Advanced Traffic Control and server-side explicit proxy

•

Advanced traffic control

•

Server-side explicit proxy

Advanced traffic control

Advance Traffic Control (ATC) allows you to manage access to backend resources based on which app the traffic is coming from 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 8.5.0 or earlier and configure ATC rules, Standalone Sentry will ignore the ATC rules.

Table 1. Rule type supported by app
Rule type	App - Services
IP-based rule	Tunnel for Android and Windows.
Domain-based rule	Tunnel for iOS AppConnect apps for iOS and Android devices. SharePoint for Docs@Work CIFS for Docs@Work Web@Work

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 the Sentry and corporate resources. This deployment allows you to access corporate resources without having to open the ports that Sentry would otherwise require.

Consider 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.

Table 2. Field descriptions for Advanced Traffic Control (ATC)
Item	Description
Advanced Traffic Control	Select to enable advanced traffic control.
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 for Traffic Control Rules.
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 Specify whether traffic from an app to the backend resource is through a proxy server, allowed direct access, or blocked. You can create multiple rule sets. Each rule set can have multiple rules. However, all rules in a rule set can only be one type, either IP based or domain based. You cannot create a mix of IP based and domain based rules in a rule set. Note The Following: Rules in a rule set 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. If AppTunnel traffic is blocked due to traffic control rules, the AppTunnel entry is not reported in the Sentry tab in device details for a device.
Rule type	Select one of the following: IP based: The rule is matched based on the IP address of the destination host. IP based rules are supported only for IP traffic from Windows and Android devices going through MobileIron Tunnel. The destination has to be an IP address or an IP range. Example: 10.0.0.0/8, 10.5.0.0/16, 10.5.2.0/24, 10.5.5.2/32 Domain based: The rule is matched based on the domain of the destination host and the bundle ID of the app. Domain based rules are supported only for HTTP/S and TCP traffic from iOS devices going through MobileIron Tunnel. The destination has to be a domain name.
Destination Host	Enter the IP address or domain name of the backend resource: IP based rules: Enter an IP address or range. The IP address range must conform CIDR format. Example: 192.168.0.15/24 Domain based rules: Port numbers are not supported. Wildcards are supported. Only the suffix after the * wildcard is matched. Example: *.acme.com.
Application Bundle ID	Enter the app bundle ID for which you are creating the domain-based rule. The bundle ID can include "*" for wildcard matching. The bundle ID can be used in conjunction with Destination Host. If you are using the bundle ID with a destination host, then the rule will be applied only to traffic from the app directed to the destination host.
Action	Select Proxy, Allow, or Block.
Proxy	If you selected Proxy for Action, then select the proxy server for the 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.

AppTunnel service

Select one of the app services to create an AppTunnel service for that app.

•

Service types and supported traffic

•

Field description for AppTunnel service

•

About context headers

Service types and supported traffic

The following table describes the service type available when configuring AppTunnel and the traffic type supported by the service.

Table 3. Service type and supported AppTunnel traffic
Service type	Supports traffic type
Sharepoint for Docs@Work	iOS: HTTP, HTTPS Android: HTTP, HTTPS
CIFS for Docs@Work	iOS: CIFS Android: CIFS
Web@Work	iOS: HTTP, HTTPS Android: HTTP, HTTPS
MobileIron Tunnel	iOS: HTTPS, TCP, IP (split tunneling for UDP traffic) Windows: HTTPS, TCP, IP (including UDP). Android: HTTPS, TCP, IP (including UDP).
Help@Work	iOS: TCP (includes HTTP and HTTPS)
Custom HTTP	HTTP and HTTPS Any service other than TCP and IP
Custom TCP	TCP

Field description for AppTunnel service

The following table describes the fields available for configuring an AppTunnel service. The fields available for configuration changes depending on the type of service you are configuring.

Table 4. Field descriptions for AppTunnel service

Item

Description

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.

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

Service Type

(only MobileIron Tunnel iOS or Mac )

IP: Select to configure packet-tunnel provider type VPN.

TCP: Select to configure app-proxy VPN.

Enable DFS

Select the check box if you are configuring a DFS site in Docs@Work.

Only for Docs@Work for CIFS service.

Server Authentication

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

Pass through (Basic Authentication)

The 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. The Sentry passes through all TCP or IP packets to the backend resource.

Kerberos

The 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 ActiveSync and/or App Tunnel with Kerberos.
- Kerberos authentication is now supported with Exchange ActiveSync, Web@Work, SharePoint for Docs@Work, and CIFS for Docs@Work services.
If you select Kerberos, additional fields are displayed. See Authentication using an Identity certificate and Kerberos constrained delegation.

All destinations (forward proxy)

Select if you want all traffic from the app to go through Standalone Sentry.

Specific destinations (reverse proxy)

Select if you want to restrict traffic to only specific servers. Standalone Sentry sends through only requests to the configured servers.

Servers (reverse proxy)

Add the backend resource’s fully qualified domain name (FQDN) and port number on the backend resource that the 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. The 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.

Enable Server TLS

Select Enable Server TLS if the servers listed in the Servers field require SSL.

NOTE:

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

ATC Rule Set

Select the ATC rule set if you want to manage the AppTunnel service traffic through ATC rules.

You must also have configured Advanced Traffic Control (ATC) rules. Only the rule type supported by the app will be listed.

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:

Context headers are not supported for TCP tunneling.

About context headers

As an administrator you may require your corporate backend resources to further validate the devices accessing these resources. In these cases, Standalone Sentry forwards context information in the header. You enable context headers in a service configuration. So, you can decide to enable context headers for some services and not enable context headers for other services.

NOTE:

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

Table 5. Information in context headers
Header Name	Description
X-MobileIron-DEVICE-UUID	Device UUID The Device UUID can be used in API calls to MobileIron Cloud 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.