(AKA Legacy Authentication)
This had been on my to-do list for a little while since I heard about it (mostly from Daniel Streefkerk who quite rightly has been drawing attention to this via Twitter, thanks!)– and it should be on yours too.
By default, Basic Authentication is allowed as an authentication method in Exchange Online. This is because that’s the ‘standard’ way things have worked for a very long time – you want to get your emails, you provide a username and password and you’re done.
In our modern world, that doesn’t work too well anymore. It’s too risky in that many ways, and things like 2FA and Conditional Access add an extra layer of security when logging in. That’s great, but many systems weren’t built or haven’t been updated to support this – they’ll just fail when logging in.
What this leaves us with, is an internet exposed authentication system that accepts username and password logins without any other layers of authentication, even if you have 2FA and conditional access turned on.
As per Microsoft’s documentation around disabling basic authentication covers, this lets attackers use brute force or spray attacks to try different credentials to get into your tenant. With the amount of leaks we see these days (register on Troy Hunt’s https://haveibeenpwned.com/ if you haven’t already), it’s likely attackers are hitting Microsoft servers with correct accounts of your staff members. If they manage to get the right password – which is very possible if people end up using an old password they used years ago, or password changes were disabled because you thought you were covered with 2FA – they now have valid credentials to get in and pretend to be that staff member, often to then send emails to all their contacts with a malicious link or some other scam.
If you want to see what’s going on for your tenant, go to the Azure portal and into Azure Active Directory > Monitoring – Sign-ins. Set the Status to ‘failure’ and apply, and see what’s there.
Here’s an example, where you can see the client app is ‘Other clients, IMAP’. This account is disabled, and if you look in the device info there’s no data.
Once you have a look here, you might start to get worried – so it’s time to see if you can disable basic auth!
Only certain email clients will work without basic auth, so your first step is to work out what people are using, and get approval to force the usage of only these:
- 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
That can be a tough ask, and you’ll need to weigh up the risk of leaving basic authentication in place (to me this is an easy choice, but can still be difficult to get approved and implement).
Again, the Microsoft documentation explains how to do this quite easily – create a new Authentication Profile which has Basic Auth disabled by default, and apply it to test users:
New-AuthenticationPolicy -Name “Block Basic Auth”
Set-User -Identity [email protected] -AuthenticationPolicy “Block Basic Auth”
Set-User -Identity [email protected] -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)
That’s all you need to do to test. The third command forces an immediate refresh on the test user.
I would recommend leaving this in place for a while, and get as many test users on as possible as you might find certain systems using basic authentication that you weren’t aware of.
If you need to drop the policy off of a user, use this command:
Set-User -Identity [email protected] -AuthenticationPolicy $null
If you’re then ready to apply this policy to all accounts company wide, these three commands will do it:
$users = Get-User -ResultSize unlimited
$usersid = $users.MicrosoftOnlineServicesID
$usersid | foreach {Set-User -Identity $_ -AuthenticationPolicy “Block Basic Auth”}
You’ll also want any new accounts to get your new policy by default, which can be done with this command:
Set-OrganizationConfig -DefaultAuthenticationPolicy “Block Basic Auth”
And with that, you’ll have all existing and future accounts protected from the risks of leaving Basic Auth enabled. Of course if you have a special requirement where a few accounts do need Basic Auth, create another policy, enable basic auth on it, and apply it to those accounts. Your attack surface will still be greatly decreased, and hopefully you’ll eventually be able to disable basic auth on those too.
Note: There’s also an option for OneDrive for Business around this same setting, more details here: https://www.adamfowlerit.com/2019/03/onedrive-for-business-rollout-considerations/
Update 26th April 2019:
There’s also now a Conditional Access option that supports ‘other clients’ –
“This includes older office clients, other mail protocols(POP, IMAP, SMTP, etc), and ACS”. This might help you if you either want to block those older clients, or allow them through in certain circumstances:
Good write-up Adam. The more word that gets out about this, the better. There’s plenty of guidance telling organisations to enable MFA, but not enough awareness of this gaping hole of a bypass.
Breaches of MFA-enabled organisations due to their continued use of legacy authentication were already making news mid-way through last year: https://www.theregister.co.uk/2018/07/13/2fa_o365_bypass_attacks/
And don’t forget to look at Conditional Access policies to block legacy auth in other cloud-connected applications while you’re at it: https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-AD-Conditional-Access-support-for-blocking-legacy-auth-is/ba-p/245417
Hi
Thanks; but you are missing a HUGE piece of the puzzle.
How about the fact that legacy clients are not IP location aware? Clients that use basic authentication are NOT IP aware so using method above simply turns off basic authentication for everybody inside and outside. So if you have users inside the network that have outlook 2010/2013 then they won’t be able to connect even if you do IP exclusions!!!
How do you block basic authentication ONLY externally as I had mentioned before; you can’t do it with Azure CA or above method?
I believe Outlook 2013 onward was supported properly with the regsitry key change mentioned in my post? It’s time to upgrade from Outlook 2010 if you want modern mechanisms, 9 year old software was not built with this in mind.
But, you could check out Conditional Access as it now has a client apps option that supports older Office installs, and allow them if you need. I’ll add a photo of the settings to the post above now.
Hi
I fully understand that conditional access now has an entry for “other clients” that covers legacy outlook 2010.
Problem is that these legacy clients including Outlook 2010 are NOT IP aware. So if you use Azure Conditional access to block them, they will also block any of those clients inside your network!!!
You know much more than I do; but I am sure about my statement above.
Thanks
I don’t have Outlook 2010 on hand to test, but since it’s not supported it doesn’t surprise me that certain Conditional Access rules don’t work. I pointed out in my post that meeting the requirements for this can be a tough ask, and also pointed out that Outlook 2010 is quite old – so spend the time working out how you’ll migrate off that. It’s still got 1 1/2 years of support left (Oct 2020).
Instead of worrying about IPs, can you just allow devices that are Azure AD Hybrid or some other check that does work with Outlook? As I don’t know what rules you’ve got in place or what goal you’re trying to achieve, I can only guess some suggestions sorry.
Thanks Adam a really interesting read and has certainly helped me get going with this as a project.
Hi Robert,
I’m about to blog in more detail about the Conditional Access side – in short, if you don’t need the extra functions in Authentication Policies, it’s better to do it that way :)
Thanks for the article. I blocked basic auth for my users long ago but there are points to consider. If certain users require IMAP access, as do our CRM users right now (until EWS auth is in place soon) then a new auth policy must allow this. Second, CA policies only kick in after the auth policy. So hackers must first breach the auth policy and then CA takes over blocking certain logins such as unusual IP, untrusted IP’s and foreign location (by IP). This would then also include the rule in Azure AD Identity Protection to block high risk sign-ins.