For the search engine, context elements:
- Exchange Online
- Office 365 / Microsoft 365 --> Particular Outlook --> outlook.office.com
- Windows' Mail & Calendar App [HxTsr.exe, "microsoft.windowscommunicationsapps"]
- Apex domain redirect to www.~
- Cloudflare DNS
- Using Cloudflare workers
- HSTS, also for subdomains
- [Azure's] Conditional Access is blocking legacy authentication methods. ('basic authentication'.)
- cname of autodiscover.domain.tld was configured towards autodiscover.outlook.com. as expected, Cloudflare's tricks disabled for this record.
- Cloudflare is providing SSL for most domains, except autodiscover.domain.tld.
Now the undesired behaviour:
In this case, the Autodiscover was not working for the 'windowscommunicationsapps', henceforth named 'problem client' or 'client'. It was working for latest Outlook for Windows most likely due to the more modern built-in autodiscovery methods that skip the legacy autodiscovery ones.
The problem client would load and load and prompt a basic authentication password, and after that, prompt for a username and domain and after that display an error with the option to go to advanced and enter everything again including the server. After that, after I remembered to enter
outlook.office365.com as server, it prompted the user with Microsoft's modern authentication window.
What was going wrong:
The client tried to retrieve
https://rootdomain.tld/autodiscover/autodiscover.xml. (Seen in cloudflare's firewall's log.)
It got redirected to
https://www.rootdomain.tld/autodiscover/autodiscover.xml. (Seen in MS's tool.)
Due to a complex configuration of Cloudflare workers, the client did not get a 404 back in first instance. It just kept loading and loading. In variation config, a dedicated Cloudflare worker returned a 404 page; it did not resolve the issue.
The problem was that there was too much going on.
- http was redirected to https.
- Root (apex) was redirected to www.domain.tld/$1 and
- autodiscover.~ supposed to resolve to autodiscover.outlook.com but for some reason did not deliver the xml. (With Microsoft's tool showed me:
Testing TCP port 443 on host autodiscover.juramento.nl to ensure it's listening and open.
The specified port is either blocked, not listening, or not producing the expected response.
- One of the next step in the Autodiscovery-quest is looking for redirects at autodiscover.domain.tld and that made it find
The assumption was that the problematic client was not getting this far and giving up on it's autodiscover-quest too soon. I am unsure if the GET request at autodiscover.domiain.tld:443 is supposed to deliver an error for Exchange Online, but the redirect worked as desired and as soon as Microsoft's tool found
https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml every thing turned green until the expected basis authentication error due to the blocking of legacy authentication methods in conditional access.
- Why can't this client connect to Exchange / Office 365 quickly?
- Why is this client asking for basic authentication?
- Why is autodiscovery not working for this domain?
- What is autodiscovery actually doing step for step?
- What can we do to shorten the autodiscovery steps and aid the original problematic client?
- What can I do to fix autodiscovery for Exchange Online quickly?