Certificate-Based Authentication (CBA) for Exchange Online

The_Exchange_Team

Microsoft

Jul 19, 2016

Update 6/6/2017: We updated this post to reflect availability for China plans.

Update 7/28/2017: Updated with links for support with Outlook for iOS and Android.

On-premises Exchange environments support the ability for certain mobile apps to utilize certificate-based authentication (CBA). Today, we are pleased to announce that CBA is available for customers using Office 365 Enterprise, Business, Education, Government, and China plans. This does not include Office 365 Defense. It will be available for Office 365 Defense and other Office 365 plans at a later date. This feature is available in Outlook for iOS, Outlook for Android and the Exchange ActiveSync (EAS) protocol.

What is certificate-based authentication?

CBA allows users to authenticate using a client certificate. The certificate is used in place of the user entering credentials into the device.

Why would I want certificate-based authentication?

By utilizing certificate-based authentication, administrators can allow their users to access resources without the need to enter credentials.

Prerequisites

The following are required to use CBA:

Access to a certification authority (CA) to issue client certificates.
For Office mobile clients, like Outlook for iOS & Android, a federation server; for more information on how to configure, see ADFS: Certificate Authentication with Azure AD & Office 365.
Each CA must have a certificate revocation list (CRL) that can be referenced via an Internet-facing URL.
Client certificates must be provisioned on mobile devices, typically done using MDM.
For EAS clients, the RFC822 Name OR Principal Name value in the certificate’s Subject Alternative Name field must have the user’s email address.

Figure 1: Client certificate with email address in RFC822 Name and Principal Name values in the SAN field

Using certificate-based authentication

Configuration in Azure Active Directory is required to use certificate-based authentication. All certificate authorities (and their associated CRL URLs) must be uploaded to Azure Active Directory. More information on getting started with CBA can be found in Get started with certificate-based authentication.

Certificate-based authentication in Outlook for iOS/Android

Certificate-based authentication is supported with Outlook for iOS and Android for Office 365 accounts. For more information and requirements, please see:

Certificate-based authentication in Exchange ActiveSync applications

Certain EAS applications may support certificate-based authentication. To determine if your application supports CBA, contact the application developer. Preview documentation on how EAS applications can support CBA can be found in Microsoft Exchange protocol documentation. Tyler Lenig Program Manager Office 365

Updated Jul 01, 2019

Version 2.0

Microsoft

Joined April 19, 2019

View Profile

Exchange Team Blog

You Had Me at EHLO.

Deleted
Jul 19, 2016
Will this be coming to Office 365 Government plans in the near future?
- Deleted
  Jul 19, 2016
  Mike/Jim, support for Office 365 Government is not included in the preview but is on our radar for when the feature is released in general availability.
  - Deleted
    Jul 19, 2016
    Glad it's available now that it's in GA. Thanks.
- Deleted
  Jul 19, 2016
  I'm interested in the answer to this question. We are in the GCC - will this be available to Government customers in the GCC?
Deleted
Jul 20, 2016
To be clear, should the SAN in the cert be the UPN or the email address? I'd be careful to not make assumptions that they are the same.
- Deleted
  Jul 20, 2016
  Alex F,
  If i may clarify to save wading through documentation and IETF RFC's,
  The Subject Alt Name is a complete field which is an extension of the X.509 certificate definition. Their are multiple options for the values in this field which comply with the X.509 specifications.
  In this instance Microsoft are stating that when using EAS, the RFC822 value or the Principal Name value should be the email address of the specific user (ergo their client certificate) wishing to authenticate using this mechanism.
  You are correct - the UPN of a user and their email address may certainly differ and in many cases most certainly will be different as the Active Directory domain a user logs into (locally defined) will definitely not match the email address containing an externally resolvable domain name (necessary for Office 365 operation with DNS queries etc,)
  In the case of authentication against an Exchange based public facing system using EAS, the identifier Microsoft are using in this instance (using a digital certificate containing multiple system identifiers and unique user identifiers) is the SAN field and specific values they have chosen to use that match the rest of their architecture based on extensions (the SAN field) the X.509 specification allows.
  It would not be correct to use a UPN, as it would not be within an externally resolvable domain (wouldn't necessarily match the email address) and therefore not be able to matched against a similar value in the Certificate Revocation List, published by the CA that created the client certificate in the first place, which has to be public (internet) facing for the Office 365 revocation checking routine to operate. Coupled with the fact that the SAN field has to comply in parts with the RFC822 spec which would negate some variations of the UPN format.
  In other words, to place a non public identifier (UPN) on a public facing system that requires public facing mechanisms to check its validity against a public facing Office 365 would not work (or be a good idea.)
  Hope that helps.
  Or lookup the RFC3280 spec from the IETF for the SAN extension if you are wanting some specialist X.509 knowledge.
  - Deleted
    Jul 20, 2016
    Mark is correct, this requirement is intended to indicate that in the EAS case, the user's email address must be in the Principal Name value or the RFC822 Name value of the SAN field of the certificate. In some cases, the UPN is the user's email address but this is not necessarily always the case. Admittedly, this requirement is rather tricky so please do feel free to let us know if you do encounter issues configuring this item.
Deleted
Jul 21, 2016
Will this introduce the same problem that Lync had with certificate based Auth, whereby an AD disabled user could continue to access the service as they are not required to reauthenticate for 180 days?
Deleted
Jul 21, 2016
"A federation server that is configured to perform certificate-based user authentication is also required when using Outlook for Android."
Does this mean it's only supported with federated tenants?
- Deleted
  Jul 21, 2016
  Andy, that is correct, federation is required when using the Outlook for Android application. More information around this can be found at the Get started with certificate-based authentication on Android - Public Preview link: https://azure.microsoft.com/en-us/documentation/articles/active-directory-certificate-based-authentication-android/
  - Deleted
    Jul 21, 2016
    What about non ADAL based mail client such as native iOS mail.
    For pure activesync client I was able to configure a non-federated O365 tenant to allow certificate based authentication.
    I am however still looking for a way to enforce certificate based auth and prevent username/password.
    Is there a way to do it without federation?
Deleted
Jul 22, 2016
This is a good start!
Now within Intune we need to be able to assign a profile to Outlook with the SCEP profile issued cert .. much like we can do with native email clients.
Cheers
- Deleted
  Jul 22, 2016
  Glad this is helpful, thanks Aengus!
Deleted
Aug 25, 2016
Hi
A lot of this appears to depends on ADFS infrastructure and federated domains.
What happens if we have set to use Azure AD as the authentication source with password hashes in the cloud. Thus removing domain federation. How would CBA work then?
Gary Smith
Brass Contributor
Sep 30, 2019
An old thread/link, but has some relevance now as MS are depreciating basic authentication for EAS. In our case simply pushing out android/ios app for outlook isn't viable. We will need to use EAS short term.
MS have confirmed CBA may achieve this for EAS devices...

Blog Post