Thursday, December 9, 2021

The Deprecation Of Basic Auth For Exchange And What It Means For VMware's Workspace ONE Customers

After several delays due to Covid-19 Microsoft has finally fixed a date for prohibiting Basic Auth in Exchange Online.  As of October 1st, 2022, Microsoft will begin disabling Basic Auth in all tenants, with short-term temporary disruptions for some customers beginning early 2022.  This news is initially a bit unnerving given that historically a lot of AirWatch/Workspace ONE customers have leveraged Basic Auth within their ActiveSync profiles.  However, it is limited to Exchange Online customers so on-premises Exchange customers, at least for now, need not worry.   Further, for existing Exchange Online WS1 customers leveraging Basic Auth there's a clear path forward through the adoption of Modern Authentication or other OAuth based alternatives.  This post begins with a quick overview of the ActiveSync Basic Auth deprecation and why it's relevant, then details the choice between Microsoft's Modern Auth or other OAuth based solutions for addressing the challenge.   Of all these OAuth based alternatives Workspace ONE Access is certainly my favorite, so I'll detail the magic that happens when you federate Azure AD with Workspace ONE Access and then introduce certificate based authentication with VMware's proprietary Mobile SSO solution. 

A MEM Misnomer: Rumors Of ActiveSync's Death Are Greatly Exaggerated


About a year and a half ago I started hearing grumblings of impending doom for WS1 customers and Mobile Email Management (MEM) in general.    The rumor went something like this: ActiveSync is getting deprecated which will lead to chaos in MEM everywhere, possibly triggering World War 3.   Making it somewhat believable was that ActiveSync hasn't been worked on for years now, with the latest version of 16.1 released in 2016.   Coupled with Microsoft's hyper focus on GRAPH APIs, in a bad mood, with your eyes squinted, it seemed possible ActiveSync could be going away.   However, the truth was more nuanced.  In August of 2020 I reached out to Martin Kniffin for guidance and he didn't fail to impress,  providing me and a handful of colleagues excellent context.   First and foremost he pointed out that it's not ActiveSync that's getting deprecated, but Basic Auth within ActiveSync. (More specifically, it's Basic Auth that's being deprecated almost across the board, not just within ActiveSync.)   When Basic Auth is used with Exchange Online you have the mail client storing a user's typed in credentials and then passing those credentials to Exchange, which in turn proxies those credentials to Azure AD.  These stored credentials on the endpoint device are constantly replayed against Exchange Online throughout the course of email access.   
 
Basic Authentication - Image taken from, "Disable Basic Authentication In Exchange Online"
So it's not ActiveSync that's dying off but rather this very rudimentary Basic Auth model that's going away, initially only in Exchange Online environments, not on-premises.   This deprecation has been in the works for awhile. Plans to disable Basic Auth in Exchange Online were first announced in Sept of 2019 with a target date of Oct 2020.   However, in response to Covid-19 it was postponed till the second half of 2021. Then in February of 2021 Microsoft indicated they would postpone until further notice.   At the same time they announced plans to begin disabling Basic Auth for tenants not currently using it.  Now, finally in late September of 2021, it was announced that Basic Auth would be disabled on all tenants starting October 2022, with more formal guidance coming out early November this year.  So, this hasn't exactly been a meteor the size of Texas hurling towards earth from out of nowhere.   More like The Blob, a really, really, really slow moving blob that, nonetheless, needs to be addressed. 


While ActiveSync payloads with Basic Auth have been wildly popular amongst Workspace ONE customers there's a clear path forward: leverage the OAuth ActiveSync payload setting for use with Microsoft's Modern Auth or a 3rd party federated IDP.    

Leveraging Microsoft Modern Auth With The ActiveSync OAuth Payload Setting

If your Office 365 tenant is purely leveraging Azure for identity, with no federation, both Basic Auth and Modern Auth are currently options for email access.   Modern Authentication is a Microsoft solution, "based on the Active Directory Authentication Library (ADAL) and Oauth 2.0."  With Modern Auth users authenticate with their AD credentials to Azure and then are issued a token granting access to Office 365.   So instead of having credentials stored within a mail client and proxied through Exchange Online, users are redirected to Azure at login.microsoftonline.com and upon successful authentication are issued a token that grants access to email, as well as the entire Office 365 suite.    

Modern Authentication Workflow - Image Borrowed From Shehan Perera's Tech Blog

In the diagram above you have a representation of Modern Auth in the context of a hybrid identity model that merges on-premises AD environments with an Azure tenant, allowing users to leverage their on-premises AD credentials when authenticating to Azure.  It starts with an on-premises Azure AD Connect instance that syncs accounts from on-premises with Azure. Then for authentication there's what's referred to as managed authentication, with a choice between password hash authentication (PHS) and pass-through authentication. (PTA)  With PHS hashes of your AD passwords are synchronized from your on-premises AD environment to the cloud. 

With PTA instead of having hashed passwords stored in the cloud validation occurs directly against your on-premises AD environment via an on-premises agent.  


Either model is supported with Modern Auth and the ActiveSync, "Use OAuth," payload setting. It's just a matter of personal taste for the organization. With both models you're extending your on-premises authentication to Azure and either one can work with the OAuth payload. As far as the ActiveSync payload settings in WS1 goes, all you have to do is check the box for, "Use OAuth, " and your email users will start getting prompted for Modern Auth. The, "OAuth Sign In URL," and, "OAuth Token URL," fields are not mandatory and can be left blank.  When you leaves these fields blank an autodiscovery process kicks in, one that first redirects login.microsoftonline.com.

The redirect to login.microsoftonline.com creates a slightly different experience from the traditional Basic Auth workflow, but it's not insurmountable.  Below is a recording that compares and contrast the two experiences with the built in iOS mail client. 

Also, there's certainly support for Modern Auth from most other mail clients as well, such as Boxer or Outlook. Here's what the process looks like for Boxer: 

 

Leveraging Workspace ONE Access With The ActiveSync OAuth Payload Setting

Along with Modern Auth, this, "Use OAuth," feature supports authentication against Workspace ONE Access, as well as various other federated IDPs such as ADFS, Okta or Ping.  When it's time to authenticate the user first hits login.microsftonline.com, then based on their email address gets redirected to a federated IDP.    In this example, AD authentication occurs through an instance of WS1 Access that's been federated with Azure.   It's very similar to Microsoft's Modern Auth model, except there's a redirection to a WS1 Access tenant where credentials are manually entered.  Here's a demonstration: 

For a more ideal experience you can accommodate authentication with  Mobile SSO for iOS, an incredibly compelling proprietary VMware solution that combines WS1 UEM with WS1 Access to provide SSO for mobiles apps. 

First and foremost, VMware's Mobile SSO solution provides an incredibly convenient certificate based single sign-on experience.  It also lays the ground work for the adoption of device compliance policies that allow us to factor in device enrollment and device posture while providing contextual authentication through conditional access policies.  Further, this solution extends device compliance security against the entire Office 365 suite, not just email access.  Even more exciting, since Mobile SSO for iOS or Android works for pretty much any Mobile App that supports SAML, adopting this solution for Office 365 puts into place a capability for securing mobile SaaS adoption across the board.  Combine this with VMware's certificate based authentication for modern management and you have a complete solution for layering zero trust security on top of SaaS adoption across most conceivable device types.  











One caveat to be aware of is that federation with an IDP like WS1 Access or other 3rd party solution is an all-or-nothing commitment.   You can't just have a subset of users handled by the federated IDP.  All of them will get initially redirected to the 3rd party IDP.    So before actually federating with another IDP you need to make sure that all your Office 365 users can be properly handled by it.  Further, federation will break Basic Auth, so you'd need to prepare accordingly.  

 

SEG For Office 365 Access

Many folks have quite a visceral response to the deployment model I'm about to mention. There are indeed some organizations that leverage SEG for Office 365 access.  I know, I know. While I can't throughly explain or exhaustively defend the design decision, to my understanding there are some use cases where this is a valid and legitimate option.  More customers than you'd image have needed it. 

I only bring it up here in the context of this ActiveSync discussion because with this model there is some authentication against Exchange Online, so it's possible a subset of folks with this type of deployment could be using Basic Auth.  Fortunately, these users can migrate to OAuth access as well.  Here's a sample from my own lab:














The Only Way Through Is Through - Tick Tock, Tick Tock

In a nutshell, the deprecation of Basic Auth is forcing customers to fall back to Modern Auth/OAuth, or, more accurately, fall forward to Modern Auth/OAuth.  As easy as it's been to just leverage Basic Auth we really should have already been marching away from it anyway, regardless of deprecation plans.  While I don't normally feel the need to defend a monster corporation like Microsoft, technically, it sounds like they're just forcing customers to do what they ought do.  Regardless, Workspace ONE/AirWatch has helped customer's navigate their mobile email management needs for over 10 years and is well positioned to assist with this challenge.  

There's no doubt in my mind that some VMware customers may still have some planning to do.  As of the time of this writing, early December 2021, customers have about 9 and half months to act.  Fortunately, Basic Auth is not dead yet, though the writing is certainly on the wall.  




13 comments:

  1. Hi there,

    I am keen to understand the last scenario where Modern Auth with SEG is configured. For OAuth do you use dedicated IdP's like Ping or Okta or you leverage Azure Oauth creds.

    Please advise as this was not shown on the screenshot.

    Kind Regards,
    Siva

    ReplyDelete
    Replies
    1. Siva, I can say for a fact that's Microsoft's implementation of Oauth, Modern Auth, will work with SEG in the deployment model detailed above. I've also seen it work for Workspace ONE Access and OAuth. However, I can't for a fact how it would work out for Okta or Ping, so I'd recommend doing some testing.

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. Hi, Our O365 tenant is federated to OKTA for authentication. In this scenario how can we use oAuth in Active Sync Profile?

    Thanks in Advance.

    ReplyDelete
    Replies
    1. I believe the, "Use OAuth," checkbox would do the trick for Okta. Autodiscovery should end up redirecting you to Okta for authentication, similar to how it works for WS1 Access.

      Delete
    2. Thanks for your reply. Appreciate it. How can we achieve the same oAUTH for Android native email client (Gmail)?

      Delete
    3. I imagine it's possible, but don't have the ability to test in my lab right now. Most likely it would involve app config settings.

      Delete
    4. I went down this rabbit hole recently. The managed version of gmail on Google Play has appconfig options to control basic/modern auth. The pre-installed OEM gmail app does not have these appconfig settings. My understanding is that modern auth is enabled by default on most pre-installed gmail apps that OEMs include, but I'd push out the play version to make sure everyone is getting the same client. My two cents from playing with this in the lab.

      Delete
  4. Hello, We have MEM configuration in place to whitelist native email clients using powershell integration. We only allow managed devices to configure Native emails. Now we want to enable users to use Outlook Mobile the same way i.e. allow Outlook mobile only if a device is enrolled, how can we enable users to use Outlook Mobile with MEM configuration? Our O365 tenant is federated to OKTA.

    ReplyDelete
    Replies
    1. I have the same question like you..

      Delete
    2. It seems microsoft is forcing us to use outlook for mobile that's why they disabling basic auth and supporting OAuth .. ho we can allow outlook mobile app with airwatch and how we can protect them via airwatch ..it seems we need to protect the app only via intune

      Delete
  5. I read your article and it was very informative and allowed me to resolve an issue I had based on Modern Authentication / /OAuth. Well written and easy to understand. Thankyou so much.

    ReplyDelete
  6. you used to be able to deploy Outlook to devices via WS1 and if there was no app config supplied, or the AccountType variable was not set, the default would be ModernAuth (if enabled in O365) from what I understand. I can see in the latest Microsoft documentation (https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/outlook-for-ios-and-android-configuration-with-microsoft-intune#account-setup-configuration) that com.microsoft.outlook.EmailProfile.AccountType may now be a required field, which leads me to wonder what will happen to in-use devices with the app config that does not include that now-required field.... even further, what happens to devices that are yet to receive the profile and will now install a possibly malformed app config.

    ReplyDelete