Page 1 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

Autodiscover flow in an Office 365

environment | Part 1#3 | Part 29#36

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.

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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 2 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

describe as cloud only.

The additional articles in the series are:

Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36

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 is 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 is implemented in an Office 365 based
environment, is very different from the standard Autodiscover flow that is
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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 3 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

Does this information sound big and not so clear?

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

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 specific 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 will be implemented in the following way-

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 4 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

Autodiscover Endpoint will query DNS looking for a host named o365info.com. In
case the Autodiscover client didnt 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 basic 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 is 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 specific 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 specific client domain cannot be
implemented!
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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 5 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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, its important that we will be familiar with the basic 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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 6 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

In Exchange on-Premises environment, the organization uses a dedicated Public

facing Exchange server, which serve 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 specific 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.
Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 7 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

The answer to this problem is impersonation.

The solution is to let the Autodiscover client think that he is communicating with
a specific host while in practice, he communicates with another element that
present himself as the element that the Autodiscover client think he is.
Sound like a conspiracy?
Yes, a little
In a cloud only environment (mail infrastructure that is 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
redetect Autodiscover client requests to an Office 365 element that will
impersonate himself to the real host that they are looking for.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 8 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 9 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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 hostautodiscover.outlook.com to each DNS client that will ask for the
IP address ofautodiscover.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.

Who is autodiscover.outlook.com?

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 10 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

The autodiscover.outlook.com is an Office 365 element that serve as a logical

router between the Autodiscover clients and the Exchange Online infrastructure.

The Autodiscover flow of Office 365 users (users whom their mailbox is 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 clients
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 is represented by
Dozens or even hundreds server which are 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 + host name) that the
Autodiscover client will get, depend on his Geographic location.
For example, an Autodiscover client that is physically located in Europe will get a
specific information that is different from Autodiscover client that is physically
located in the USA.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 11 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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 namedautodiscover-emeaeast.outlook.com

In case that you are wondering why do we see the host nameautodiscover-emeaeast.outlook.com instead of the host name that we talk about
autodiscover.outlook.com, the answer that its 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 to 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 will be
used is a host who is physically located in EMEA.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 12 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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 think 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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 13 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

additional redirection but this time, the redirection method is based on the HTTPS
protocol.

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 need also 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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 14 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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 will be 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.

Additional review of the Autodiscover process in Office

365 environment

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 15 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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 is 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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 16 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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
hostautodiscover.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 doesnt 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,
that can provide the required Autodiscover services using the HTTPS protocol.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 17 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

The HTTP Redirection answer of autodiscover.outlook.com

includes the name of the Autodiscover Endpoint named autodiscovers.outlook.com
Note I think that the S in the name of the new Autodiscover Endpoint stand for:
security

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 hosts names who belong to the outlook.com
domain.
The Autodiscover client is expecting to find in the server certificate the host name
autodiscover.o365info.com and this expectation cannot be fulfilled 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
host nameautodiscover.o365info.com in the server certificate and technically the
Autodiscover process should fail.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 18 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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

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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 19 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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 successfully
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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 20 of 20 | Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

Additional reading

Office 365 Autodiscover Lookup Process

Written by Eyal Doron | o365info.com | Copyright 2012-2015