[ad_1]
It’s been a few months since our last update on Basic Authentication in Exchange Online, but we’ve been busy getting ready for the next phase of the process: turning off Basic Authentication for tenants that don’t use it, and therefore, don’t need it enabled.
We have millions of customers who have Basic Auth enabled in their tenant, but only use Modern Auth. Many of them don’t know Basic is enabled, and the risks that it presents – so we are going to do our bit to help secure their data by turning it off for them.
Over the last few months, we have been building the supporting process and tools we need to do that at scale, and now we’re ready to start rolling it out.
As we’ve said before, we’re only currently planning to turn off Basic Auth for those customers who are not using it. For customers that use still Basic for some or all the affected protocols*, we are not touching authentication settings for those protocols (for the time being).
(*as previously announced these are: Exchange Web Services (EWS), POP, IMAP, Exchange ActiveSync (EAS), Remote PowerShell (RPS) , Outlook (EWS + MAPI, RPC, and OAB) and SMTP AUTH)
We have been busy analyzing Basic Auth usage data for our customers and now have a solid understanding of who uses it and who does not. And we’re going to start turning it off for those who are not using it.
The process is: We’ll randomly select customers with no usage in any, or all affected protocols, send them a Message Center post informing them that in 30 days we’re going to turn off Basic Auth. 30 days later, we’ll turn it off and send another Message Center post to confirm it was done. Customer protected… check!
We’ve already done this for a pilot set of tenants so we feel good about how this works, but before we scale up we wanted to build a tool to help our customers just in case we get it wrong. Why would we get it wrong? Well, very low usage is hard to detect if connections are rare, and some customers might even suddenly start using Basic auth. On that note….
You should know that we can’t really tell if Basic auth usage is legitimate usage, or an account that has already been compromised – we just see this as someone logging in to the mailbox, and in this case will not disable the protocol. Now therefore is another great moment to plug the Azure AD Sign-In log, as it can help surface ‘unexpected’ usage.
What if we do not spot that new usage , and we disable Basic? What then? Well, that’s where a new tool we’ve been building comes in – a tool that provides self-service re-enablement.
We’ve built a new diagnostic into the Microsoft 365 admin center. You may have seen this before for things like EWS migration throttling, or you read this excellent recent post about it. These diagnostics have proven really popular with customers, so we simply built on that technology.
If you want to re-enable a protocol that we have disabled for Basic Auth, or want to see what protocols we have disabled, open the Microsoft 365 admin center and click the small green ? symbol in the lower right hand corner of the screen.
Once you do that you enter the self-help system which, (in case you didn’t know) can use some very clever logic to help you find a solution to all kinds of problems. But if you want to get straight to the new Basic Auth self-help diagnostic simply enter the magic phrase “Diag: Enable Basic Auth in EXO”.
(Don’t tell anyone, this is our little secret. Published on one of the most popular blogs we’ve ever had at Microsoft. Shhh.)
Once you do that, you’ll see a page very similar to this:
Once you click Run Tests, the tool will check your tenant settings to see if we have disabled Basic Auth for any protocols, and then display the results.
If we have not disabled Basic Auth for any protocols we’ll tell you just that. But assuming we have done something, you’ll see a list of protocols that are disabled. My tenant has the full set of protocols disabled as you can see from the following:
Now that’s great, you can see what we did, but the best thing is, you can also re-enable the protocols yourself (if you want to). You can simply select the protocol (or a group of protocols, in the case of Outlook), check the box to agree to the warning (you know turning Basic Auth back on is bad right?) and then click Update Settings:
If you want to re-enable another protocol (again – why would you do that…?) re-run the diag and you can do just that.
That’s it – that’s how you can re-enable a protocol if we turn it off as part of this larger security effort. This is the only way to re-enable 8 of the 9 protocols included in the scope of this effort. (Up until the point at which we start to disable Basic Auth for protocols which are in-use – we are still planning on doing that and will have news on that later this year)
The only protocol you cannot re-enable in this way is SMTP AUTH – that’s not a part of this diagnostic because there’s already a lot of diagnostic wizardry available to help you with SMTP AUTH, and you can already switch SMTP AUTH on and off yourself by using the Set-TransportConfig cmdlet. Because unlike the other 8, all we’re doing to disable Basic Auth for SMTP AUTH is Set– SmtpClientAuthenticationDisabled to $False for tenants, and you can just go right ahead and turn it back on if you subsequently decide you need and want to use it.
One other notable difference in behavior with SMTP AUTH compared to the others is that the switch for SMTP AUTH controls Basic and OAuth client submission, they are not individually switchable. You can still enforce the use of OAuth using Conditional Access, but it’s a little more involved than just on or off for Basic, you can read more about authenticated SMTP submission here.
So how are we controlling the use of Basic Auth for the other 8 protocols? Good question, so good in fact we added that to the list of other excellent questions you might have below.
Why do I need this diagnostic tool? Why can’t I just go look at the Authentication Policies in my tenant and disable/delete them if I do not want Basic disabled for any protocol?
Good question! We are not turning off Basic using Authentication Policies. Therefore, Authentication Policies setting has no effect on the way that we will disable (and you can re-enable) Basic Auth using this diagnostic.
I use Basic Auth still for <insert your device, third party app, home grown app, etc. here> and I do not want you to turn it off!!
As long as your app checks mail or does whatever it does pretty regularly, we’ll consider that ‘active usage’ and not touch the authentication settings for the protocol it uses for the time being.
How exactly is Microsoft turning Basic Auth on or off on a per-protocol level?
We’ve added a new org level parameter that can be set to turn Basic Auth on or off for individual protocols within a tenant. Admins can view the parameter (-BasicAuthBlockedApps) using Get-OrganizationConfig. It’s not something you can change, and the values we store in there aren’t very user friendly, but luckily Exchange Online knows how to read and enforce them. A value of Null there means we’ve not touched your tenant. A value other than Null means we have, and the diagnostic is the way to determine what is disabled there.
I just got the Message Center post but I know I have an app that still needs to use Basic Auth. Please do not turn it off, I don’t want to have to re-enable it.
We are looking to add ‘opt-out of Basic Auth disablement’ functionality to this diag quite soon so you can do just that. The idea is that once you get the Message Center post you can use the diag to say “please don’t disable basic auth for IMAP” for example. And we’ll respect that. However… we strongly encourage you to request an opt-out only for the protocols you know you need, and don’t just ask for them all. Leaving unused protocols enabled for Basic Auth is a huge security risk to your tenant and your data.
When is Microsoft going to start turning off Basic Auth for protocols that we are actively using?
As announced earlier this year we’ve paused that program for now, but it will be coming back, so make sure you keep an eye on the blog and the Message Center for that announcement and keep working to eliminate the need for Basic Auth in your environment!
Source link
