Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36 5/5 (2)

17 min read
The Autodiscover flow in an Office 365 based environment can be considered as a fascinating process because the way that Autodiscover client locates their Autodiscover Endpoint, includes many twists and turns.

Article Series Table of content | Click to expand

Exchange and Autodiscover infrastructure | Article Series

Exchange Autodiscover – Article series – INDEX

Exchange and Autodiscover infrastructure | The building blocks

Autodiscover infrastructure | FQDN and URL address

Exchange Autodiscover flow in different environments

Autodiscover infrastructure | Exchange infrastructure and namespace convention

Exchange, Autodiscover and security infrastructure

Autodiscover Troubleshooting tools

Autodiscover major flow scenarios

Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment

Autodiscover flow in an Office 365 based environment

Autodiscover flow in an Exchange Hybrid environment

Exchange Stage migration and Autodiscover infrastructure

Autodiscover flow in an Office 365 environment | The article series

The current article is the first article on a series of three articles that is dedicated to describing in details the Autodiscover flow in an environment which we can describe as “cloud only”.
The additional articles in the series are:

The first article is dedicated to presenting the logic and the involved components in the Autodiscover flow that is implemented in an Office 365 based environment.

In the next two articles, we will review the Autodiscover flow that implemented in an Office 365 based environment by using the Microsoft web-based tool, the Microsoft Remote Connectivity Analyzer (ExRCA).

Note – you can read more information about how to use the Microsoft Remote Connectivity Analyzer (ExRCA) tool in the article – Microsoft Remote Connectivity Analyzer (ExRCA) | Autodiscover troubleshooting tools | Part 2#4 | Part 22#36

The special characters of the Autodiscover flow in an Office 365 based environment

The Autodiscover flow that that implemented in an Office 365 based environment is very different from the “standard” Autodiscover flow that implemented in Exchange on-Premise environment.

The Key features of the Autodiscover flow in Office 365 based environment are:

  • The Autodiscover flow, including in a structured manner, failure event. In simple words, the Autodiscover client will address Autodiscover Endpoint that does not exist” or cannot provide the required Autodiscover information.
  • The Autodiscover flow will be based on a couple of nodes and “Jumps” until the Autodiscover client reaches his final destination, meaning the Autodiscover Endpoint that can provide the required Autodiscover information.
  • Some of the nodes that include the Autodiscover flow will not provide the “standard Autodiscover information” but instead, provide an Autodiscover redirection message that will “route” the Autodiscover client to additional Autodiscover Endpoints.

Does this information sound big and not so clear?

If the answer is “Yes” then, welcome to the club!

The Autodiscover flow in an Office 365 based environment includes many twists and turns

Exchange Online and “cloud only environment”

In Exchange Online environment, the Autodiscover process is implemented in a different way versus the “standard” Autodiscover process that in implementing in Exchange on-Premises environment.

In Exchange on-Premises environment, Autodiscover client will look for an Autodiscover Endpoint that represents a particular domain.

For example, in a scenario in which a user who is E-mail address is – Bob@o365info.com tries to create a new Outlook mail profile; the Autodiscover process implemented in the following way-

Autodiscover Endpoint will query DNS looking for a host named – o365info.com. In case the Autodiscover client didn’t manage to connect the specified host name, the Autodiscover Endpoint will move on to step 2, in which the Autodiscover client tries to locate a potential Autodiscover Endpoint using the host name –
autodiscover.o365info.com

The underlying assumption is that in an Exchange on-Premises based environment, the organization allocates a Public facing Exchange CAS server who will serve as a representative for the domain name – o365info.com and, the FQDN –autodiscover.o365info.com mapped to this Public facing Exchange server.

When the Autodiscover client manage to locate the Autodiscover Endpoint, the Autodiscover client will request from the Autodiscover Endpoint to “proof his identity” by providing a Public server certificate.

The Autodiscover Endpoint will provide the required certificate, and the Autodiscover client will verify that the server certificate includes the domain name – o365info.com (in a scenario of a wildcard certificate) or the host name – autodiscover.o365info.com.

In the Exchange Online environment, the described scenario cannot be implemented because a very simple reason:

In reality, the “cloud infrastructure” (Office 365 and Exchange Online) is not able to allocate a dedicated public certificate for each of the Office 365 tenants and, for each of the public domain that the registered at Office 365.

In Exchange Online, a particular Exchange server (or array of Exchange Online server) can represent a hundred or a thousand different domain at the same time.

The concept in which the Autodiscover Endpoint (the Exchange server) provides a public certificate that includes a reference to the particular client domain cannot implement!

So, the big question is – how do we solve the problem that will enable Autodiscover clients to access their Exchange Online mailbox?

And the answer is – “redirection”.

Providing a redirection to the AutoDiscover clients

DNS redirection method using a CNAME record

Office 365 and Exchange Online environment has a different character from the Exchange on-Premises environment.
For this reason, it’s important that we will be familiar with the core logic of the Office 365 infrastructure.

Office 365 (that use Exchange Online as mail infrastructure) is a SaaS (Software as a Service).
Each of the Office 365 subscribers described as a “tenant”; that hires a private space at the Office 365 “Big Building”.

Office 365 tenants

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.

For example, in case that we need to create a new Outlook mail profile to a recipient with the E-mail address – Bob@o365info.com, the Autodiscover client (Outlook), will always start the Autodiscover process by looking for a host named – o365info.com
and, if he cannot find or communicate with this host he will try to look for Autodiscover Endpoint named – autodiscover.o365info.com

The real answer that in the Office 365 environment, there is no “real server” named – autodiscover.o365info.com that has a public certificate that include reference to the domain name – o365info.com

In theory, the Autodiscover process should fail.

The answer to this problem is – impersonation.

Office 365 server impersonate

The solution is – to let the Autodiscover client “think” that he is communicating with a particular host while in practice, he communicates with another element that “present” himself as the element that the Autodiscover client thinks he is.

Sound like a conspiracy?
Yes, a little

In a “cloud only environment” (mail infrastructure that fully hosted on the cloud) Office 365 subscriber need to update their public DNS by adding a new CNAME record.

Note – there are a couple if DNS records that Office 365 subscribers need to add and update in their public DNS server in the current article, we only review the DNS records that relate to the Autodiscover services.

The DNS records that make the “magic” is a simple CNAME record that created for redetecting Autodiscover client requests to an Office 365 “element” that will impersonate himself to the “real host” that they are looking for.

The magic of the Autodiscover CNAME record

Autodiscover and the DNS CNAME record (DNS redirection)

The “trick” of the CNAME record is implemented as follows:

In the public DNS server who host the organization public domain name, we create a new CNAME record that redirects requests for the hostname – Autodiscover to a different or another hostname.

The host name to which Autodiscover requests will be redirected as – autodiscover.o365info.com

Note – a DNS CNAME record is a record that has “two parts: the “right part” will include the host name whom the DNS clients are looking for and the “left part” of the CNAME record will include the host name whom the DNS will provide his IP address.

DNS CNAME Record that translate the host name-01

For example, in the public DNS server who host the domain name – o365info.com , we will add a new CNAME record that will cause the DNS server to provide the IP address of the host autodiscover.outlook.com to each DNS client that will ask for the IP address of autodiscover.outlook.com

For example, when an Autodiscover client tries to communicate with a host named – autodiscover.o365info.com, the IP address that will be returned to the Autodiscover client from the DNS will “lead” the Autodiscover client to the Office 365 hosts named – autodiscover.outlook.com.

autodiscover.outlook.com appear as autodiscover.o365info.com-03

Who is autodiscover.outlook.com?

The autodiscover.outlook.com is an “Office 365 element” that serve as a “logical router” between the Autodiscover clients and the Exchange Online infrastructure.

autodiscover.outlook.com as a Logical Router-02

The Autodiscover flow of Office 365 users (users whom their mailbox hosted at Exchange Online) starts by communicating with the Office 365 hosts named –
autodiscover.outlook.com

The “autodiscover.outlook.com component”, will accept the Autodiscover client’s requests, but, instead of proving the required Autodiscover information, the host autodiscover.outlook.com, send as a reply, a “redirection message” to “lead” the Autodiscover client to -other Offices 365 Autodiscover Endpoints.

autodiscover.o365info.com a single host or logical components. Theoretically, the Office 365 objects that redirect Autodiscover Endpoint to their required Exchange Online server is a single host named autodiscover.o365info.com.

In reality, the autodiscover.outlook.com is just a logical object that represented by Dozens or even hundreds server which scattered around the world.

When an Autodiscover client tries to get the IP address of the hostname – autodiscover.outlook.com, the answer (the IP address + hostname) that the Autodiscover client will get, depend on his Geographic location.

For example, an Autodiscover client that physically located in Europe will get accurate information that is different from Autodiscover client that physically located in the USA.

We can see a demonstration of this process, by using a simple ping command.
In the following screenshot, we can see the result of a ping command to the host named – autodiscover.o365info.com

The “answer” that we get from the DNS server point us to a different host named-
autodiscover-emeaeast.outlook.com

Resolve the host name of - autodiscover.outlook.com -01

In case that you are wondering why do we see the host name-
autodiscover-emeaeast.outlook.com instead of the host name that we talk about – autodiscover.outlook.com, the answer that it’s probably because the Office 365 DNS infrastructure is based on a “GeoDNS”.

When using the option of GeoDNS, the DNS server recognizes the IP address of the DNS client and concludes what is the geographic location of the DNS client.

Based on this information, the DNS servers to provide an answer (IP address and hostname) that is suitable for the DNS client geographic location.
In our example, my physical location considered as “EMEA” (Europe, Middle East, and Africa) and for this reason, the Office 365 Autodiscover component that used is – a host who physically located in EMEA.

Resolve the host name of - autodiscover.outlook.com -02

HTTP and HTTPS redirection method

An additional redirection method that is implemented in the Office 365 environment for Autodiscover services is the – HTTP redirection and, HTTPS redirection methods.

In the former section, we mention that the Autodiscover client that queries the DNS server for the potential Autodiscover Endpoint, will be “redirected” to another hostname
(autodiscover.outlook.com).

The Autodiscover client “think” that this is the “element” that could provide him the required information, but this “assumption” is wrong.

When the Autodiscover client tries to connect to the Autodiscover Endpoint named – autodiscover.outlook.com, the final result, will be an additional redirection, which is implemented by the HTTP protocol to additional Autodiscover Endpoint.

If you believe that this is the “end of the story,” you will be disappointed!
(Or if to be more accurate, the Autodiscover client will be disappointed).

After the phase of the HTTP redirection, when the Autodiscover client tries to address the “new host” (the potential Autodiscover Endpoint), the result is additional redirection but this time, the redirection method is based on the HTTPS protocol.

HTTPS versus HTTP redirection process

The Autodiscover “Journey” of the Autodiscover client in an Office 365 environment

I described the Autodiscover workflow if the Autodiscover client in Office 365 as a “Journey”, because, like fairy tales, where the Prince goes through many hardships to reach Princess, the Autodiscover client, will also need to wander through many hoops.

Note – We will not get into much detail about each of the “steps” that the Autodiscover client needs to pass because, in the next article
Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36, we review thoroughly each of these steps.

In the following diagram, we can see a “high-level view” of the “elements” that Autodiscover client will meet on his way.

I have to position the DNS server at the top of the diagram because, each time that the Autodiscover client redirected to the “next hop”, the Autodiscover client will need to create a DNS query asking for the IP address of the hostname who appear in the redirection message.

The AutoDiscover Journey in cloud only environment

Additional review of the Autodiscover process in Office 365 environment

The process in which the Autodiscover Endpoint is “welling” to provide the Autodiscover client the required information (the Autodiscover response) can be made, only if two rules are applied:

Rule 1 – Mutual authentication
The server must prove his identity to the Autodiscover client so, the Autodiscover client can be sure that the server (Autodiscover Endpoint) is a “reliable source of information”.

The Autodiscover client must prove his identity to the Autodiscover Endpoint by providing his user credentials.

Rule 2 – Secure communication channel

The data that transferred on the communication channel between the Autodiscover Endpoint and, the Autodiscover client must be encrypted.

We need to know about this “mandatory rules,” to be able to understand the “strange Autodiscover flow” in the Office 365 environment.

In the following section, I answer the question of – “what is the need, for implementing such a complicated Autodiscover infrastructure in the Office 365 environment.”

The basic Autodiscover Security Rules

Phase 1

As mention before, in our scenario, the Autodiscover client looks for a host named – autodiscover.o365info.com

The answer of the DNS will provide the Autodiscover client the IP address of the host autodiscover.outlook.com

The Autodiscover client will try to communicate (using HTTPS) with this host.

The host – autodiscover.outlook.com, cannot communicate using HTTPS because he is not the “real” Autodiscover Endpoint and, he doesn’t have a server certificate that includes the host name – autodiscover.o365info.com

Because the HTTPS communication test fails, the Autodiscover client will create a new HTTP request asking for a “redirection” to the required Autodiscover Endpoint, which can provide the necessary Autodiscover services using the HTTPS protocol.

The “HTTP Redirection answer” of autodiscover.outlook.com
includes the name of the Autodiscover Endpoint named – autodiscover-s.outlook.com

Note – I think that the “S” in the name of the “new Autodiscover Endpoint” stand for: security

Autodiscover in Office 365 environment - Phase 1 of 3

Phase 2

The Autodiscover client tries to communicate the “new Autodiscover Endpoint” (autodiscover-s.outlook.com) using HTTPS protocol.

The good news is that the host autodiscover.outlook.com can communicate using HTTPS, but the less good news is, that the autodiscover.outlook.com public certificate includes an “authorization” only for host’s names who belong to the “outlook.com” domain.

The Autodiscover client is expecting to find in the server certificate the hostname – autodiscover.o365info.com and this expectation cannot fulfil because, in the Office 365 environment, there is no mechanism that provides a dedicated public certificate for each of the Office 365 tenant public domain name.

So now we have a “problem”.

The Autodiscover client cannot complete the process because he cannot find the hostname autodiscover.o365info.com in the server certificate and technically the Autodiscover process should fail.

And the good news is that the Autodiscover method has a “trick” named –HTTPS redirection.

The Autodiscover Endpoint – autodiscover.outlook.com cannot meet the conditions of the Autodiscover client, but because the
autodiscover.outlook.com can prove his identity by providing the client his certificate, the Autodiscover client can “trust” the host
autodiscover.outlook.com and relate to him as a reliable source of information.

The information that the autodiscover.outlook.com provide to the Autodiscover client is not the Autodiscover information (the Autodiscover configuration settings) but instead, the information includes a redirection to additional Autodiscover Endpoint.

The “additional Autodiscover Endpoint” is the Exchange Online CAS server that will be able to provide the Autodiscover client the required Autodiscover information.

In our specific scenario, the information that is provided by autodiscover.outlook.com (the XML redirection message) includes the name of the following host – pod5149.outlook.com

Autodiscover in Office 365 environment - Phase 2 of 3

Note – the name of the Exchange Online CAS server in our scenario is – pod51049.outlook.com
Technically, the name can and will be changed based on many factors such as the office 365 data centers in which the Office 365 tenant is hosted, the available Exchange Online CAS servers and so on.

Phase 3

Autodiscover client is willing to accept the redirection information and try to communicate with the Autodiscover Endpoint – pod51049.outlook.com

The good news is that now the Autodiscover process can be completed.

The public certificate that the pod51049.outlook.com provides, is a wild-card certificate that includes an “authorization” for all the host names “under” the outlook.com domain name.

The Autodiscover client will get the pod51049.outlook.com certificate, validate that the certificate was provided from a trusted CA, verify the host name or the domain name (in our scenario outlook.com) appears in the public certificate.

This is a “sign” for the Autodiscover client that now, he can safely provide his identity to the “server” by providing the Office 365 user credentials.

After the completion of the mutual authentication process, a secure communication link is created, and the “server” (pod5149.outlook.com) provide to the Autodiscover client the desired autodiscover.xml file.

Autodiscover in Office 365 environment - Phase 3 of 3

Now it’s Your Turn!
It is important for us to know your opinion on this article

Summary
Article Name
Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36
Description
The Autodiscover flow in an Office 365 based environment can be considered as a fascinating process because the way that Autodiscover client locates their Autodiscover Endpoint, includes many twists and turns.
Author
Publisher Name
o365info.com
Publisher Logo
Print Friendly

Related Post

Please rate this

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

One Response to “Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36”

  1. If not the grammar the article would be great, but unfortunately, poor English makes it very hard to understand.

Leave a Reply

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