Okta Mobility Management with Android for Work

  • The OMM menu is only available to orgs that implement Okta Mobility Management (OMM).
  • Procedures documented on this page are only available to customers who have already purchased OMM for their organization. New OMM sales are not supported. For more information, contact Okta Support.

Android for Work, or Android in the enterprise, is Google's solution to enterprise mobility management. Enrolling a user in Okta Mobility Management (OMM) through Android for Work creates an encrypted, containerized Work profile on their device, and installs a managed Google Play store. These allow you to assign separate managed versions of work apps, like Box or Outlook, as well as selectively wipe company data from an end user's device, while leaving their personal data intact.

Supported Versions of Android

  • Android 5.1.1 (L) and later
  • If you enable Android for Work, we strongly recommend you deploy Google Chrome to your OMM users in order to prevent unexpected behavior on certain older Android devices. See Enable access to managed mobile apps for information on deploying managed apps.

  • When a work profile is configured on an Android O device, Google Chrome is automatically installed. This prevents Okta Mobile and other apps that use web views from crashing due to a bug in Android O. See the Google documentation of the bug for details.

Set up Android for Work

See Setting up Android for Work in Okta for instructions.

Configure a Work profile passcode policy

OMM allows you to configure passcode policies for any supported Android device. These policies allow you to require your users to enter a passcode that meets your specifications to unlock their device. They are applied based on groups you create, which allows you to set different levels of access and security for different people.

For an additional level of flexibility, you can also set a separate work profile passcode policy for your users with Android 7.0+ devices. You can use this policy to require users to enter a passcode before accessing apps managed by their work profile, which allows you to set a more secure policy for accessing work resources than for accessing personal apps and data. This way, your users can easily access their personal resources without having to enter complex passwords, while still keeping company data safe and secure.

Note: Requires Okta Mobile 3.0 or above.

To set a work profile passcode policy, you must create or edit a device policy, then configure that policy's Android rule.

Create a device policy

  1. In the Admin Console, go to OMMOMM Policies.
  2. Click Add Device Policy, then specify:
    • A unique Policy name
    • An optional Description
    • The groups of users to whom this policy will apply
    • An optional ClosedUser Agreement

      If you select this box, enter a brief custom user agreement in the text field. The agreement appears on end users devices and end users must acknowledge it before they can proceed to OMM enrollment. As part of the OMM enrollment process, end users are warned that enrolling in OMM gives admins certain controls over their devices. This User Agreement is an opportunity to provide additional custom terms and conditions you may want your end users to acknowledge.

  3. Click Save and Add Platform Rule, then select Android to continue.

Edit an existing device policy

If you have an existing policy that is assigned to the correct groups, you can edit it to include a work profile passcode policy.

  1. In the Admin Console, go to OMMOMM Policies.
  2. Select the policy you want to edit.
  3. If the policy already has an Android rule, click the pencil icon to edit the rule. Otherwise, click Add Platform Rule, then select Android to continue.

Configure an Android rule with a work profile passcode

  1. In the Admin Console, go to OMMOMM Policies.
  2. Select Allow devices.
  3. Select Android for Work. If this option is disabled, click Set up AfW.
  4. Click Next. and then configure settings in the following sections as appropriate:
  5. General Android Device Passcode Requirements

    For Android devices earlier than 7.0 – Select Require a device passcode if you want to require users running versions of Android earlier than 7.0 to enter a passcode to unlock their device. Then, specify the passcode requirements. For Android devices 7.0+, see this section.

    • PIN minimum length Specify the minimum PIN length (from 4 to 30).
    • Characters — Specify whether passcodes must contain at least one letter, and/or at least one symbol.
    • Expiration — Specify whether passcodes never expire (the default), or the number of days they are valid before expiration (Max age), and how many distinct passcodes a user must create before they can reuse a previous passcode (History limit).
    • Failed attempts before wipe — Specify the maximum number of times users can enter the wrong passcode before their device is wiped. Note the following:
      • Select Unlimited attempts if you never want to wipe a device because of failed passcode attempts.
      • On Android for Work, only the Work profile is wiped.

      • Devices are not wiped if users enter the wrong passcode less than 4 times.
      • You can allow up to 10 failed attempts before the device is wiped.
    • Device lock timeout — Specify how long after the display is turned off that the user must enter their passcode to unlock the device.

    Android Data Separation

    If you want to allow unmanaged apps to open files from the work profile, select Work profile can transfer data to personal profile under Android Data Separation.

    Optional: Android 7.0+ Work Passcode Requirements

    Prompt for work passcode

    Under Android 7.0+ Work Passcode Requirements, select Require Work passcode if you want to require Android 7.0+ users to enter a passcode in order to access apps in their work profile, and then specify the passcode requirements.

    • PIN minimum length Specify the minimum PIN length (from 4 to 30).
    • Characters — Specify whether passcodes must contain at least one letter, and/or at least one symbol.
    • Expiration — Specify whether passcodes never expire (the default), or the number of days they are valid before expiration (Max age), and how many distinct passcodes a user must create before they can reuse a previous passcode (History limit).
    • Failed attempts before wipe — Specify the maximum number of times users can enter the wrong passcode before their device is wiped. Note the following:
      • Select Unlimited attempts if you never want to wipe a device because of failed passcode attempts.
      • On Android for Work, only the Work profile is wiped.

      • Devices are not wiped if users enter the wrong passcode less than 4 times.
      • You can allow up to 10 failed attempts before the device is wiped.
    • Device lock timeout — Specify how long after the display is turned off that the user must enter their passcode to unlock the device.

    Prompt for device passcode on 7.0+

    Important: If you configured a work passcode for your users with Android 7.0+ devices, the general device passcode policy that you may have configured above in General Requirements no longer applies to them. If you want to require these users to lock their device as well as their work profile, select Require a device passcode here, and then specify the passcode requirements.

    PIN minimum length — Minimum number of required characters (from 4 to 30).

    Characters — You can specify whether passcodes must contain at least one letter, and/or at least one symbol.

    Expiration — Either passcodes never expire (the default), or you can specify the number of days after which they expire (Max age), and the number of distinct passwords a user must create before they can reuse a previous password (History limit; prevents users from reusing a previous password for a specified period of time ).

    Failed attempts before wipe — Specify the maximum number of times end users can enter the wrong passcode before their device is wiped. Note the following:

    • Select Unlimited attempts if you never want to wipe a device because of failed passcode attempts.
    • On Android for Work, only the Work profile is wiped.

    • Devices are not wiped if users enter the wrong passcode less than 4 times.
    • You can allow up to 10 attempts before a wipe occurs.

    Work lock timeout — Use the dropdown menu to specify how long after the device display is turned off that a passcode is required to unlock the device. Note: This setting is only supported on Android devices running Okta Mobile 2.8 or higher.

Known issues

  • If they use Okta Mobile 4.21.0 on Android 11 or 12, and a passcode isn’t set up on the device, users might not be able to access Play for Work even if you change the OMM policy to allow access without a device passcode. Users receive the following message: “Play for Work is not available. Play for Work is still being enabled, please try again later.” To access Play for Work, users must set up the work profile again.
  • If users enroll in Android for Work using Okta Mobile 4.21.0 on Android 11 or 12, apps configured for the work profile are not installed automatically. However, users can download the apps from the Play for Work app store.
  • Although you configure an OMM policy to require both work and device passcode, users who enroll in the work profile with Okta Mobile 4.21.0 on Android 11 or 12 are prompted to set only the work profile password. The setup wizard doesn’t prompt users to set the device password. After setting up the work profile password, users can access their work apps.
  • Applies to Android devices running versions 7.1 or 7.1.1; fixed in 7.1.2: After an admin strengthens a group's work profile passcode policy, end users are prompted to update their passcode to comply with the updated policy. However, when end users respond to the prompt, their device passcode is updated instead of their work profile passcode. If the end user's Security settings allow different device and work profile passcodes, they are prompted continually to update their work profile passcode until they change it in their device settings.
  • On November 1, 2020 Google ended support for Native Android and Samsung SAFE enrollment types. Okta will no longer support Native Android and Samsung SAFE enrollment types in OMM policy rules on devices running Android 10 or later. Native Android and Samsung SAFE enrollment options will continue to work for Android 9 and earlier devices. Do the following:
    • If you configure new OMM policy rules, make sure to select the Android for Work enrollment type so that users on Android 10+ devices can enroll and remain compliant.
    • Check your existing OMM policy rules and update any that are currently configured with the Native Android and/or Samsung SAFE options to make sure that they also include the Android for Work option so that users on Android 10+ devices can enroll and remain compliant.
    • To force Android 10+ users to re-enroll to the Android for Work enrollment option, go to the Okta OMM devices dashboard (OMM > Okta Mobility Management) and un-enroll any Android 10+ device users that may be enrolled with the Native Android or Samsung SAFE enrollment options.

    See the Announcement Log.

  • Secure your device message doesn't appear if Okta username and Google account name don't match

    Given

    • An org configured with Android for Work Gsuite Okta Mobility Management (OMM)
    • A user assigned to that same OMM policy but not yet enrolled in OMM
    • The user's Okta username (an email address) doesn't match their Google account username
    • The user signs into Okta Mobile for Android
  • Issue

    A message prompting the user to secure their device with Okta Mobility Management doesn't appear.

Related topics