Autodiscover flow in an Exchange Hybrid environment | Part 2#3 | Part 33#36

Page 1 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

http://o365info.com/autodiscover-flow-in-an-exchange-hybrid-environment-part-2-of-3-part-33-of-36


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/

http://o365info.com/autodiscover-flow-in-an-exchange-hybrid-environment-part-3-of-3-part-34-of-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 –

[email protected], 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

– o365info\Alice

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 – [email protected]






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 – [email protected]

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 – [email protected]

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.





http://o365info.com/autodiscover-process-and-exchange-security-infrastructure-part-20-of-36

http://o365info.com/autodiscover-process-and-exchange-security-infrastructure-part-20-of-36


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 –[email protected]

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-

[email protected]






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

[email protected]. The Autodiscover XML response was successfully retrieved.

Autodiscover Domain Redirection

<Action>redirectAddr</Action>

<RedirectAddr>[email protected]</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 – [email protected]

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







Documents

Autodiscover flow in an Exchange Hybrid environment | Part 2#3 | Part 33#36