Autodiscover flow in an exchange hybrid environment part 2#3 part 33#36

of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 2#3 | Part
33#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Autodiscover flow in an Exchange
Hybrid environment | Part 2#3 | Part
33#36
The current article and the next article, will be dedicated for detailed review of the
Autodiscover flow, that is implemented in Exchange Hybrid environment, by using
the Microsoft web-based tool, the Microsoft Remote Connectivity Analyzer (ExRCA).
Autodiscover flow in an Exchange Hybrid environment | The
article series
The current article is the second article in a series of three articles.
The additional articles in the series are:
 Autodiscover flow in an Exchange Hybrid environment | Part 1#3 | Part
32#36
 Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36

33#36
A user in a Hybrid environment that his mailbox was migrating to the cloud, get a
new desktop, double-click on the Outlook icon, Outlook is coughing and shivering
and after a couple of seconds the user connects to his mailbox.
Sound simple, isn’t?
In reality, this “simple process” in which user create a new Outlook mail profile and
automatically connect to his “cloud mailbox”, based on a very smart and complex
Autodiscover process.
The reason for describing Exchange Hybrid Autodiscover flow as – “complicated” is,
because for Exchange recipient whom their mailbox is hosted at the Exchange
Online infrastructure, the Autodiscover flow in an Exchange hybrid environment will
be implemented twice:
The first time using the Exchange on-Premises infrastructure and the second time,
after the Exchange client gets a redirection message, the Autodiscover flow will be
implemented against the Exchange Online infrastructure.
The magic of the Autodiscover journey in Exchange
hybrid environment

33#36
In the current article and the next article (Autodiscover flow in an Exchange Hybrid
environment | Part 3#3 | Part 34#36), we will review in details, each of the many
steps that include in the Autodiscover journey in Hybrid environment.
I have tried to separate each of these steps and came with a result of 30 different
parts.
The number “30”, is just an arbitrary number because, the “Autodiscover Journey”
can be dived even to more parts or fewer parts. The number of the “parts” depend
on many variables.

33#36
So, if you have the required courage, come and join our long but interesting
journey of reviling the Autodiscover flow in an Exchange hybrid environment!
This is your last chance. After this, there is no turning back. You take the blue pill—
the story ends; you wake up in your bed and believe whatever you want to believe.
You take the red pill—you stay in Wonderland, and I show you how deep the rabbit
hole goes. Remember: all I’m offering is the truth, nothing more.
Quoted from the matrix part 1#3
Scenario description

33#36
To be able to demonstrate the Autodiscover process in Hybrid environment, we will
use the following scenario:
An organization named – o365info.com, use a Hybrid Exchange configuration, which
include a mixture of Exchange On-Premise mailboxes and cloud (Exchange Online)
mailboxes.
In our scenario, a user named Alice that uses the following E-mail address –
Alice@o365info.com, needs to create a new Outlook mail profile.
Alice’s mailbox was migrated to the cloud (Exchange Online).
The Autodiscover long journey in Hybrid environment
In the Hybrid environment, the Exchange On-Premise continues to serve as a “focal
point” for the Autodiscover services.

33#36
Despite the fact that Alice mailbox is physically stored in the Exchange Online, the
Autodiscover process will start with the Exchange On-Premise environment.
The Exchange client (Alice in our scenario) will try to connect their Exchange On-
Premise server and in case that the user mailbox is “in the cloud”, the Exchange On-
Premise is the element which will redirect the mail client to his “cloud mailbox” by
providing him his “cloud E-mail address”.
Before we get into the details, it’s important that we will be able to see the “big
picture” or the major nodes that will appear in our Autodiscover journey in the
Hybrid environment.
In the following diagram, we can see the Autodiscover client, will need to pass
through many nodes in his Autodiscover journey until he gets to his final
destination, the Autodiscover Endpoint that will provide him the required
Autodiscover information.
Using the Microsoft remote connectivity analyzer – the
prefix
To be able to illustrate each of the Autodiscover steps that are involved in the
Autodiscover flow, we will use a combination of diagrammatic and a screenshot
from the result of the Microsoft remote connectivity analyzer.

33#36
In our scenario, we will use the ExRCA test named – Microsoft office Outlook
Connectivity tests and, choose the Outlook Autodiscover test.
1. The Exchange “environment” | Exchange on-Premises
In our scenario, we examine the Autodiscover flow of a recipient whom his mailbox
is hosted at the Exchange Online infrastructure.
Theoretically, we should have chosen the ExRCA “Office 365 tab” because the
recipient mailbox is physically located at the Exchange Online infrastructure.
In the Exchange hybrid environment, the Exchange on-Premises serve as an
“Autodiscover focal point”. The Autodiscover flow should be started by addressing
the Exchange on-Premises serve and based on the ”redirection message” that will
be provided to the Autodiscover client, continue the Autodiscover flow by
addressing the Exchange Online infrastructure.
For this reason, we will choose the Exchange Server tab.

33#36
2. Login credentials
In a scenario in which we want to test an Autodiscover process, for user mailbox
hosted in Exchange Online, we will have to use the UPN (User principal name)
naming convention, although the process starts with Exchange On-Premise that
enables to use the standard Active Directory login naming convention such as
– o365infoAlice
The reason is that – in the first Autodiscover phase; the user identifies himself
before the Exchange On-Premise but, in the next steps, the Autodiscover client will
need to identify himself to the Exchange Online server who uses the Office 365 UPN
naming convention such as – Alice@o365info.com

33#36
3. The two different Exchange infrastructures
Before we dive into the specific Autodiscover steps that are implemented in an
Exchange hybrid environment, let’s start at the end, by looking at an example of
ExRCA test that was completed.
In the following screenshot, we can see that the Autodiscover test was completed
successfully.
The summary report displays information about two different Exchange
environments:
 Exchange on-Premises environment
 Exchange Online environment

33#36
Using the Microsoft remote connectivity analyzer – the
detailed description
In the following section and in the next article, we will review in details, each of the
“30 steps” that are implemented in an Autodiscover flow in an Exchange hybrid
environment.

33#36
Step 1/30: Attempting to resolve the hostname o365info.com
By default, Autodiscover client will try to locate a “potential Autodiscover Endpoint”,
by using a host name who was “extracted” from the recipient E-mail address.
Autodiscover client will use the “right part” of the recipient E-mail address that
includes the SMTP domain name.
In our scenario, the recipient E-mail address is – Alice@o365info.com
Based on this specific E-mail address; the Autodiscover client will create a DNS
query looking for an IP address of a host named – o365info.com
The “answer” of the DNS server, depend on the specific organization, public server’s
and services infrastructure.
For example, most of the organizations, have a public web site and, most of the
time the public domain name is “mapped” to the public IP of the website.
In our scenario, the DNS server reply with a public IP address of the requested host
name. The IP that was provided by the DNS server, doesn’t “belong” to an Exchange
server (Autodiscover Endpoint) but instead, this public IP address is assigned to a
standard web server.

33#36
Step 1/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information:
The DNS name resolution step, in which the Autodiscover query the DNS server for
the IP address of the host – o365info.com, complete successfully.
The DNS server reply with a list of public IP addresses.
Attempting to resolve the host name o365info.com in DNS. The host name resolved
successfully. IP addresses returned: 104.28.12.85, 104.28.13.85
Step 2/30: Testing TCP port 443 on host o365info.com
The Autodiscover client addresses the potential Autodiscover Endpoint, using the IP
address that he got in the former step.
The Autodiscover client, will try to verify if, the potential Autodiscover Endpoint can
communicate using the HTTPS protocol (port 443).

33#36
In our scenario, the HTTPS communication test succeeds. The “server” approves
that he can communicate using HTTPS.
Just a quick reminder
 Case 1 – the fact that the “destination host” support HTTPS protocol, doesn’t
necessarily mean that the host is Exchange server who can provide the required
Autodiscover services.
 Case 2 – even in case that the “destination host” support the HTTPS protocol +
the “destination host” is a valid Exchange server; it doesn’t mean that he can
provide Autodiscover information to the Autodiscover client.
information:
The Autodiscover client tries to verify if the “destination host” support, the HTTPS
protocol and the answer is “yes”.
Testing TCP port 443 on host o365info.com to ensure it’s listening and open. The
port was opened successfully.

33#36
Step 3/30: Attempting to obtain the SSL certificate from remote server
o365info.com
The Autodiscover “relationships” between the Autodiscover client and the
Autodiscover Endpoint is built on a “trust concept”.
The first phase, is the step in which the Autodiscover client will need to trust the
Autodiscover Endpoint and in the second phase, the Autodiscover Endpoint will
need also to “trust” the Autodiscover client.
The “trust” begins with the step, in which the Autodiscover Endpoint, needs to
prove his identity.
To be able to verify the Autodiscover Endpoint identity, the Autodiscover client will
ask from the Autodiscover Endpoint to send him his public certificate.
information:

33#36
 The Autodiscover client request from the Autodiscover Endpoint to send him his
certificate.
 The Autodiscover Endpoint sends his certificate.
 The certificate was successfully accepted by the Autodiscover client.
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from
remote server o365info.com on port 443.
The Microsoft Connectivity Analyzer successfully obtained the remote SSL
certificate.
Additional Details
In the following section, we can see the content of the server public certificate that
was sent to the Autodiscover client.
Remote Certificate Subject: CN=ssl2000.cloudflare.com, O=”CloudFlare, Inc.”, L=San
Francisco, S=CA, C=US, Issuer: CN=GlobalSign Organization Validation CA – G2,
O=GlobalSign nv-sa, C=BE.
Step 4/30: Testing the o365info.com SSL certificate to make sure it’s
valid.
The Autodiscover client will need to implement three different verification test, to
be able to “approve” the server certificate.
(In case that one of the three different tests failed, the certificate will not be
considered as valid).
The first test, realities of the - ”Host name”. The Autodiscover client will check if the
certificate includes the hostname of the Autodiscover Endpoint.
In our scenario, the Autodiscover client will try to look for the host name
– o365info.com

33#36
In our example, the result is “failure” because, the certificate that was provided by
the server doesn’t contain the hostname – o365info.com
In the Microsoft Remote Connectivity Analyzer result page, we can see information
about the fact that the server certificate doesn’t include the required host name.
Host name o365info.com doesn’t match any name found on the server certificate
CN=ssl2000.cloudflare.com, O=”CloudFlare, Inc.”, L=San Francisco, S=CA, C=US.
Step 5/30: Attempting to resolve the host name
autodiscover.o365info.com
Because the communication attempt with the potential Autodiscover Endpoint
using the hostname Because, the communication attempt with failed, Autodiscover
client will pass to the next method, in which Autodiscover client will look for a
potential Autodiscover Endpoint using the following naming scheme – Autodiscover
+ <Recipient SMTP domain>
In our scenario, the recipient E-mail address is – Alice@o365info.com
Based on this specific E-mail address; the Autodiscover client will create a DNS
query looking for an IP address of a host named – o365info.com

33#36
In our scenario, the host name autodiscover.o365info.com is mapped” to the
Exchange on-Premises server
Note – Don’t forget that in a Hybrid environment, even if the recipient mailbox is
hosted on the Exchange Online, the focal point is the Exchange On-Premise
infrastructure.
The Autodiscover client will start the Autodiscover flow by addressing the Exchange
On-Premise and in a later phase will be “redirected”, to his “cloud mail
infrastructure” (Exchange Online).
information:
Attempting to resolve the host name autodiscover.o365info.com in DNS. The host
name resolved successfully. IP addresses returned: 212.25.80.239
Step 6/30: Testing TCP port 443 on host autodiscover.o365info.com to
ensure it’s listening and open.

33#36
The Autodiscover client addresses the potential Autodiscover Endpoint, using the IP
address that he got in the former step.
The Autodiscover client, will try to verify if – the potential Autodiscover Endpoint
can communicate using the HTTPS protocol (port 443).
In our scenario, the HTTPS communication test succeeds. The “server” approves
that he can communicate using HTTPS.
information:
Testing TCP port 443 on host autodiscover.o365info.com to ensure it’s listening and
open. The port was opened successfully.
Step 7/30: Attempting to obtain the SSL certificate from remote server
autodiscover.o365info.com

33#36
To be able to verify the Autodiscover Endpoint identity, the Autodiscover client will
ask from the Autodiscover Endpoint to send him his public certificate.
information:
 The Autodiscover client request from the Autodiscover Endpoint to send him his
certificate.
 The Autodiscover Endpoint sends his certificate.
 The certificate was successfully accepted by the Autodiscover client.
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from
remote server autodiscover.o365info.com on port 443.
The Microsoft Connectivity Analyzer successfully obtained the remote SSL
certificate.
In the following section, we can see the content of the server public certificate that
was sent to the Autodiscover client.
Remote Certificate Subject: CN=mail.o365info.com, OU=Domain Control Validated,
O=mail.o365info.com, Issuer: SERIALNUMBER=07969287, CN=Go Daddy Secure
Certification Authority, OU=http://certificates.godaddy.com/repository,
O=”GoDaddy.com, Inc.”, L=Scottsdale, S=Arizona, C=US.

33#36
In our scenario we can see that the server certificate was provided by
GoDaddy.com
Step 8/30: Testing the autodiscover.o365info.com SSL certificate to
make sure it’s valid.
The certificate validation test which the Autodiscover client performs, includes
three distinct different parts.
1. Validating the certificate name
The Autodiscover client, address the potential Autodiscover Endpoint using the host
name –autodiscover.o365info.com
To be able to know that this is the valid or reliable source of information, the
Autodiscover client will check if the certificate includes the specified host name-
autodiscover.o365info.com or the domain name – *.o365info.com in a scenario of a
wildcard certificate.

33#36
2. Validating the certificate trust
The public certificate that the server provides, was provided by a CA (certificate
authority). The Autodiscover client will need also to validate the CA certificate that
provides the server (Autodiscover Endpoint) his certificate.
3. Verify that the certificate date is valid.
The Autodiscover client will need to verify that the server certificate date is valid.
Note – In case that you want to read more detailed information about the subject of
Autodiscover, security mechanism and certificates, read the article: Autodiscover
process and Exchange security infrastructure | Part 20#36
information:
1. Validating the certificate name
The Autodiscover client, verify that the server certificate includes the server FQDN
or the server domain name.

33#36
Validating the certificate name. The certificate name was validated successfully.
Host name autodiscover.o365info.com was found in the Certificate Subject
Alternative Name entry.
2. Validating the certificate trust
 The Autodiscover client verifies the trust chain that appears in the server
certificate.
 The Autodiscover client successfully manages to verify the trust chain.
The Microsoft Connectivity Analyzer is attempting to build certificate chains for
certificate CN=mail.o365info.com, OU=Domain Control Validated,
O=mail.o365info.com. One or more certificate chains were constructed
successfully.
3. Verify that the certificate date is valid.
The Autodiscover client verifies that the server certificate is still valid and was not
expired.
In our example, the test complete successfully meaning the server certificate is
valid.

33#36
Date validation passed. The certificate hasn’t expired. The certificate is valid.
NotBefore = 1/26/2013 11:22:11 PM, NotAfter = 1/26/2015 11:22:11 PM
Step 9/30: Checking the IIS configuration for client certificate
authentication
The “trust channel” between the Autodiscover client and the Autodiscover Endpoint,
is built on the ability of each party to prove his identity.
In the former section, the Autodiscover client managed to successfully verify the
server’s identity.
Now, we are getting to the second part, in which the Autodiscover client will need to
prove his identity to the server for getting the required Autodiscover information.
The Autodiscover client, verify if the destination host (the Autodiscover Endpoint)
needs a client certificate. (A client certificate, is a method in which the client can
prove his identity).
The use of a client certificate is very rare and, most of the time, the way that the
client uses for “proof his identity” is by providing a user’s credentials.

33#36
In the Microsoft Remote Connectivity Analyzer result page, we can see that
 The Autodiscover client asks the server if a client certificate is required.
 The server replies that he doesn’t need a client side certificate.
Checking the IIS configuration for client certificate authentication. Client certificate
authentication wasn’t detected. Accept/Require Client Certificates isn’t configured.
Step 10/30: Providing user credentials to the Autodiscover Endpoint
After the certificate validation, test was successfully completed and the
Autodiscover client can “trust” the destination host, the Autodiscover client will also
need to prove his identity.
The Autodiscover client will identify himself by providing a user’s credentials”
(User name + password).

33#36
Note – the part of “providing user credentials“, doesn’t appear in the Microsoft
Remote Connectivity Analyzer result page.
Step 11/30: Attempting to send an Autodiscover POST request to
potential Autodiscover URL:
https://autodiscover.o365info.com/autodiscover/autodiscover.xml
The Autodiscover client will attempt to send an Autodiscover POST request to the
Autodiscover Endpoint, for getting the required Autodiscover information.
In our scenario, the Autodiscover Endpoint is Exchange on-Premises Public facing
server.
If you remember, Alice’s mailbox is hosted on the Exchange Online server.
The Exchange On-Premise relates to Alice’s mailbox as a “Remote mailbox”.
Because the Exchange on-Premises is to the “owner” of Alice’s mailbox, the
Exchange on-Premises answer will include a redirection to the “real” Exchange
infrastructure that host Alice’s mailbox meaning – Exchange Online infrastructure.

33#36
Exchange on-Premises “inform” the user (Alice) that is should perform the
Autodiscover process using a new or, updated E-mail address.
In our scenario, the Exchange On-Premise informs Alice that her “real E-mail
address” is –Alice@o365info2.onmicrosoft.com
Hybrid environment and Office 365 “Hybrid domain name”
Before we continue with the Autodiscover process description, it’s important to
understand the concept of the E-mail address in a Hybrid environment.
In our specific scenario, the SMTP domain name space that is used for
“representing” Exchange Online recipients is – o365info2.mail.onmicrosoft.com
This “domain name” is not a real domain name that will be used for Autodiscover
process, but instead, just a “logical pointer” that will “lead” Exchange Online
recipients to the Exchange Online Autodiscover infrastructure.
When the Autodiscover client tries to look for a hosted named
– o365info2.onmicrosoft.com, the process will fail, because the host name is not
supposed to be published.
In the following diagram, we can see that the Exchange on-Premises Autodiscover
response includes a redirection message.
The Exchange on-Premises inform Alice that her “real” E-mail address is-
Alice@o365info2.mail.onmicrosoft.com

33#36
information:
 The Autodiscover client addresses the Autodiscover Endpoint asking for
Autodiscover information.
 The Autodiscover Endpoint response includes a redirection message that
includes “another” E-mail address.
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover
response from URL
https://autodiscover.o365info.com:443/Autodiscover/Autodiscover.xml for user
alice@o365info.com. The Autodiscover XML response was successfully retrieved.
Autodiscover Domain Redirection
<Action>redirectAddr</Action>
<RedirectAddr>Alice@o365info2.mail.onmicrosoft.com</RedirectAddr>

33#36
o365info2.mail.onmicrosoft.com
Now, the Autodiscover flow is “moved” from the Exchange On-Premise environment
into the “cloud environment” (Office 365 and Exchange Online).
The Autodiscover client “understand” that he needs to restart the Autodiscover
process all over again. The Autodiscover process will be based on the “new E-mail
Address” that was delivered to Alice – Alice@o365info2.mail.onmicrosoft.com
As we already know, the Autodiscover client will “extract” the “right part” of the
recipient
E-mail address in try to start a DNS query looking for this host name.
The Autodiscover client will address a DNS server, looking for the IP address of the
host named – o365info2.mail.onmicrosoft.com
The request for information will fail because, in reality, there is no such host.

33#36
information:
 The Autodiscover client addresses the DNS server looking for The IP address of
the host –mail.onmicrosoft.com
 The DNS answer is that he doesn’t have any information about the specific host
name.
Attempting to resolve the host name o365info2.mail.onmicrosoft.com in DNS. The
host name couldn’t be resolved. Host o365info2.mail.onmicrosoft.com couldn’t be
resolved in DNS InfoNoRecords.
autodiscover.o365info2.mail.onmicrosoft.com

33#36
In case that the Autodiscover client cannot find his Autodiscover Endpoint using the
“domain naming convention”, the Autodiscover client will try to look for the
Autodiscover Endpoint using the FQDN using the following naming scheme
– Autodiscover +<E-mail SMTP domain name>
In our scenario, the result of this “formula” is a named host-
The Autodiscover client will address a DNS server, looking for the IP address of the
host named –autodiscover.o365info2.mail.onmicrosoft.com
The DNS Server “answer”, include a list of IP addresses. The reason for the “multiple
IP address” is that in Office 365 we use a “logical host name” that in the reality, can
be “mapped to” many physical servers.
information:
The DNS reply includes a list of IP addresses that are “mapped” to the host named –
Attempting to resolve the host name autodiscover.o365info2.mail.onmicrosoft.com
in DNS. The host name resolved successfully. IP addresses returned:
157.56.244.217, 157.56.236.89, 157.56.232.9, 157.56.234.137

33#36
Step 14/30: Testing TCP port 443 on host
autodiscover.o365info2.mail.onmicrosoft.com to ensure it’s listening
and open
Autodiscover client, try to verify if he can continue the Autodiscover process with
the host-autodiscover.o365info2.mail.onmicrosoft.com by checking if the destination
host can communicate using HTTPS protocol.
The result of the “HTTPS test” is -failure.
This is an expected result, because the
host autodiscover.o365info2.mail.onmicrosoft.com, is not a “real” Exchange server.
information:
The Autodiscover client tries to check if the host
– autodiscover.o365info2.mail.onmicrosoft.comcan communicate using the HTTPS

33#36
protocol. The result is that the specific host doesn’t listen to port 443 (the default
HTTPS protocol).
Testing TCP port 443 on host autodiscover.o365info2.mail.onmicrosoft.com to
ensure it’s listening and open. The specified port is either blocked, not listening, or
not producing the expected response. Network error occurred while
communicating with the remote host.
Step 15/30: Attempting to contact the Autodiscover service using the
HTTP redirect method
The Autodiscover client algorithm is based on the following concept – in case that
the Potential Autodiscover Endpoint cannot respond to an HTTPS request, the
Autodiscover client is not willing to “surrender” and instead to give up; the
Autodiscover client will try another method in which his address the Potential
Autodiscover Endpoint using the HTTP protocol asking for instructions for- “How to
get to his Autodiscover Endpoint”.

33#36
The Autodiscover client checks if the
host autodiscover.o365info2.mail.onmicrosoft.com, can communicate using the HTTP
protocol.

33#36
information:
The Autodiscover client tries to check if the host
– autodiscover.o365info2.mail.onmicrosoft.comcan communicate using the HTTP
protocol. The result is that the specific host listen to port 80 (the default HTTP
protocol).
Testing TCP port 80 on host autodiscover.o365info2.mail.onmicrosoft.com to
ensure it’s listening and open. The port was opened successfully.
The continuation of the Autodiscover flow in an Exchange hybrid environment
appears in the next article – Autodiscover flow in an Exchange Hybrid environment
| Part 3#3 | Part 34#36

Autodiscover flow in an exchange hybrid environment part 2#3 part 33#36

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (10)

Plus de Eyal Doron

Plus de Eyal Doron (20)

Dernier

Dernier (20)

Autodiscover flow in an exchange hybrid environment part 2#3 part 33#36