Moving to Modern Authentication in Azure and Exchange Online
This post walks through an iterative approach to moving your organization’s Microsoft environment to modern authentication and away from legacy (aka basic) authentication. Legacy authentication methods, like POP3 or IMAP, do not support multi-factor authentication and so leave you vulnerable to threats due to stolen credentials and from brute force attacks, such as password spraying or credential stuffing. Microsoft has plans to disable legacy authentication for Exchange online in 2021, so now is the time to make the transition before it is forced on you.
The approach I will describe here is best-suited when you are into the endgame of moving to modern authentication. You have modern authentication enabled in your Exchange Online environment and most if not all of your users have MFA enabled. Now you are looking to close the door on legacy authentication and are looking at how to do this in a safe way (i.e., without locking out large swaths of your users).
The overall idea is to not let a few users hold us back from blocking legacy authentication for everyone else. If we can identify who is relying on legacy authentication today then we can make exceptions for them, block legacy authentication for everyone else, and then work to get the exception group down to zero.
Set up Logging of Sign-in Activity
First, a couple of prerequisites that will allow us to create conditional access policies and run queries and workbooks that will help us monitor log-in activity and check out work.
- An Azure AD Premium P1 (or P2) license to allow you to send sign-in logs to storage. Personally, I find the P2 license to be great value for reasons beyond what I will cover here. It is the type of license that only needs to be given to administrators (i.e., not everyone), so even having one or two admins with this license unlocks a lot of useful features (in particular, access policies and Privileged Access Management) without adding a lot of cost.
- A log analytics workspace (instructions). I recommend you increase the log retention from the default 30 days to 180 days or more.
To set up log storage for sign-in activity, go to your AAD directory, choose Diagnostic settings, then Add diagnostic setting.
Select Signinlogs at a minimum (I recommend selecting all the log options) and choose your subscription and log analytics workspace.
You should wait a couple of weeks to let the workspace fill with log data that we will use in the following steps.
Find Who is using Legacy Authentication
We want to first get a sense of who is relying on legacy authentication and for what purposes.
A good place to start is the Sign-ins using Legacy Authentication workbook, found in Workbooks in your AAD directory.
Choose a period of 30 days and click on Success:
The bottom-left (1) shows the application and the legacy authentication methods being used by each application. Click each application and review the Legacy Auth Sign-in Details (2), taking the names you see there and adding them to a list of exception users.
It is important to understand what is meant by application and protocol because some of the terminology in other areas of the Azure portal can lead to confusion.
For example, in the previous screenshot you see the label Legacy Sign-ins by App and Protocol. Now, if you are listing and filtering your sign-ins in your AAD you can add a filter for Client app, which is equivalent to the “Protocol” in the previous view.
If you filter on Client app you will see “Exchange ActivSync” and “Other clients”, which we saw in our workbook, among other choices (e.g. POP3, IMAP). I find it more intuitive to consider this the authentication protocol, which can be used by various applications. A small but important point.
Set up Conditional Access Policies
In this step we will set up a conditional access policy that will block applications that rely on legacy authentication for all users except the ones we identified in the previous step (the ones with successful legacy authentication login records).
Navigate to your AAD directory -> Security -> Conditional Access Policies and choose New policy.
Include all users:
Exclude the users you noted in our previous steps – the users that have been successfully logging in with legacy authentication protocols.
In Cloud apps or actions select All cloud apps:
In the Conditions section, choose the Exchange ActiveSync clients and Other clients check boxes.
And finally, set the policy to Report-only so that we can monitor its effects before we make it active.
Monitor the Policy
Watch the effects of the policy, perhaps for at least a week, to see what it would block if enabled. Your log analytics workspace will have accumulated sign-in data over these weeks and now you can view that data using an AAD workbook.
Navigate to your AAD directory, then Workbooks, and then select the Conditional Access Insights and Reporting workbook.
Filter on the policy you created and choose a time frame of at least a week:
In the bottom-right panel labelled Sign-in events – Total, search for results with a status of reportOnlyFailure:
These are events where the users would have been blocked from signing in, and we want to see no entries with this result for our exception users. We don’t want to block legacy authentication-using applications for those exception users until we are confident they no longer need it.
Enable the Policy
Once you are at a point with zero reportOnlyFailed results in the previous weeks you can now flip the conditional access policy from Report-only to On:
Blocking Legacy Authentication for Exchange Online
At this point, notwithstanding our exception users, we have blocked applications that rely solely on legacy authentication. What may not be blocked is the use of legacy authentication by modern applications.
We will focus on Exchange Online but you may need to perform steps specific to the other modern application you see in your report. Skype for Business is a common one and the steps for it will depend on your topology (as discussed here).
As an example, in our earlier workbook we saw this:
Office 365 Exchange Online is a modern application and capable of using both modern and legacy authentication. We can see there is still some legacy authentication being used.
First, ensure that modern authentication is enabled for Exchange Online in your tenant:
Connect-ExchangeOnline -UserPrincipalName <UPN> -ShowProgress $true
Get-OrganizationConfig | fl Name,OAuth*You should see OAuth2ClientProfileEnabled : True. If not, refer to Microsoft’s documentation on how to enable it.
Next, we will create two authentication policies:
New-AuthenticationPolicy "Enable all BasicAuth" -AllowBasicAuthActiveSync -AllowBasicAuthAutodiscover -AllowBasicAuthImap -AllowBasicAuthMapi -AllowBasicAuthOfflineAddressBook -AllowBasicAuthOutlookService -AllowBasicAuthPop -AllowBasicAuthReportingWebServices -AllowBasicAuthRpc -AllowBasicAuthSmtp -AllowBasicAuthWebServices -AllowBasicAuthPowershell
New-AuthenticationPolicy "Disable all BasicAuth"You could be finer-grained with exactly which forms of basic authentication you allow for each user, but if you are dealing with more than a few users I think it is better to keep it simple and user-focused rather than getting into allowing methods ABC for user 1, BCD for user 2, etc.
Now apply the Enable all BasicAuth policy to each of your exception users:
Set-User -Identity <UPN1> -AuthenticationPolicy "Enable all BasicAuth"
Set-User -Identity <UPN2> -AuthenticationPolicy "Enable all BasicAuth"
...Now disable basic authentication for the organization, which will disable it for everyone except those in our list of exception users (assuming other users do not have an authentication policy – if they do it will take precedence over the organizational default policy):
Set-OrganizationConfig -DefaultAuthenticationPolicy "Disable all BasicAuth"Unlike with conditional access policies, there is no “report-only” mode, so these settings take effect immediately and I would advise you keep a close eye on the sign-in logs to ensure you don’t see any unexpected failures.
Grind Down the List of Exception Users
Now you are into the phase where you are in the trenches, even going user by user, to remove the last pockets of legacy authentication. These might be users that have older mail clients and need to set up their mail on a modern client, or perhaps are using unsupported applications and need to be transitioned to use a corporate standard. The reasons will vary from user to user.
As you address whatever is keeping them from using modern authentication, review your Sign-ins using Legacy Authentication workbook to check that they no longer show up. Once confirmed, remove them from the exception group in your conditional access policy, and then remove their Exchange Online authentication policy (which will let them inherit your company default) via Powershell:
Set-User -Identity <UPN> -AuthenticationPolicy $nullKeep monitoring your workbook until you get to that satisfying flat graph showing zero legacy authentication sign-ins:
Wrap-up
The process I followed here takes time and persistence but reduces the risk of disruption to your users. Removing legacy authentication is important but you don’t need to panic and turn it off in a big-bang approach. Microsoft has some nice tools to let you do this in a phased and iterative way and I hope this post gives you some guidance on how you can leverage these tools to help your organization or clients make the transition to modern authentication and away from reliance on passwords.
