A few weeks back, my colleague Brian Podolsky wrote a blog post article detailing the deprecation of legacy authentication in favor of modern authentication for Exchange Online. As you are now aware of Microsoft’s timeline, we’ll dive a little deeper into some of the technical details and how to tell if you have any clients that are connecting to Azure Active Directory via legacy protocols.
Beyond “security!”, why is Microsoft forcing this switch? To answer that question, it is best to understand a little about what we are coming from and where we are going to.
Legacy Authentication
For years, Windows (and other systems) have relied on protocols like CHAP, NTLM, and Kerberos, which don’t work particularly well over the internet. Authentication for internet resources would typically use Basic Authentication, which has the benefit of being very simple. Username and password were contained in a single header field, in plain text, base64 encoding. For this reason, Basic Auth needed to be combined with SSL to encrypt the headers (Remember the adage: NEVER authenticate to a website that is not SSL protected) and protect the user’s credentials. However, even when HTTPS is used, there are still a number of vulnerabilities for Basic Auth. First, the authentication header is sent with each request, so the opportunity to capture credentials is practically unlimited. Second, the password will be cached (and possibly permanently stored) within the browser, creating another surface for compromise. Additionally, the entire basis of basic authentication is predicated on a very simplistic and archaic username\password architecture that Microsoft is trying to eliminate.
Modern Authentication
Modern Authentication is not a single authentication method, but instead a category of several different protocols that aim to enhance the security posture of cloud-based resources. Some examples of Modern Authentication protocols are SAML, WS-Federation, and OAuth. While each are different in their execution, they all aim to move away from the classic username\password method and instead rely on token-based claims. So, while the user may still provide a username and password (for now; see more below), it is used to authenticate with an identity provider to generate a token for access. This token has more specific information (in the form of a claim) that specifies what the requestor does and does not have access to. Tokens also expire and can be revoked, so there is more ability to govern access.
An apt analogy compares access to one’s home versus a hotel room. When you unlock the front door of your house, you walk in and have access to everything; all the bedrooms, the kitchen, the bathrooms, and the underused exercise room. When you are given a keycard at a hotel, it will allow you to get in the front door, into your room, maybe the VIP lounge, and the underused exercise room. But because of the way the keycard was encoded, you cannot access the rooms of other guests, the linen closet, or the employee only areas. The hotel keycard may have other properties as well, such as time-based access to certain areas (e.g. the swimming pool is off limits after 9pm). Most important, the keycard can be permanently disabled by the hotel, after you inevitably forget to return it at checkout.
Within the cloud, these tokens help govern access to individual resources. These can include Microsoft resources, or third-party applications linked to the user’s Office 365 identity. That extensibility is perhaps the most compelling part of this architecture. If you have ever used your Facebook or Google account to access other websites or apps, you have already experienced the concept.
These tokens may also contain information about more than just your user account, including details such as the current computer or current location, thus enabling one of Microsoft’s best security tools. Conditional Access allows organization to create rules restricting access based on location or device. For example, an organization might choose not to allow access from certain countries or from personal devices.
You might be thinking, “Yeah, but I still need to enter a username and password,” but this requirement may be fading. With technologies such as Seamless Single Sign-On, Windows Hello, and password-less authentication with the Microsoft Authenticator app, the number of instances where you need to actually enter your password has been greatly reduced. Personally, I can count on one hand the number of times over the last month that I have had to type my password.
➡ Read our guide to Modern Authentication
How to Eliminate Basic Authentication
Beyond what, why, and when, the pressing question is How, as in “How do we stop using Basic Authentication?” Our goal is therefore to identify and remediate the areas where it’s still used.
First, the lowest hanging fruit; if you are using Outlook 2010 you are using Basic Authentication, as support for Modern Authentication did not appear in the Office suite until Office 2013. Easy logic dictates that if you are still on Office 2010, and are planning on moving to Exchange Online, you first need to upgrade your Office applications to a more modern version. While Outlook 2013 does support Modern Authentication, it is not enabled by default, and there are several registry keys that need to be set in order to allow the client to use it. Please note that if you are still using Office 2013, enabling Modern Authentication won’t get you off the hook regarding an upgrade. As of October 2020, Office 2013 will no longer be able to connect to Office 365 cloud resources such as Exchange Online and OneDrive for Business.
Outlook 2013 and newer clients that support Modern Authentication do not preclude the use of Basic Authentication. Modern Authentication needs to be enabled within the Exchange Online tenant. That can be checked with a simple PowerShell command. After logging into PowerShell for Exchange Online (more on this later) run the following:
Get-OrganizationConfig | FT Name, OAuth2ClientProfileEnabled
If the resultant output is “True” then congratulations, you are using Modern Authentication. If it is “False”, you’ll need to run the following command to enable it:
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
This will allow clients to use Modern Authentication and allow you to begin eliminating Basic Authentication. Keep in mind that this setting does NOT prevent Basic Authentication from being used. The next step is to verify which clients are using Basic Authentication, and to gracefully reconfigure or replace them with applications that support Modern Authentication. The best way to do that is to log into the Azure Active Directory portal and navigate to “Sign-ins”.
Click on “Add Filter” and select the “Client-app” radio button and click apply.
Click on all of the apps listed under “Legacy Authentication Clients”
This will provide a list of all clients that are accessing Azure Active Directory and Authenticating with legacy authentication protocols.
You can drill down on the login and review which users/applications are accessing the portal. While the user IDs are redacted in the example above, you may notice an interesting piece of information is that the client attempting a connection is Exchange Online PowerShell.
Not Just End-Users
Anyone who has managed Exchange Online, or really any Microsoft product since the late 2000s knows that trying to do it without PowerShell is like trying to do it with one hand tied behind your back. If you are like me, PowerShell has become the most indispensable tool in your toolkit. PowerShell, like Outlook or any other client, needs to authenticate in order to function, and the old method of connecting to Exchange Online via PowerShell used Basic Authentication. Exchange Online administrators should start using the EXO V2 PowerShell module, which uses Modern Authentication and can take advantage of additional security mechanisms such as conditional access and MFA.
Another quick way to discern the type of authentication client is via the login prompt presented. If your client is requesting credentials and looks like this:
Then you are authenticating with Basic Authentication. If it looks like this:
Then you are using Modern Authentication.
Endgame
Once you have eliminated Basic Authentication from your landscape and have verified there are no longer any clients attempting to authenticate with legacy protocols to Exchange Online, you can shut the door permanently and restrict Basic Authentication from your tenant.
Using an authentication policy, you can restrict Basic Authentication from Exchange Online either on a per-user basis or set it as the default for the entire organization. The best course is generally to do this with a pilot set of users and, assuming that there are no issues, eventually expand it to the entire tenant.
The question here is not “should you restrict Basic Authentication”, but rather “when will you restrict Basic Authentication”. The answer to the latter should be “before Microsoft disables Basic Authentication entirely in another year”.
