Mobile and Chrome OS Clients

See the AppGate website for links to the respective app store.

Using Mobile Clients

Mobile operating systems are less capable than their desktop counterparts. For the most part the Client looks, feels and behaves the same on mobile however there are some things that should be taken into account when configuring AppGate ZTNA. Mobile operation systems expect relatively simple network configurations so the number of Sites (tunnels), Entitlements and routes should be limited in order to make them compatible.

For more detailed information about how routes are set refer to Routing Client traffic.

Installation using MDM

MDM (Mobile Device Management) systems can be used to install the mobile Clients. We follow the best practices documented by the AppConfig Community. AppConfig is a standardized means for application configuration and management for managed devices. This should be compatible with a range of MDM vendors such as MobileIron, Intune, etc.

In Client Profiles it was already explained that it is possible to configure the Clients using a profile link allowing users to have to enter only their username and password to get connected.

So we can combine these two features to create an easy way to set up enterprise managed mobile devices:

• On Android/Chrome OS this is done by adding a manifest restriction within the app restrictions

• On iOS/iPadOS it is done within managed configuration

The idea with AppConfig is to provide key-value pairs from the MDM. AppGate ZTNA Clients look for a single key: ag_config. Clients expect a JSON structure to be used to provide a value for that key. The JSON structure must include a key named ag_url however it can comprise additional parts. The first part (ag_url) comprises the Client profile which sets the URL, SPA key, Certificate fingerprint and identity provider. Any subsequent parts will comprise and any claims you would like reported as device claims when the Client connects. For example, you may want to pass a device claim "mdm_approved: 5e224d10-a7c0-4f3f-a72c-3d002be0730b" to check if connecting iOS/Android Client is actually connecting from a company MDM approved device.

App Configuration

Here are few examples:

iOS using AirWatch MDM

Use the Workspace One UEM Admin Interface to add a key/value pair:

Key: ag_config

Type: String

Value: "{"ag_url": \"appgate:mycontroller.com/eyJW.....","mdm_approved": "SNdYpXJMOqnd0bIE"}"

iOS using Jamf Pro

This is the syntax required to deploy the Client using Jamf Pro device management:

<dict>

<key>ag_config</key>

<string>{ "ag_url":"appgate://sdp-controllers.domain.com" }</string> </dict>

iOS using Safari for external authentication

Enter the following to enable Safari for external authentication:

"ag_use_safari_for_external_authentication": "true"

ChromeOS using Google

This is the syntax required to deploy the Client using Google device management:

{
 "applications": [{
         "packageName": "com.cryptzone.appgate.xdp",
         "installType": "FORCE_INSTALLED",
         "defaultPermissionPolicy": "GRANT",
         "managedConfiguration": {
                 "ag_config": "{ \"ag_url\": \"appgate:\/\/mycontroller.com\/eyJz.....GUifQ==\", \"Claim_ManagedDevice\": \"true\"}"
         }
 }]
}

NOTE

The configuration remains essentially the same - just with the use of additional delimiters in this case.

Android using MS Intune

This is the syntax required to deploy the Client using Intune device management:

{
    "kind": "androidenterprise#managedConfiguration",
    "productId": "app:com.cryptzone.appgate.xdp",
    "managedProperty": [
        {
            "key": "ag_config",
            "valueString": "{\"ag_url\" : \"appgate://appgate.company.com/xxxx\", \"mdm_approved\": \"random key\"}"
        }
    ]
}

Checking for managed devices

One reason for including extra device claims is to allow enterprises to check that a device is MDM enabled before it is allowed to connect through AppGate ZTNA. It is nearly impossible for the AppGate ZTNA Client to check this at run time because of the security model used on mobile operating systems prevents device claims being harvested using device scripts. So instead of this we need to use some other mechanism.

The AppGate ZTNA MUST be installed using MDM. At this point the the additional claims are populated by the MDM. These values are baked in and could for instance be something the MDM is allowed to know/read and the AppGate ZTNA is unable to know/read; such as say - imei:number. It could equally be some static claim such as mdm_version:1234 or mdm_manged:true. Now, when the Client connects these claims will be sent from the Client and can be used in Policy assignment decisions. They will also be recorded in the logs for audit purposes.

It might also be possible to include these claim values in external API calls. By this means a serial number could be checked against a database to verify the device before the Policy is assigned.  

Log files

Logs can be downloaded in the usual way using About > Download log files.

Other actions and settings

Remove Settings

On iOS/iPadOS it is possible to wipe all settings including removing the certificate saved when the Client first connected.

In settings find AppGate ZTNA Settings. Enable Wipe credentials at next launch.