This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it, please contact Okta Support.
This Okta Device Trust solution for Microsoft Office 365 EAS on OMMAn acronym for Okta Mobility Management. OMM enables you to manage your users' mobile devices, applications, and data. Your users enroll in the service and can then download and use managed apps from the Apps Store. Managed apps are typically work-related, such as Box or Expensify. As an administrator, you can remove managed apps and associated data from users' devices at any time. You can configure policies, such as data sharing controls, on any of your managed apps. See Configuring Okta Mobility Management for more information. managed iOS devices allows you to do the following:
- Configure the iOS mail appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. to use certificates instead of passwords to allow OMM-enrolled usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. to authenticate to Microsoft Office 365 Exchange ActiveSync.
- Configure iOS mail app clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. access policy to prevent users with unmanaged devices from accessing Microsoft Office 365 Exchange ActiveSync.
- Allows end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. to seamlessly SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. 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
- An Office 365 tenant federated to an Okta orgThe Okta container that represents a real-world organization. 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
This procedure has three parts:
Important: Do not click Save at the end of Step 1. You will save changes in Part Ⓑ.
- From the Okta AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. 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/domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https).. 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.
- Go to Applications and click the Office 365 app instance.
- Go to the Mobile tab, scroll down to the Exchange ActiveSync Settings and click Edit.
- Select Enable Exchange ActiveSync.
- Enter a profile name.
- Select Enable certificate-based authentication for iOS.
- Click Download root certificate.
- 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.
- 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.
- From a Windows command line, enable ActiveSync Cert Based Authentication in Office 365:
- 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.
Issue the following command to install the AzureAD module for PowerShell:
Install-Module -Name AzureAD –RequiredVersion 126.96.36.199
- 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.
- In PowerShell, issue the following command to connect to your Azure AD tenant and authenticate to Office 365:
Enter your Office 365 credentials in the Azure Active Directory sign-in screen.
- 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
- To enable certificate revocation in Office 365, issue the following commands, making sure to paste the revocation URLs that you saved earlier: Screenshot
$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.
- To add the appropriate certificate authority in Office 365, issue the following command:
New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca
- To confirm that the certificate authority was added to Office 365, issue the following command:
- (Optional) Issue the following commands to help troubleshoot your configuration, if necessary:
If you want to add the existing Certificate Authorities to a variable:
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
- Launch Azure PowerShell 5.0 (64-bit) as an Administrator.
- Important: Tell your end users how the above configuration may affect their device and mail account. For details, carefully review the section Known Issues.
- Make sure to advise your end users to remove any manually-configured EAS profiles that may be installed on their device.
- In the Okta Admin Console, return to the Exchange ActiveSync Settings dialog box and click Save.
- Click Save in the Confirm Exchange ActiveSync changes message.
Note: Only configure Part C if your users have been notified to enroll in Okta Mobility Management.
- Configure the Office 365 client access policy:
- In Okta, go to Applications and click the Office 365 app instance.
- Click the Sign On tab, scroll down to the Sign On Policy, and click Add Rule.
- Enter a name for the rule and apply it to the appropriate group or users.
- In the Client section, select Mobile (Exchange ActiveSync) and iOS.
- In the Actions section, change the Access setting for When all the conditions above are met, sign on to this application is to Denied.
- Click Save.
Important: Make sure the other options are not selected.
Using an OMM-enrolled iOS device, verify the Device Trust configuration:
- Ensure that the OMM-enrolled iOS device is covered by an appropriate Okta mobile policy.
- Launch the native iOS mail app and confirm that email works without the need to authenticate to Office 365.
- Manually create an EAS mail account on the native iOS mail app to confirm that Okta is blocking manually-configured email accounts.
- 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.
- 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 groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with 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.