Understanding the Ivanti Android Enroller

Version 1

    MDM and Android Agent Behavior

     

    Ivanti currently publishes two types of Android agent: “Standard” and “Android Enterprise” and both are available on the Play Store. Either one allows a user to enroll into Ivanti EPM.

    Note: Android for Work (“AfW”) is old Google terminology that has been replaced by Android Enterprise (“AE”).

    For the AE agent, it can operate in two or more modes, primarily in POM and DOM. POM is “Profile Owner Mode” and is typically used on BYOD devices as the “work profile” containing Work apps is distinct from the rest of the device. DOM “Device Owner Mode” is for Enterprise-owned devices and requires a specific provisioning process.

    The Standard agent is generally less desirable because it “takes over” the user’s BYOD device (it can be used to fully wipe the device, the potential of which causes distress to some users).

    The principal differences are given below:

    Type of Agent

    Typical Use

    Full control of device?

    Can MDM wipe a device?

    Standard

    BYOD

    Yes

    Yes

    AE POM

    BYOD

    No

    No

    AE DOM

    Enterprise-owned

    Yes

    Yes

     

    User Experience for Android Agents

    The common user experience for the agents includes the Ivanti disclosure screen and the Enrollment and optional Enrollment Agreement screens. The specific differences are given below.

    Standard Agent- How to Enroll an Android Device in LDMS 2016

    Because the standard agent can perform many management operations on the device, the user is warned of these requirements when the agent is first installed.

    1. When the agent is installed, a long list of capabilities requested by the agent must be accepted by the user
    2. After starting the agent, the user is offered an Ivanti disclosure page informing them that MDM may make changes to the device via “Device Admin”.
    3. After the page is dismissed, Android prompts them to accept the “Device Admin” requirements.
    4. After accepting, the user is presented with the enrollment page
    5. When the user tries to enroll, they may be presented with a enterprise-configured Enrollment Agreement which they must accept to proceed with enrollment
    6. Once accepted, enrollment completes and the device is manageable

    Android Enterprise POM Agent- Android for work (AFW) Setup and Configuration

    The experience for POM is significantly different from the standard agent.

    1. When the agent is installed, the user is not offered a list of capabilities requested
    2. The user is offered the Ivanti disclosure screen for “Device Admin” which they must accept. It is worth noting that POM does not use Device Admin, but the disclosure is still required by Google.
    3. After the page is dismissed the user sees a page from Android which asks them to create a work profile.
    4. After the user accepts the various conditions, a work profile is created by Android and then launches the agent’s Enrollment screen.
    5. When the user tries to enroll, they may be presented with a enterprise-configured Enrollment Agreement which they must accept to proceed with enrollment
    6. Once accepted, enrollment completes and the device is manageable

    Android Enterprise DOM Agent

    The experience for DOM is similar to standard agent with the exception that certain Android screens are not presented because this is an enterprise-owned device.

    1. The user is offered the Ivanti disclosure screen for “Device Admin” which they must accept. It is worth noting that DOM does not use Device Admin, but the disclosure is still required by Google.
    2. After the page is dismissed, the user is presented with the enrollment page
    3. When the user tries to enroll, they may be presented with a enterprise-configured Enrollment Agreement which they must accept to proceed with enrollment
    4. Once accepted, enrollment completes and the device is manageable

    Two agent icons for POM

    A work profile contains data separate from the rest of the device as a means to separate enterprise data from personal data. Certain apps run within a work profile and use their data is stored in the work profile.

    These same apps can also run outside the work profile. To distinguish which data the app is using, Android creates two icons for the same app: the normal app icon and the work profile app icon, which is “badged”. Android places a briefcase badge over the icon if it is in the work profile.

    The agent operates from within the work profile, thus any user interaction must be with the badged agent icon. If the user attempts to run the normal app, they will be warned that the app cannot be used and that they should use the badged app instead.

    Converting from Standard to AE POM Agent

    The administrator can enable setting on the server to prompt a standard agent user to upgrade to the AE agent (POM). The user is instructed how to obtain the AE agent from within the standard agent. See server documentation for more information.

    Lock

    When the administrator sends a Lock command from the console, the agent screen will lock regardless of the type of agent.

    Unlock

    When the administrator sends an Unlock to an agent, the behavior of the device varies with version and type. The original behavior was to remove the PIN (or passcode) from the device and the user could then gain access. This then changed to requiring the administrator to enter a new PIN, relay that to the user, and the user would use the new PIN to access the device.

    POM Unlock

    AE Agents running in POM are unable to unlock a device due to a deliberate limitation imposed by Android. The exception is that with Android 8 (Oreo), it is possible to lock the work profile. By default the profile is unlocked, but the administrator can send an Unlock command with a new PIN which then restricts access to apps in the work profile. Unlocking the actual device in POM is not supported on any version.

    Unlock in Oreo

    Unlock is only supported in the AE agent in Oreo (8.0+); Unlocking is restricted by Android for BYOD and is not possible in the standard agent. For POM, as noted previously, only the work profile can be unlocked (or PIN set). An unlock is straightforward if the device does not currently have a PIN, however, if it does have a PIN, the user will be prompted to give permission to the agent to perform unlock (change PIN) operations.

    Passcode-to-PIN-to-Unlock Sequence in Oreo

    The following diagram illustrates a typical configuration sequence (DOM example) involving enrollment, passcode requirement, PIN (or Passcode) setting by the user and eventual Unlock (change forgotten PIN) by the administrator.

    The diagram is provided as a explanation of the flow, because in practice, the user experiences multiple prompts and screens that do not appear to follow a logical sequence. Many of the prompts and screens are controlled by the Android OS and so it is difficult to get a bearing on the intention of some of the screens.

    For POM, the diagram is almost identical except that the PIN begin referred to is for the work profile, not the device. The PIN setup screen will show “work profile” so you know the PIN is intended for the work profile, not the device. If the device has a PIN then the Ivanti PIN prompt (third row, left) is asking for the device PIN, not the work profile PIN.

    Once a work profile PIN is entered to access a work profile app, the system caches the PIN and allows access until some predetermined time (usually until the device is locked again, or goes to sleep).

    Require Passcode in Oreo and POM

    When applying a passcode profile for an Android 8.x+ device, the user receives a notification to set their PIN. If they click on the notification, if the device is POM, then the PIN the user supplies is applied to the work profile, NOT the device. This is in keeping with limiting the effect of the agent behavior on the user’s BYOD device. It is important to note because Passcode requirements in the standard agent apply to the device itself.

    Thus the work profile is PIN protected, but the device may not be. Say for example, a child accesses a BYOD device to play a game, and they try to access a work profile app, they will be prompted for a PIN which they hopefully do not know.

    It is this work profile PIN which can be changed via the Unlock command from the console.

    Unlock Behavior Table

    Mode/Version

    1. 4.x
    2. 5.0
    3. 5.1
    4. 6.0
    5. 7.0
    6. 8.0

    Standard

    Immediate

    Not supported

    PIN dialog

    PIN dialog

    Not supported

    Not supported

    POM

    N/A

    N/A

    Not supported

    Not supported

    Not supported

    Work profile only; user acceptance

    DOM

    N/A

    N/A

    PIN dialog

    PIN dialog

    PIN dialog

    PIN dialog; user acceptance