Configure Oka Device Trust for Exchange ActiveSync on OMM-managed iOS devices Skip to main content
https://support.okta.com/help/oktaarticledetailpage?childcateg=&id=ka02a0000005udjsaa&source=documentation&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fdocumentation%2fknowledge_article%2fconfigure-oka-device-trust-for-exchange-activesync-on-omm-managed-ios-devices-103912052
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Average Rating:
Configure Oka Device Trust for Exchange ActiveSync on OMM-managed iOS devices
Published: Jan 31, 2018   -   Updated: May 15, 2018

okta-doc-source

This is an Early Access feature. To enable it, please contact Okta Support.

Configure Okta Device Trust for Exchange ActiveSync on OMM-managed iOS devices


Applications > Office 365 > Mobile

This Okta Device Trust solution for Microsoft Office 365 EAS on OMM managed iOS devices allows you to do the following:

  • Configure the iOS mail app to use certificates instead of passwords to allow OMM-enrolled users to authenticate to Microsoft Office 365 Exchange ActiveSync.
  • Configure iOS mail app client access policy to prevent users with unmanaged devices from accessing Microsoft Office 365 Exchange ActiveSync.

Diagram — profile and certificate flow

EAS_DT_O365_flow3


Key benefits
  • Allows end users to seamlessly SSO in to their native iOS mail app (EAS) from OMM-enrolled iOS devices
  • Enhances Office 365 ActiveSync security through enforcement of certificate-based authentication instead of password authentication
  • Prevents users with unmanaged iOS devices from accessing Office365

  • Helps prevent users from becoming locked-out of their account due to Active Directory (AD) password resets

Requirements
  • An Office 365 tenant federated to an Okta org with at least one license for Exchange Online
  • A Windows computer to run PowerShell commands
  • Azure PowerShell 5.0 (64-bit)
  • An iOS 9 (or higher) device

Procedure

This procedure has three phases:

Phase Ⓐ — Enable ActiveSync certificate-based authentication in Office 365

Phase Ⓑ — Distribute certificates for EAS to OMM-enrolled devices

Phase Ⓒ — (Optional) Prevent unmanaged devices from accessing Office 365 email using the iOS Mail app (EAS)


Phase Ⓐ — Enable ActiveSync certificate-based authentication in Office 365

Important: Do not click Save at the end of Step 1. You will save changes in Phase Ⓑ.

  1. From the Okta admin console, prepare to enable certificate distribution for OMM and download the Okta root certificate:

    Note: If you have set up multiple Office 365 app instances in your org, note that Okta generates a different Okta CA certificate for each Office 365 app instance/domain. This means that you must upload a separate root certificate for each Office 365 app instance/domain that you want to configure with certificate based authentication.

    1. Go to Applications and click the Office 365 app instance.
    2. Go to the Mobile tab, scroll down to the Exchange ActiveSync Settings and click Edit. Screenshot

      EAS_CBA_O365

    3. Select Enable Exchange ActiveSync.
    4. Enter a profile name.
    5. Select Enable certificate-based authentication for iOS.
    6. Click Download root certificate.
    7. For use later in this procedure, copy and paste the Certificate Revocation List URL and the Delta Certificate Revocation List URL into a text editor. Screenshot

      EAS_CBA_O365_CLR-DRL

    8. Stop: Do not click Save yet. You must complete the PowerShell actions detailed in Step 2 before you save your Exchange ActiveSync settings. If you save now and then encounter a problem when enabling ActiveSync Cert Based Authentication in Office 365, your users may not be able to access their mail app.
  2. From a Windows command line, enable ActiveSync Cert Based Authentication in Office 365:
    1. Launch Azure PowerShell 5.0 (64-bit) as an Administrator.

      Important: An error message appears if you try to use the x86 (32-bit) version of PowerShell.

    2. Issue the following command to install the AzureAD module for PowerShell:

      Install-Module -Name AzureAD –RequiredVersion 2.0.0.33

      • If the message NuGet provider is required to continue appears, click Yes to install and import NuGet provider.
      • If the message Untrusted repository appears, click Yes to All to install the required modules.
    3. In PowerShell, issue the following command to connect to your Azure AD tenant and authenticate to Office 365:

      Connect-AzureAD

    4. Enter your Office 365 credentials in the Azure Active Directory sign-in screen.

    5. To create the necessary PowerShell variables, issue the following commands in PowerShell:

      $cert=Get-Content -Encoding byte "LOCATION OF YOUR CER FILE\filename.cer"

      Make sure to replace LOCATION OF YOUR CER FILE\filename.cer with the path and filename of your *.cer file.

      $new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation

      $new_ca.AuthorityType=0

      $new_ca.TrustedCertificate=$cert

    6. To enable certificate revocation in Office 365, issue the following commands, making sure to paste the revocation URLs that you saved earlier: Screenshot

      EAS_CBA_O365_CLR-DRL

      $new_ca.crlDistributionPoint = "CERTIFICATE REVOCATION LIST URL"

      Replace CERTIFICATE REVOCATION LIST URL with the Certificate Revocation list URL that you saved earlier.

      $new_ca.deltaCrlDistributionPoint = "DELTA CERTIFICATE REVOCATION LIST URL"

      Replace DELTA CERTIFICATE REVOCATION LIST URL with the Delta Certificate Revocation list URL that you saved earlier.

    7. To add the appropriate certificate authority in Office 365, issue the following command:

      New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca

    8. To confirm that the certificate authority was added to Office 365, issue the following command:

      Get-AzureADTrustedCertificateAuthority

      ScreenshotEAS_Cert_Install_CLI_867x361

    9. (Optional) Issue the following commands to help troubleshoot your configuration, if necessary:
      • If you want to add the existing Certificate Authorities to a variable:

        $c=Get-AzureADTrustedCertificateAuthority

      • If you want to remove a Certificate Authority, issue the following command and choose the correct certificate. Numbering begins at 0 (zero). For example, to remove the first certificate, enter 0 as shown below:

        Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0]

  3. Important: Tell your end users how the above configuration may affect their device and mail account. For details, carefully review the section Known Issues.

Phase Ⓑ — Distribute certificates for EAS to OMM-enrolled devices

  1. Make sure to advise your end users to remove any manually-configured EAS profiles that may be installed on their device.
  2. In the Okta admin console, return to the Exchange ActiveSync Settings dialog box and click Save.
  3. Click Save in the Confirm Exchange ActiveSync changes message.

Phase Ⓒ — (Optional) Prevent unmanaged iOS devices from authenticating to Office 365

Note: Only configure this phase if your users have been notified to enroll in Okta Mobility Management.

  1. Configure the Office 365 client access policy: Screenshot

    ClientAccessPolicies_DT_EAS_iOS

    1. In Okta, go to Applications and click the Office 365 app instance.
    2. Click the Sign On tab, scroll down to the Sign On Policy, and click Add Rule.
    3. Enter a name for the rule and apply it to the appropriate group or users.
    4. In the Client section, select Mobile (Exchange ActiveSync) and iOS.
    5. Important: Make sure the other options are not selected.

    6. In the Actions section, change the Access setting for When all the conditions above are met, sign on to this application is to Denied.
    7. Click Save.
  2. Using an OMM-enrolled iOS device, verify the Device Trust configuration:
    1. Ensure that the OMM-enrolled iOS device is covered by an appropriate Okta mobile policy.
    2. Launch the native iOS mail app and confirm that email works without the need to authenticate to Office 365.
    3. Manually create an EAS mail account on the native iOS mail app to confirm that Okta is blocking manually-configured email accounts.

Known Issues
  • Continuous password prompt caused by duplicate EAS profiles — iOS 9.3 and iOS 10.2 device users who manually configure the native iOS mail app before enrolling in OMM will have duplicate EAS profiles on their device after OMM enrollment pushes a certificate-based profile to their device automatically. On iOS 9.3 devices, this duplication may cause confusion. On iOS 10.2 devices, in addition to the profile duplication issue, the manually-configured profile does not receive email and continuously prompts for a password. To address these issues, we recommend that you advise your users to delete the manually-configured profile from their device. As shown in this example, the password prompt appears continuously.

    Duplicate EAS-profiles

  • Currently, this feature supports only the native iOS mail app on iOS devices.
  • Users may be prompted for credentials — If you unassign and then reassign a CBA-configured Office 365 app instance to users or groups, users trying to access the EAS-enabled native iOS mail client are prompted to enter their credentials. Even after entering credentials, users still receive the message Cannot Get Mail. Users may need to wait up to several hours before they can access email.

  • Block access to Outlook for iOS or Android — If you don't want your end users to access Outlook for iOS or Android, you can block access as described in the Microsoft article Enabling Outlook for iOS and Android in Exchange Online. Scroll down to Blocking Outlook for iOS and Android.
  • CRL cache must refresh — When Okta revokes a certificate — or if the trusted root CA certificate is removed from Exchange Online/O365/Azure AD — CBA EAS-enabled devices using the certificate can still access email until the next time Office 365 invalidates the Certificate Revocation List (CRL) cache and refreshes the CRL. When the cache is refreshed, Microsoft denies the device access to email. Microsoft cache expires once every 24 hours, or whenever the device switches to a different Wi-Fi network.

  • More than one OS type in the header when using the Outlook mail app — When Okta receives a request from the Outlook Mail app on iOS and Android devices, the header contains both iOS and Android, which prevents Okta from precisely identifying the OS type. To ensure that the client access policy is applied in this case, select the Others option in the Mobile (Exchange ActiveSync) client access policy. For more information, see Configuring Rules for Office 365 Client Access Policies.

Post a Comment