Now that they've disabled basic authentication for email connection protocols, Microsoft is doing the same for the Autodiscover service. This makes sense. There's no point in allowing basic authentication for Autodiscover when clients can't use basic authentication to connect. Microsoft will therefore turn off basic authentication for Autodiscover as it removes basic authentication for protocols like POP3, EAS, IMAP4, EWS, and MAPI.
An interesting and worthwhile interview (available on YouTube) with security researcher Amit Serper reveals a lot more detail about the Autodiscover credential leak reported by Guardicore last month. The interview (with three Office 365 MVPs) goes through the collection of leaked credentials, how Serper tried to reproduce the problem, and his interaction with Microsoft. It’s a real pity Serper didn’t include the information in his original report as it would have taken a lot of heat out of the situation.
It's often helpful when security researchers like Guardicore shed light on flaws in Microsoft Exchange - however, the Autodiscover protocol isn't flawed in the way they describe. Even though the issue is hard to replicate, it shouldn't distract from the work you need to do to protect your organization from the underlying reason why people want your credentials.
Lots of excitement was generated when Guardicore revealed a purported vulnerability with the Exchange Autodiscover service. However, the almost total lack of detail about the configuration used for testing and to generate the reported results makes it impossible for Exchange administrators to check the theory against their own deployment. I don't think a problem exists with Exchange Online, but it's possible that poor DNS practice or flawed third-party clients could cause an issue with on-premises servers. The case remains to be proved.
How to fix Exchange Server Autodiscover failures for ActiveSync mobile devices due to HTTPS issues with root domain lookups.
Outlook clients may begin displaying a security alert warning dialog after an Exchange 2013 server installed into an existing organization.
Some considerations for Autodiscover when planning an Exchange 2013 deployment in an existing Exchange 2010 organization.
Using the Test-OutlookWebServices PowerShell cmdlet to test web services in Exchange Server 2013.
A run down of some of the common concerns people have when installing the first Exchange 2010 server into their production environment.
How to publish different Exchange ActiveSync URLs for multiple geographic locations with Autodiscover in Exchange Server 2010.
How to configure your Exchange 2010 SSL certificate to include the correct Autodiscover names.