Preparing for Modern Authentication: Identifying client auth methods.

Who is still connecting via old protocols in your org?

Microsoft long ago announced the depreciation of legacy protocols to Exchange Online, their deadline is now upon us with Microsoft opportunistically disabling basic auth on tenants from October 1st 2022. You can still apply for an extension until January 2023 (Not recommended but if you really want to apply for an extension you can do so here LINK) and organizations’ user base should have already patched their apps and moved to modern auth long ago.

Unsurprisingly due to the nature of the sheer amount of applications that rely on email access, some orgs may not yet be ready for the changes – here is what you can do to prepare below.

Check if basic authentication is enabled in your org

We can leverage the Exchange Online Powershell cmdlets to effectively see whether or not basic auth is enabled per tenant:

#Connect to your EXO instance

#Confirm if basic auth protocols are enabled

#In this example we can see basic auth is enabled for protocols such as SMTP
PS C:\Users\user> Get-AuthenticationPolicy |fl *basic*

AllowBasicAuthActiveSync           : True
AllowBasicAuthAutodiscover         : True
AllowBasicAuthImap                 : True
AllowBasicAuthMapi                 : True
AllowBasicAuthOfflineAddressBook   : True
AllowBasicAuthOutlookService       : True
AllowBasicAuthPop                  : True
AllowBasicAuthReportingWebServices : True
AllowBasicAuthRest                 : False
AllowBasicAuthRpc                  : True
AllowBasicAuthSmtp                 : True
AllowBasicAuthWebServices          : True
AllowBasicAuthPowershell           : True

You may also wish to disable these protocols to prohibit the use of basic auth in your org:

#Create a new authentication policy, by default in new policies basic auth is disabled
New-AuthenticationPolicy –Name “Disable Basic Auth"

Set-OrganizationConfig -DefaultAuthenticationPolicy "Disable Basic Auth"

Audit your client connections in Azure AD

The Azure AD sign-in audit log leverages a filter to easily drill down to who is using modern or basic auth methods.

Head over to the Azure AD admin centre, from the dashboard > Users > Sign-in logs. Choose Columns and make sure Client App is ticked, this will show us the method of authentication used in the login session.

You can then use Add filters and choose the field Client App, from here we will create filters for Modern Authentication Clients or Legacy.

Tick every option under Legacy Authentication Clients.

If any results hit your criteria, you should now see a log of recent sign in events, this is usually 7 day’s worth unless you are on an Azure AD P1 or similar to see back further. If you receive no results this is an indicator that your users are likely using modern authentication.

However in this example we are able to see a user sign in using basic auth. We can use information like date, user, IP address and client app to diagnose why this user may be connecting in this way. In this case the method of connection is Autodiscover, which is most likely an Outlook client using MAPI over HTTP which does not utilize the modern authentication protocols to connect.

It may be useful to choose Download in the top right to load these results in Excel. I recommend the json format and loading this into a table in Excel.

Identify if Outlook is using modern protocols.

It is also possible to confirm whether Outlook is connecting using modern auth by examining the connection status. Ctrl + right click the Outlook icon in the task tray and choose Connection Status…

If the connection to Exchange Online shows Clear* then this suggests basic authentication.

However if you see Bearer* then the modern set of authentication protocols are being used.

Up to date Outlook clients should opportunistically use modern auth where possible, however you can leverage the below registry key commands to enforce this:

REG ADD "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Exchange" /v AlwaysUseMSOAuthForAutoDiscover /t REG_DWORD /d 1

Additionally, it is worth checking the below keys do not exist (swapping “x.0” for your version of office e.g 16.0 for 2016 onward).

This key was used to force outlook to ignore checking 365 for an account during the autodiscovery process.

[HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover] "ExcludeExplicitO365Endpoint"=dword: 00000001

This key disabled modern authentication protocols from being used to connect via office apps.

[HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Common\Identity] "EnableADAL"=dword:00000000

Contact your user base.

Consider contacting your user base and warning them about upcoming changes.

  • iOS, Apple has supported Oauth2 since around iOS11 with support within the Mail as well as the option to download the official Outlook app. It is worth noting that users using the iCloud restore process when moving to a new handset, have on occasion reported it to pull over basic auth settings from the previous backup, and thus the account needs re-adding to move to modern auth.
  • MacOS features support since version 10.14, so both Mac Mail and Office 365 apps will function.
  • Android, most users would benefit from using the Outlook app however many users still using IMAP or activesync clients will have to migrate.
  • Legacy clients, there are no plans to continue support for legacy protocols, apps that do not support OAuth2 will need to move to modern platforms or use Azure AD App API access for example.
  • It is also important to note that app passwords use basic auth and will no longer work.

In summary…

Organizations should have already taken provisions for the upcoming changes, however, there is a selection of tools to help identify and plan how workloads connect to Exchange Online. Many users or developers may feel averse to being forced into using services like Multi-Factor Authentication to comply with modern standards, but from this, we should see a rise in the bottom level of security that these services offer.

Leave a Reply

Your email address will not be published. Required fields are marked *