Conditional Access

Protect Your Office 365 Accounts By Disabling Basic 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 testuser@yourdomain.com -AuthenticationPolicy “Block Basic Auth”

Set-User -Identity testuser@yourdomain.com -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 testuser@yourdomain.com -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.

Azure AD Sign-in via Google Chrome and Conditional Access

While testing MFA, Conditional Access and all the other good stuff Azure AD provides, I came across this scenario:

Conditional Access configured to require MFA if the user wasn’t on an Azure AD Hybrid PC, or coming from an internal IP.

User on an Azure AD Hybrid PC, but on an external IP.

User uses Chrome to access a Microsoft resource, and gets challenged despite being on the Azure AD Hybrid PC.

It seems that the sign-in process isn’t aware of the state of the computer when using Chrome- but there is an easy fix: deploy Windows 10 Accounts extensions for Chrome.

This is really easy to do via Group Policy.

  1. If you don’t already have them, get the ADMX Group Policy files for Google Chrome and deploy into your environment
  2. Under User Configuration > Policies > Administrative Templates > Google > Google Chrome > Extensions, configure the policy ‘Configure the list of force-installed apps and extensions’:

3. Change the radio button to enabled, click ‘Show’ and enter the value for the add-in

ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx

4. Do your normal process of configuring the Group Policy object to target the users you want, run a gpupdate and see the addin silently turn up in Chrome. The only user impact will be a visible Windows logo to the left of the Google Accounts area in the top bar of Chrome.

Peter van de Woude has documented how to do this via registry, so read his post if you want info on how to do that –  as well as how to then deploy via Intune and PowerShell script.

Worth doing if you use Azure AD connect, and highly recommended if you’re using Conditional Access. 

Conditional Access Makes MFA Migration Easier

Microsoft Azure’s Conditional Access is a really great way to get a company using Multi-Factor Authentication. The old argument of not wanting MFA to get in the way of logins constantly goes away with this solution, because it lets you set the rules and scenarios where MFA will and won’t trigger.

To be more accurate, the access controls that Conditional Access can use lets you use more than just MFA to log in (username/password/token style). You can set the rules so a trusted device negates the need for MFA.

This isn’t new anymore either. Here’s a video from Microsoft back in March 2017 talking about how all this works:

What this means is that someone with a username and password on a device that is either InTune enrolled, or set up for Azure AD Hybrid is trustworthy enough. Of course this is less secure than asking for MFA every time, but do you really need to do that when someone is using their work laptop?

Another condition to choose from is ‘Locations’. You can decide that MFA won’t kick in if the login is coming from inside your corporate network. You can also target different applications with different rules that stack – so maybe the payroll system will always ask for MFA, but a less sensitive one will only ask when not on a managed device.

Security wise, there’s also a ‘Sign-in Risk‘ option where each authentication attempt is evaluated and given a risk ranking, and access can be granted or blocked based on the results. Note that this one needs Azure AD Premium P2 which isn’t part of the Microsoft 365 E3 subscription – E5 or separate licensing is required.

Because Conditional Access works like a bunch of Outlook rules, you can slowly build up and adjust what kicks in when. It’s really easy to do, and there’s really no excuse (once you have licensing!) to stop you setting it up ready to demo to staff. 

Combine Conditional Access with Azure AD App Proxy where you can externalise any internal web based app, while forcing auth on it and you’ve got an easy way of enabling workers to do their jobs remotely, while being happy about the security around it – and NOT just poking a hole in a firewall, exposing your IIS box to the world.

Conditional Access Stuck on “Loading…”

There’s currently an issue with configuring Conditional Access via Azure Active Directory. There’s an open ticket with Microsoft Support, with no ETA at the time of writing.

The issue:  When trying to configure a new policy for Conditional Access against an Azure Active Directory application, the ‘New’ page gets stuck loading. I’ve tested this on multiple browsers, tenants, internet connections, computers, and had Microsoft support confirm.

The path to doing this is from the Azure portal – Azure Active Directory > Enterprise Applications > choose your application > Conditional Access > New policy:

The Workaround: Thankfully it’s not a showstopper, as there’s another way to get to Conditional Access and it works fine. Instead of going via a specific app first, you can just go via Azure Active Directory > Conditional Access > New policy. Also Azure Active Directory > Enterprise Applications > Conditional Access > New policy works, it’s just an extra click to the same screen.

Points to take note of – if something’s broken, try accessing the same function from a different route of click-through links and it might work another way. Also, log these issues with Microsoft Support as overall the support is pretty good and often the issue won’t be anything to do with you. Test different scenarios wherever possible too, and also asking the question on Twitter can get some extra attention!