Tech

Certificate Based Authentication to Exchange Online using MobileIron Cloud Local CA

Timothy Duong

Timothy Duong

— 4 min read

This article will briefly walk-through on how to enable Certificate Based Authentication (CBA) to Exchange Online using MobileIron Cloud's Internal Local CA capabilities for automated, streamlined authentication when using iOS's Native Mail App.

Microsoft enabled the functionality for CBA to Exchange Online sometime in 2016, although it has a narrow use case; it's a solution worth having a look if your MDM and AAD set-up is similar since it reduces the on-boarding friction and monthly / quarterly password updates.

MobileIron Cloud is a suitable candidate for this solution; this is because MobileIron Cloud's Local CA capabilities fit the requirements of Azure AD's CA CRL requirements; as the CRL is publicly accessible. This makes it convenient to deploy this solution for iOS end users when using iOS's Native Mail Client.

This walk-through will not cover the MobileIron configurations of Exchange Profile or Identity Certificate.

Usage in Production Notes

This is not recommended for a Production Solution as the CA and auth relies on MI Cloud's uptime. Should MI Cloud be down for maintenance, access to emails may be impacted.

Prerequisites:

  • MobileIron Cloud with Local CA configured
  • Azure AD enabled and Federated to ADFS 2.0+
  • Basic Authentication is enabled for Exchange Online
  • iOS Native Mail Client as primary Mail Client

Setting the Trusted Cert Authority on Azure AD

  • Log into MobileIron Cloud Admin Console
  • Navigate to Admin > Infrastructure > Certificate Authority
  • Download your MobileIron Certificate and take note of the MobileIron CRL URL to a local location to be used in future (I saved mine to a Windows machine as my Mac couldn't run all the Azure AD Powershell commands)

Open up Powershell, connected to Azure AD using a Global Administrator Account, run the following commands replacing the MobileIron Certificate Location and MobileIron CRL URL with your corresponding values.

# Connect to Azure AD
Connect-AzureAD

# Extract the Encoding Information into $cert
$cert=Get-Content -Encoding byte "C:\Users\Administrator\Desktop\cert.cer"

# Set the CA Certificate Type
$new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
$new_ca.AuthorityType=0
$new_ca.TrustedCertificate=$cert

# Set the CA CRL URL
$new_ca.crlDistributionPoint="http://ap2.mobileiron.com/c/ca/12345/MI%20Cloud%20-%20Local%20CA.crl"

# Command to Set the CA using the above $references
New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca

Testing the CA was uploaded successfully

Run the following PowerShell command to confirm that your Azure AD tenant has a trusted Root CA info set.

Get-AzureADTrustedCertificateAuthority

ADFS Changes

Enabling ADFS Certificate Authentication

  1. Edit the ADFS Authentication Methods for 'Certificate Authentication' under Extranet, set this value to Enabled.
  2. Make sure that Network Port 49443 is available externally to your ADFS & WAP Server. Devices will use Port 49443 when performing Cert-Based Auth to the WAP / ADFS server.

ADFS Transform & Issuance Rules

Log into your ADFS Server and via the AD FS Management tool, edit the following Claim Rules for your Active Directory from Claims Provider Trusts and Claim Issuance Policies for the Relying Party Trusts.

These are necessary to allow ADFS to revoke Certificates.

Add these Custom Rules as Send Claims Using a Custom Rule, you will be required to add them separately via the Add Transform Claim Rule Wizard. (Give them friendly names to easily identify them in future)

c:[Type == " http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber"] => issue(claim = c);
c:[Type == " http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer"] => issue(claim = c);

The following Claims are to be added to the Office 365 (Microsoft Office 365 Identity Platform Worldwide) Relying Party Trusts as Custom Claim Issuance Policies (Also give them friendly names to easily identify them in future)

c:[Type == " http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber"] => issue(claim = c);
c:[Type == " http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer"] => issue(claim = c);

Configuration of Device Profiles on MI Cloud

On MobileIron Cloud, configure an Identity Certificate profile that deploys the User Principal Name or the RFC822 Name Value of the Subject Alternative Name Field.

A Certificate Profile was already configured in MobileIron Cloud that had the following SAN values:

The Native Mail Exchange Profile had the following notable settings

Exchange URL: outlook.office365.com
Username / Email Address: ${userEmailAddress}
Identity Certificate: <The Certificate Profile from above>
Enable OAuth for Exchange Payload: False

Deployment to the device is straight forward, the profile should deploy to the device containing the Certificate, Exchange configurations.

The device should have no prompts for passwords or errors.

Considerations

Here are some notable additional configurations that may need to be taken into account:

  • MobileIron Access: If you have MI Access enabled, play around and configure a pass-through value for Exchange / Baseline authentications
  • Basic Authentication vs Modern Authentication: If Basic Auth can be enabled, you will need to disable it in multiple locations; Azure AD, MI Cloud Exchange Configuration and MI Access's Access Policies

External Resources

The following vendor resources were helpful to get this enabled: