MobileIron Core, Standalone Sentry, and device interaction

The following describe MobileIron Core, Standalone Sentry, and device interaction:

When an ActiveSync device accesses email

The following illustrates the interaction between Standalone Sentry, UEM, and the device when the device first attempts to access the ActiveSync server.

Figure 1. Device first attempt to access the ActiveSync server

1. Device attempts to access ActiveSync or other backend resource.
2. Standalone Sentry adds device to its list of devices.
3. Standalone Sentry tells UEM about the device.
4. The ActiveSync devices view on the UEM now includes the device.
5. UEM tells Standalone Sentry whether to block or allow the device based on:

- the device’s security policy

- whether the maximum number of devices per mailbox has been exceeded

- whether you specified to auto block unregistered devices

6. Sentry tells device whether it is blocked or allowed, passing ActiveSync policy if allowed.
7. If access is allowed, device applies ActiveSync policy, and continues email processing.

If access is blocked, Standalone Sentry informs the device.

The next time a device attempts to access the ActiveSync server, the device is already in the list of devices on Standalone Sentry. Therefore, Standalone Sentry already has the information in the UEM about whether to block or allow access.

If Standalone Sentry cannot communicate with MobileIron UEM

On the first attempt, if Standalone Sentry is temporarily unable to communicate with MobileIron UEM due to, for example, a network error, the following occurs:

  1. Standalone Sentry allows the device to access the ActiveSync server.

  2. Standalone Sentry pushes a default ActiveSync policy to the device.

    NOTE: This default policy is not the same as the default ActiveSync policy you configure in the Admin Portal. This default policy is a temporary policy to cover this infrequent communication failure.
  3. At a periodic UEM-Sentry resync, the UEM sends Standalone Sentry the proper state of the device (allowed, blocked, or wiped) as well as the device’s ActiveSync policy. If access is allowed, Standalone Sentry pushes the ActiveSync policy to the device.

When an app accesses the backend resource

When using Standalone Sentry for AppTunnel, when an app first attempts to access the backend resource, the following occurs:

  1. MobileIron UEM tells Standalone Sentry whether to allow or block the app’s access to the backend resource based on:

    • the device’s security policy
    • whether you specified to auto block unregistered devices
    • whether the app is an authorized app
  2. Standalone Sentry creates an AppTunnel for the app to access the backend resource based on the AppTunnel status provided by the UEM.
  3. The AppTunnel view on the UEM now includes the new AppTunnel.
  4. The next time the app attempts to access the backend resource, the app uses the AppTunnel that was created to access the backend resource.

On the first attempt, if Standalone Sentry is temporarily unable to communicate with the UEM due to, for example, a network error, the following occurs:

  1. Standalone Sentry allows the app to access the backend resource.
  2. At the periodic Core-Sentry resync, the UEM sends Standalone Sentry the proper state of the device (allowed, blocked, or wiped).

When MobileIron Core detects a security policy violation

MobileIron UEM detects a security policy violation when, for example, a device checks in. UEM tells Standalone Sentry to block the device from accessing the ActiveSync server and backend resources.

When you change an ActiveSync policy (Core only)

On the Admin Portal, you can add or modify ActiveSync policies. For each affected device, MobileIron Core sends the ActiveSync policy to Standalone Sentry. Standalone Sentry sends the policy to the device.

When Sentry initializes

When Standalone Sentry starts or restarts, the following occurs:

1. Standalone Sentry gets all the registered ActiveSync devices from MobileIron UEM that are allowed to access the ActiveSync server.
2. Standalone Sentry puts all these devices in its list of devices. The information in the list includes the ActiveSync policy for each device.

Creating this list speeds up the time it takes for devices to access their email after a Sentry maintenance restart, especially when Core and Standalone Sentry communicate over a high latency link. The performance improvement is because the Standalone Sentry does not have to ask Core whether to block or allow most devices’ access to the ActiveSync server.

If a device is not in the list, the device’s next attempt to access the ActiveSync server is as though it is the first time. See When an ActiveSync device accesses email.

3. Standalone Sentry retrieves the AppTunnels equal to the Sentry device cache size (number).

Periodic Core-Standalone Sentry resync

Sometimes communication errors can occur between the following:

  • Core and Standalone Sentry

    A communication error can occur because of, for example, a network problem.

    These communication errors can result in UEM failing to tell Standalone Sentry to block, allow, or wipe a device, or failing to send Standalone Sentry an updated or new ActiveSync policy, or failing to tell Standalone Sentry to block, allow, or remove an AppTunnel.

  • Standalone Sentry and a device

    For example, a device can be turned off when you update its ActiveSync policy.

Therefore, Core and Sentry periodically resync to make sure that they and the ActiveSync devices have the correct data. For example, Standalone Sentry updates its list of devices with the proper state of each ActiveSync device (allowed, blocked, or wiped), the ActiveSync policy if it changed, the state for each AppTunnel (allowed, blocked, or removed). Standalone Sentry also pushes updated ActiveSync policies to the devices.