Basic Authentication. The bane of my existence for quite some time now…

Many of my clients have, or are, rolling out MFA to help combat the use of stolen/scraped credentials from being used effectively within O365 (and AAD integrated services), as it’s one of the easiest ways to combat the usage of stolen accounts, especially when combined with device-based conditional access.

Now enabling MFA is pretty easy, Enable Modern Authentication in your tenant, make sure you have a compatible client (browser, Office 2016 or Office 2013 with Modern Authentication enabled), and off you go. What isn’t discussed enough, is that by simply enabling Modern Authentication, you are NOT enforcing or disabling basic authentication! So let’s get this straight…I can still steal/scrape/phish/socially engineer passwords from users, use a legacy client (or force basic auth), and get in without absolutely any challenge! I have proved this out in many scenarios.

First we need to talk about how to get there. Simply disabling basic authentication isn’t something you want to just go out there and do in production today. For instance, it can affect the following:

  • Office 2010 and previous clients
  • Office 2013 without the EnableADAL registry key pushed
  • Office for Mac prior to 2016 version
  • Android native e-mail clients
  • iOS native e-mail clients prior to iOS 11

Usually I would pull a report from the O365 Admin portal to understand how big of an issue this really is:

Now getting to the nirvana of blocking basic authentication may be a journey for you. Get rid of those pesky Office 2010 clients and upgrade them to 2013 or 2016 (sometimes easier said than done), push out a registry key for Office 2013, consider pushing out a standard modern authentication capable mobile e-mail client such as Outlook Mobile and certainly communicate to your home users that they’ll need to upgrade. Then and only then, can you rid yourself of basic auth*!

*Just an example of some of the most common uses of basic authentication

So what are our options? Well prior to last week, there was really only one, which was using your STS provider, such as ADFS to implement a block rule on basic authentication. What this also meant, is that for those customers looking to rid themselves of ADFS, they were still really bound to it, because this wasn’t possible for a customer using PHS or PTA.

Well after much complaining, crying and asking politely, Microsoft has finally released a method in which to do this within Conditional Access. Now, CA was really only used prior for enforcing policies on modern authentication requests, but that has changed as of this week. Let’s see how to set it up.

Now our standard CA policy looks a little something like this. Targeted at our users, all cloud apps, no conditions, and you’re Granted if you are on a compliant devices, hybrid registered device (best experience) or if neither, you get traditional MFA (phone, text, app). This is great because ALL apps that are O365, AAD integrated or published through Azure AD App Proxy are protected. But with this configuration, guess what’s missing? Basic Auth!

Now we see a new option, but to enforce it, we’ll need to model a new policy that explicitly blocks it (Do not add to your existing policy). So we go ahead and choose all users, all cloud apps and ONLY “Other Clients”. This hasn’t been documented well yet, so just note the below protocols.

NOTE: Big shout out to Oliver Kieselbach for the guidance on this one via Twitter DMs!


After we implement, we give it some time to seed a bit.

Then we go test with my Office 2016 client that has EnableADAL=0 (Disabling modern auth). Let’s first verify it is using basic authentication by confirming to doesn’t show “Bearer” under authentication, but Clear* or Error if you haven’t authenticated recently.



After further testing, we found that by disabling basic auth, it was impacting the EWS call that Skype for Business uses to get calendar information. You can mitigate this by deploying the following registry key or configuring the S4B settings documented here:

Kudos to Kevin Walter for tracking this down and testing!

And look at that! Constant auth prompts with no success! All without ADFS!

This is a fine day and hope this helps support many of my customers and community in moving from ADFS to PHS/PTA (where applicable). And we are so happy that this is finally in Preview since many of us have been identifying this as a key gap for some time.

Have a great holiday weekend!


Leave a Reply

Your email address will not be published. Required fields are marked *