Office 365 Outlook – Autodiscover Using Reverse Proxy

autodiscoverymicrosoft-office-365outlook

Background. Outlook Autodiscover has a certain order of trying to figure out configuration, and it's somewhat unchangeable, at least for Office 365 users with BYOD devices:

  1. Domain apex https://example.com:443/Autodiscover/Autodiscover.xml. As this is typically a public web site hosted elsewhere, this seems like an unnecessary step for most.

  2. https://autodiscover.example.com:443/Autodiscover/Autodiscover.xml is a way more reasonable alternative. Unfortunately, as of Sep 2019, Microsoft has screwed this up: for Office 365 users this is instructed to be a CNAME autodiscover.outlook.com., but…

    $ curl -vvv https://autodiscover.outlook.com:443/Autodiscover/Autodiscover.xml
*   Trying 40.101.49.88...
* TCP_NODELAY set
* connect to 40.101.49.88 port 443 failed: Connection refused
*   Trying 40.101.65.216...
* TCP_NODELAY set
* connect to 40.101.65.216 port 443 failed: Connection refused
*   Trying 40.101.126.120...
* TCP_NODELAY set
* connect to 40.101.126.120 port 443 failed: Connection refused
*   Trying 40.101.126.216...
* TCP_NODELAY set
* connect to 40.101.126.216 port 443 failed: Connection refused
*   Trying 2603:1026:207:15::8...
* TCP_NODELAY set
* connect to 2603:1026:207:15::8 port 443 failed: Connection refused
*   Trying 2603:1026:207:109::8...
. . .

  3. Fallback to HTTP redirect method, the only method working.

    This time http://autodiscover.example.com:80/Autodiscover/Autodiscover.xml, configured as a CNAME autodiscover.outlook.com., answers with a redirect to a working site.

    Location: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml

    This one is serving correctly in most cases, although lines seems to be long for new Application Passwords to make it this far. This, how ever, takes a lot of request and additional time. (Also, this makes it harder to debug why certain versions of Outlook can't currently connect to Office 365 at all, but must be ugraded before even trying…)

Possible solution to make this faster is to add a reverse proxy at the domain apex, pointing to the working Office 365 Autodiscover site. E.g. with Apache this is as easy as enabling the module with a2enmod proxy_http and adding a simple configuration to the VirtualHost:

# Office 365 Autodiscover Hack 20190918
SSLProxyEngine on
ProxyPass "/Autodiscover/"  "https://autodiscover-s.outlook.com/Autodiscover/"
ProxyPassReverse "/Autodiscover/"  "https://autodiscover-s.outlook.com/Autodiscover/"

According to the Microsoft Remote Connectivity Analyzer test for Outlook Autodiscover this seems to work perfectly fine, and it also seems to make Outlook Autodiscovery seemingly faster on actual Outlook installations.

As this is a hack rather than an actual solution documented anywhere, my question: is there any possible consequences from this approach you could think of?

Is the autodiscover-s.outlook.com for example a static hostname for the service, or does it ever give other redirects? Wouldn't Outlook just continue with steps 2 & 3 in any case this proxy gives unexpected results?

Best Answer

Office 365 and Exchange Online environment has a different character from the Exchange on-Premises environment. In Exchange on-Premises environment, the organization uses a dedicated Public facing Exchange server, which serves as a “representative” for the organization public domain name. The “cloud environment” (Office 365), cannot provide this type of “dedicated Exchange server” that will represent the particular domain name of the Office 365 tenant. Please refer to this article: https://o365info.com/autodiscover-flow-in-an-office-365-environment-part-1-of-3-part-29-of-36/

Related Topic