Microsoft is removing basic authentication on 13th October 2020 from Exchange online.
How does it affect your Exchange setup?
Once retired all the client devices using basic authentication will not be able to authenticate and will stop getting data from the servers.
It affects Exchange ActiveSync (EAS), IMAP, POP, and Remote PowerShell and few other protocols. It does not affect the SMTP based access for now.
This will be replaced by Modern authentication which is supported by the following clients
- Outlook 2013 or later (Outlook 2013 requires a registry key change)
- Outlook 2016 for Mac or later
- Outlook for iOS and Android
- Mail for iOS 11.3.1 or later
Basic authentication is also known as proxy authentication because the email client transmits the username and password to Exchange Online, and Exchange Online forwards or proxies the credentials to an authoritative identity provider (IdP) on behalf of the email client or app.
What should you do?
You must ensure that you stop using basic and legacy authentication before the retirement date to avoid service disruption for your users. You can do this by proactively disabling the basic and legacy authentication from Exchange Online and ensure that all your clients are using the modern authentication.
1. Update the emails clients to below or higher versions
- Outlook 2013 or later (Outlook 2013 requires a registry key change)
- Outlook 2016 for Mac or later
- Outlook for iOS and Android
- Mail for iOS 11.3.1 or later
2.Create appropriate authentication policies
3.Apply the policies to end users
4.Check you have successfully disabled the old authentication mechanisms
How can you do it?
Basic authentication in Exchange Online can be blocked by creating users. The policies define the client protocols authentication policies and assigning them to end users. A policy for a specific user and specific protocol can be set to disable the basic authentication for the given user and protocol.
When it’s blocked, Basic authentication in Exchange Online is blocked at the first pre-authentication before the request reaches Azure Active Directory or the on-premises IdP. The benefit of this approach is brute force or password spray attacks won’t reach the IdP (which might trigger account lock-outs due to incorrect login attempts).
The policies are effective for only those users which are actually stored in Exchange. For federated authentication, if a user doesn’t exist in Exchange Online, the username and password are forwarded to the on-premises IdP/other cloud IDPs like OKTA. For example, consider the following scenario:
Your organization used OKTA for user authentication and SSO to O365
The user abc@yourdomain.com exists in the OKTA, but not in Office 365 (there’s no user account in Azure Active Directory and no recipient object in the Exchange Online global address list).
An email client sends a login request to Exchange Online with the username abc@yourdomain.com. An authentication policy can’t be applied to the user, and the authentication request for abc@yourdomain.com is sent to the on-premises AD FS.
Authentication is done as per OKTA policies and a SAML token is issued to the user for SSO into O365
In this scenario, if yourdomain.com uses OKTA server for authentication, the OKTA service will still receive authentication requests for non-existent usernames from Exchange Online during a password spray attack.
For more details on how to disable the legacy authentication contact us on contact@trevonix.com
