MFA

Blocking ActiveSync with Conditional Access

Microsoft has announced that they’re continuing the path away from Legacy Authentication, with the decommission of legacy auth to EWS on Exchange Online on October 13th 2020. Instead of waiting for that looming date, there’s a bunch of security reasons to only have Modern Authentication for Microsoft 365.

I’ve already written up on Protect Your Office 365 Accounts By Disabling Basic Authentication and Blocking Legacy Authentication – Conditional Access vs Authentication Policies – but when I migrated from Authentication Policies to Conditional Access, I didn’t realise ActiveSync wasn’t included as part of blocking Legacy Authentication, even though it connects without MFA.

The guide from Microsoft on how to block Legacy Authentication doesn’t actually mention ActiveSync, so it’s easy to miss like I initially did! You’ll need to block ActiveSync altogether as far as I know, as it doesn’t support MFA.

Although I still think Conditional Access is easier to manage than Authentication Policies, there is one caveat; even with an ActiveSync block in place via Conditional Access, too many attempts by a user will lock their account briefly. This might cause problems or require work to get those users to clean up whatever device is trying to log in. With an Authentication Policy I don’t believe this happens because it’s blocked earlier in the sign-in process – you won’t see logs, and the account can’t get locked.

There is of course, a checkbox around ActiveSync, and a way to block it using Conditional Access, but I had mixed results in blocking it successfully until I did it exactly this way:

Create a new Conditional Access Policy and set these options:

Users and groups > All Users
Cloud apps or actions > Select Apps > Office 365 Exchange Online
Conditions > Client apps > Tick both ‘Mobile apps and desktop clients’ + ‘Exchange ActiveSync Clients’
Grant > Block Access

In the Users and Groups section, you can narrow this down from ‘All Users’ for testing or for a gradual rollout.

The user experience is interesting on this one – they can still sort of authenticate, but instead of getting their emails, they will see a single email advising that their access has been blocked:

On top of this, you can use Azure AD to audit who might be using ActiveSync before you put any sort of block in place. As per usual, there’s a good Microsoft article on Discovering and blocking legacy authentication which can walk you through this, but in short:

Via the Azure Portal, go to Azure Active Directory > Users. Under Activity, go to Sign-ins. Click Add filters, and choose Client App > Tick the three ‘Exchange ActiveSync’ options and press ‘Apply’. You’ll see the last 7 days of sign in attempts using ActiveSync, which should give you an idea of how many users are using it, and who.

Blocking Legacy Authentication, plus blocking ActiveSync will give you a much more secure environment, protecting from account attacks.

Blocking Legacy Authentication – Conditional Access vs Authentication Policies

I’ve already written a post on why Legacy Authentication (Basic) is bad, and Modern Authentication is good. At the time of writing, Authentication Policies were the way to go to block Legacy Authentication methods. Of course, things change and there’s now a better* option to look at – Conditional Access.

I’ve also covered Conditional Access before, and it’s really hard to fault the solution. There are now Baseline policies deployed by default (still in preview though) to Azure AD tenants with recommended best practices:

Conditional Access Baseline Policies

One of these is for blocking legacy authentication – but I’m not going to recommend you turn this on (at least for starters, it’s good at the end when you know you have full modern authentication support), as it’s a tenant wide setting that has no exceptions if you need to allow legacy authentication for an account (unlike Require MFA for admins, which does allow exceptions).

Instead, you can create your own policy that does the same. This means you can gradually roll it out, and put exceptions in place until you either work around them, or live with them. If you have a requirement for an account that requires legacy auth, then you need to consider how else you’ll protect that account – can you use other Conditional Access policies to restrict it to a certain region/locations, certain apps, platforms etc – lock it down as much as you can, and make sure the account has a long unique password.

The single important setting to block legacy auth via a Conditional Access Policy is blocking access to ‘Other clients’ via Client apps:

Microsoft have a full guide on how to set this up on docs.microsoft.com.

So, why is this better than using Authentication Policies? Two main reasons:

If an account has their access or signin blocked due to an Authentication Policy, it’s not logged. You can look at the user in Azure AD and check the sign-ins, but you won’t see anything. However, if it blocked via Conditional Access, you’ll have a nice log entry showing you it was blocked:

Side note: Although in this example I was logging in from Australia, I was trying to connect to Exchange Online via PowerShell. That seems to often be detected as being in the US, so be careful with region blocking.

The other reason is that Authentication Policies can take up to 4 (!) hours to apply, although it’s often more like an hour. That is a long time to wait, and you just have to keep waiting and trying until it works – except if you did it wrong, you won’t know and you’ll keep waiting. Or, if you need to unblock access while rolling out, it’s a long time to roll back.

Authentication Policies do have their place though, they give more granular control over what you want to block or not – say you know you want to block POP3 access company wide, but not IMAP – that’s possible in there, but not via Conditional Access.

Unless you have a good reason to use Authentication Policies, just use Conditional Access (and assuming you have Azure AD Premium P1 or P2 licensing to actually let you use Conditional Access, and if you are using Azure AD you should be on that licensing anyway). It’ll make your life easier!

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!