autodiscover flow in an exchange hybrid environment | part 3#3 | part 34#36

of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part

34#36

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

Autodiscover flow in an Exchange

Hybrid environment | Part 3#3 | Part

34#36

The current article, is the continuation of the previous article , in which we will

continue to review in details the Autodiscover journey in Exchange Hybrid based

environment

Autodiscover flow in an Exchange Hybrid environment | The

article series

The current article is the last 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 2#3 | Part

33#36

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


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

http://o365info.com/







34#36


Step 16/30: redirect (HTTP 301/302) response

The Autodiscover client is “programmed” to use an HTTP redirect request, in case

that the potential Autodiscover Endpoint cannot communicate using HTTPS.

In our example, because the potential Autodiscover Endpoint cannot communicate

using HTPTS, the Autodiscover client will “draw back” and, try to communicate with

the Autodiscover Endpoint using the HTTP protocol.

The Autodiscover client HTTP request will include requests for information about

“other Autodiscover Endpoint” name that can provide the required information.

In our scenario, the Autodiscover client addresses the host

– autodiscover.o365info2.mail.onmicrosoft.com

The autodiscover.o365info2.mail.onmicrosoft.com host, is a special Office 365

component, which serve as a “logical router”, that is responsible for redirecting

Autodiscover clients to an additional nodes or elements (Autodiscover Endpoints),

that can help the Autodiscover client to reach his final destination.






34#36


In our scenario, the HTTP redirect message that the Autodiscover Endpoint provide

to his Autodiscover client, include the URL address of a Potential Autodiscover

Endpoint named

– autodiscover-s.outlook.com






34#36


In the following diagram, we can see the specific Autodiscover phase in which the

Autodiscover client is redirected to the “next hop” – autodiscover-s.outlook.com

Step 16/30: Analyzing the data from the ExRCA connectivity test

In the Microsoft Remote Connectivity Analyzer result page, we can see the following

information-

The Autodiscover Endpoint reply, using a redirection message code (HTTP 301/302)

and provide to the Autodiscover client the “full URL” address of the destination






34#36


Autodiscover Endpoint – https://autodiscover-

s.outlook.com/Autodiscover/Autodiscover.xml

The Microsoft Connectivity Analyzer is checking the host

autodiscover.o365info2.mail.onmicrosoft.com for an HTTP redirect to the

Autodiscover service. The redirect (HTTP 301/302) response was received

successfully. Redirect URL:

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

Step 17/30: Attempting to resolve the hostname autodiscover-

s.outlook.com

Autodiscover client query the DNS server for the IP address of the host –

autodiscover-s.outlook.com

Before we continue, it’s important to stop for a minute and ask ourselves-

Q1: Who is, or what is, the host autodiscover-s.outlook.com?

A1: The host named – autodiscover-s.outlook.com, is an additional Office 365

component that serves also as a “logical router.

Q1: If the autodiscover-s.outlook.com, considers also as a logical router, what is the

difference from the former HTTP redirect mechanism?

A2: The former process was based on the HTTP protocol and the current

redirection process is based on HTTPS redirect mechanism.

Q3: So… what is the big difference between HTTP versus HTTPS redirection?






34#36


A3: The difference is that when using the HTTPS redirection method, the

Autodiscover client will need to verify the Autodiscover Endpoint certificate so he

will be able to “believe” him,

The “redirect game”, is a very interesting concept that is implemented in the Office

365 cloud environment.

In a “standard” Exchange on-Premises environment, that Autodiscover client that

communicates with his Exchange server, expects from the server to provide an SSL

certificate that includes the FQDN of the Autodiscover Endpoint or the domain

name (in case that the server use wildcard certificate).

For example, in our scenario, the Autodiscover client will use Alice E-mail address,

domain name and when the Autodiscover client will start the HTTPS session with

the Exchange server, the Autodiscover client will look at the server certificate

looking for the hostname –autodiscover.o365info.com or for the domain name

– o365info.com

In case that the server certificate will not include the specified name, the

Autodiscover client is “obliged” to stop the communication process and, move on to

another method or display an error message.

In the Office 365 cloud environment, the interesting fact is that there is no “real”

Exchange server that have a public certificate that include the “required hostname”

such as –

autodiscover.o365info.com

In reality, there is no option to purchase a dedicated public certificate for each of

the Office 365 tenants.

In this case, theoretically, the Autodiscover process should fail.

The solution for this “enigma” is – a process is which the Autodiscover client will be

“instructed” to communicate with “other” Autodiscover Endpoint, that have a

different host name from the “original host name” that the Autodiscover client try

to use.






34#36


If you are a suspicious fellow, a paranoid thought could appear in your mind – if the

Autodiscover client looks for a very specific host name (such

as autodiscover.o365info.com in our scenario) and the “cloud” redirect the

Autodiscover client to other Autodiscover Endpoint hostname such as

– autodiscover-s.outlook.com , how can we know that this is not a fraud or a

conspiracy that could lead the “Autodiscover client” to un-trusted elements?






34#36


The answer to this “fears” is that the Autodiscover Endpoint which the Autodiscover

client is “redirected to” (the autodiscover-s.outlook.com) will have to prove his

identity and to the fact that he is trustworthy, by providing a public certificate.

The Autodiscover Endpoint – autodiscover-s.outlook.com have a public certificate

that includes all of the required “parts” that will be verified by the Autodiscover

client.

Only after all of the “certificate parts” will be tested and verified by the Autodiscover

client, then the Autodiscover client will be able to “believe” that the host –

autodiscover-s.outlook.com is a reliable source of information.






34#36


In the next sections, we will see that the autodiscover-s.outlook.com is not the last

hope in our Autodiscover journey, but for now, let’s carry on with the description of

the Autodiscover steps.

The Autodiscover client query the DNS server for the IP address of the host –


The DNS answer includes a range of IP address because, in reality, Office 365

infrastructure is a couple of “nodes” or “hosts” that “play the role” of

the autodiscover-s.outlook.com host.



information:

Attempting to resolve the host name autodiscover-s.outlook.com in DNS. The host

name resolved successfully. IP addresses returned: 157.56.241.102, 157.56.245.166,

157.56.232.166, 157.56.245.70, 157.56.236.214, 157.56.236.6.






34#36


Step 18/30: Testing TCP port 443 on host autodiscover-s.outlook.com to ensure

it’s listening and open

The Autodiscover client will try to verify if the autodiscover-s.outlook.com , supports

an HTTPS communication.

In our scenario, the test completes successfully meaning that autodiscover-

s.outlook.com support HTTPS communication.

Note – in case that you are wondering about the name of the host – “autodiscover-

s”, I could not find any formal explanation for the “S” in the host name but my belief

is that the “S” stand for security.



information:

Autodiscover client checks if the destination host can communicate using port 443

(HTTPS).

The results of the “HTTPS test” is -success.

Testing TCP port 443 on host autodiscover-s.outlook.com to ensure it’s listening

and open. The port was opened successfully.






34#36


Step 19/30: Attempting to obtain the SSL certificate from remote server


The Autodiscover client, ask from the Autodiscover Endpoint (autodiscover-

s.outlook.com) to prove his identity by providing a valid 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.






34#36


The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from

remote server autodiscover-s.outlook.com on port 443. The Microsoft Connectivity

Analyzer successfully obtained the remote SSL certificate.

Remote Certificate Subject: CN=outlook.com, OU=Microsoft Corporation,

O=Microsoft Corporation, L=Redmond, S=WA, C=US, Issuer: CN=Microsoft IT SSL

SHA2, OU=Microsoft IT, O=Microsoft Corporation, L=Redmond, S=Washington,

C=US.

In the information details, we can see that the certificate “belong” to the Microsoft

Corporation (OU=Microsoft Corporation) and, that the certificate include the

domain name -outlook.com (Remote Certificate Subject: CN=outlook.com).

Step 20/30: Testing the autodiscover-s.outlook.com SSL certificate to

make sure it’s valid

The certificate validation test which the Autodiscover client performs, includes

three distinct different parts.






34#36


1. Validating the certificate name

The Autodiscover client, address the potential Autodiscover Endpoint using the host

name –autodiscover-s.outlook.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-s.outlook.com or the domain name – *.outlook.com in a scenario of

wildcard certificate.

2. Validating the certificate trust

The public certificate that the server provide was provided by a CA (certificate

authority). The Autodiscover client will need also to validate the CA certificate that

provides the server his certificate.

3. Verify that the certificate date is valid

The Autodiscover client will need to verify that the server certificate date is valid






34#36


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:


The Autodiscover client, verify that the server certificate includes the server FQDN

or the server domain name.

Validating the certificate name. The certificate name was validated successfully.

Host name autodiscover-s.outlook.com was found in the Certificate Subject

Alternative Name entry.





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



34#36



The Autodiscover client verifies the trust chain that appears in the server

certificate.

The Autodiscover client successfully manages to verify the trust chain.

Certificate trust is being validated. The certificate is trusted and all certificates are

present in the chain. The Microsoft Connectivity Analyzer is attempting to build

certificate chains for certificate CN=outlook.com, OU=Microsoft Corporation,

O=Microsoft Corporation, L=Redmond, S=WA, C=US.

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.

Testing the certificate date to confirm the certificate is valid. Date validation passed.

The certificate hasn’t expired. The certificate is valid.

NotBefore = 2/18/2014 11:41:01 PM, NotAfter = 2/18/2016 11:41:01 PM






34#36


Step 21/30: Checking the IIS configuration for client certificate

authentication

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 be

proof his identity.


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.






34#36


Step 22/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 proof his identity.

The Autodiscover client will identify himself by providing a user’s credentials”

(user name + password).


Note – the part of “providing user credentials“, doesn’t appear in the Microsoft

Remote Connectivity Analyzer result page.






34#36


Step 23/30: Attempting to send an Autodiscover POST request to


The Autodiscover client will attempt to send an Autodiscover POST request to the

Autodiscover Endpoint for, getting the required Autodiscover information.

The host named – autodiscover-s.outlook.com is not the last node in our

Autodiscover journey but instead, “additional router” that will route the

Autodiscover Endpoint to his final destination – his Exchange server.

The redirection is implemented by using an additional – “HTTPS redirection”.

The Autodiscover client “trust” the host autodiscover-s.outlook.com but, the

autodiscover-s.outlook.com is not the “expected Exchange CAS server”.

In our specific scenario, autodiscover-s.outlook.com send an HTTPS redirection

message that includes the following URL address –

https://pod51049.outlook.com/Autodiscover/Autodiscover.xml

The Autodiscover client will “extract” from this URL address the host name –

Pod51049.outlook.com and in the next step, we will see the process in which the

Autodiscover Endpoint tries to communicate with this host for completing the

Autodiscover process.






34#36


In the following diagram, we can see the phase in which we are located in our

Autodiscover journey







34#36



information:

The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover

response from

URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml for user

[email protected]. The Autodiscover XML response was

successfully retrieved. An HTTPS redirect was received in response to the

Autodiscover request. The redirect URL is

https://pod51049.outlook.com/Autodiscover/Autodiscover.xml.

Step 24/30: Attempting to resolve the host name

pod51049.outlook.com

The Autodiscover client creates a DNS query looking for the host

named- Pod51049.outlook.com

From the DNS server answer, we can see that the resolution for this specified host

name (Pod51049.outlook.com) include a range of IP addresses.

Despite the logical assumption that the host – Pod51049.outlook.com is a single

server, in reality, the host “Pod51049.outlook.com” represent many “units” of Office

365 Exchange server who serve Office 365 clients requests.






34#36



In the Microsoft Remote Connectivity Analyzer result page, we can see the range of

the IP4 and the IP6 address that are mapped to the specified host name.

Attempting to resolve the host name pod51049.outlook.com in DNS. The host

name resolved successfully. IP addresses returned: 157.56.250.66, 157.56.254.178,

132.245.229.146, 132.245.226.34, 157.56.251.217, 157.56.255.60, 132.245.210.9,

132.245.212.98, 2a01:111:f400:9434::2, 2a01:111:f400:9850::2,

2a01:111:f400:8000::9, 2a01:111:f400:9428::2, 2a01:111:f400:9800::12,

2a01:111:f400:882a::2, 2a01:111:f400:803c::2, 2a01:111:f400:9814::9

Step 25/30: Testing TCP port 443 on host pod51049.outlook.com to

ensure it’s listening and open.

The Autodiscover client, will try to verify if the host named

– Pod51049.outlook.comAutodiscover Endpoint, support an HTTPS communication.

In our scenario, the test complete successfully meaning

that, Pod51049.outlook.com support HTTPS communication.






34#36




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 pod51049.outlook.com to ensure it’s listening and

open. The port was opened successfully.

Step 26/30: Asking from the potential Autodiscover Endpoint to provide

a public server certificate

Autodiscover client, ask from the Autodiscover Endpoint (Pod51049.outlook.com) to

proof his identity by providing a valid public certificate.






34#36




information:

The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from

remote server pod51049.outlook.com on port 443. The Microsoft Connectivity

Analyzer successfully obtained the remote SSL certificate.

Remote Certificate Subject: CN=outlook.com, OU=Exchange, O=Microsoft

Corporation, L=Redmond, S=Washington, C=US, Issuer: CN=Microsoft IT SSL SHA1,

OU=Microsoft IT, O=Microsoft Corporation, L=Redmond, S=Washington, C=US.

Step 27/30: Testing the pod51049.outlook.com SSL certificate to make

sure it’s valid.






34#36


The certificate validation test which the Autodiscover client performs, includes

three distinct different parts.


The Autodiscover client address the potential Autodiscover Endpoint using the host

named –Pod51049.outlook.com

To be able to know that this is the “real host”, Autodiscover client will check if the

certificate includes the specified host name (Pod51049.outlook.com) or, the domain

name – *.outlook.com


The public certificate that the server provides, was provided by a CA (certificate

authority). The Autodiscover client will need to validate also the CA certificate that

provides the server hos certificate.






34#36



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:


The Autodiscover client, verify that the server certificate includes the server FQDN

or the server domain name.








34#36


Validating the certificate name. The certificate name was validated successfully.

Host name pod51049.outlook.com was found in the Certificate Subject Alternative

Name entry.


The Autodiscover client verifies the trust chain that appears in the server

certificate.

The Autodiscover client successfully manages to verify the trust chain.

Certificate trust is being validated. The certificate is trusted, and all certificates are

present in the chain. The Microsoft Connectivity Analyzer is attempting to build

certificate chains for certificate CN=outlook.com, OU=Exchange, O=Microsoft

Corporation, L=Redmond, S=Washington, C=US.

One or more certificate chains were constructed successfully


The Autodiscover client verifies that the server certificate is still valid and was not

expired.






34#36


In our example, the test complete successfully meaning the server certificate is

valid.

Testing the certificate date to confirm the certificate is valid. Date validation passed.

The certificate hasn’t expired. The certificate is valid.

NotBefore = 7/24/2014 6:34:15 PM, NotAfter = 7/23/2016 6:34:15 PM

Step 28/30: Checking the IIS configuration for client certificate

authentication

The Autodiscover client, verify if the destination host (the Autodiscover Endpoint)

need a client certificate. A client certificate, is method in which the client can proof

his identity.


In the Microsoft Remote Connectivity Analyzer result page, we can see that






34#36


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 29/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 proof his identity.

The Autodiscover client will identify himself by providing a user’s credentials” (user

name + password).


Note – the part of “providing user credentials“, doesn’t appear in the Microsoft

Remote Connectivity Analyzer result page.






34#36


Step 30/30: Attempting to send an Autodiscover POST request to

potential Autodiscover

URL: https://pod51049.outlook.com/autodiscover/autodiscover.xml

This is the last stop on Outlook Autodiscover journey in the Hybrid environment.

Outlook or the “Autodiscover client”, fined his Exchange CAS server.

In this phases all the “pre requirements tasks” have already successfully completed-

Autodiscover manage to verify the Autodiscover Endpoint identity and provides his

identity to the Autodiscover Endpoint.

The last step, is the step in which the Autodiscover Endpoint (Exchange CAS server

named –Pod51049.outlook.com) will generate and send the Autodiscover response

to our Autodiscover client.






34#36


In our scenario, the “client” is an Outlook client that will use the information in the

Autodiscover response for two main purposes:

1. Creating a new Outlook mail profile

The “declared mission” in our scenario was to enable Alice to create a new Outlook

mail profile.

The information that included in the Autodiscover response, will include all the

required information that is needed for creating a new Outlook mail profile using

the Outlook Anywhere settings.

2. Using the URL address of the Exchange web services

After the task of creating new Outlook mail profile is completed, Outlook will us the

URL address of the different Exchange web services that was included in the

Autodiscover answer, each time that Outlook will need a specific Exchange to serve

such as availability services (Free/Busy time), OAB (Offline address book) and so on.


The Exchange CAS server Autodiscover responds is implemented as an XML file that

includes tons of “information lines” (XML Tags).






34#36


We will not get into a detailed review of each of this “information bank line” but

instead, review just a small sample of the Autodiscover respond content.


information:

The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover

response from URL https://pod51049.outlook.com/Autodiscover/Autodiscover.xml

for user [email protected].

The Autodiscover XML response was successfully retrieved.

The information in the Exchange Autodiscover response is dived into section.

The purpose of these sections is – to provide a different information for a different

mail profile of Outlook clients.

Exchange relates to the “different Outlook mail profile” as Outlook providers.

The different type classified as EXCH, EXPR, WEB and EXHTTP

EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings.

In the following screenshot, we can see an example for the XML tag’s names and

the information that included between these XML tags.

For example:

1. Outlook GUID\session ID






34#36


In an Exchange 2013 environment, the Outlook client doesn’t use the name of the

Exchange CAS server but instead, use a unique session ID.

The value of the unique session ID is provided by using the <Server> XML tag.

<Server>[email protected]</Server>

2. Availability services (Free/busy time)

Each time that a user accesses his calendar and, ask to view the Free/busy time of

other users, the Outlook client will send a query to the Exchange web service’s URL

address that is dedicated to this purpose.

<ASUrl>https://outlook.office365.com/EWS/Exchange.asmx</ASUrl>

3. Automatic reply (Out of office)

The Exchange Automatic reply web services, enable Exchange clients, to respond

with an Automatic reply when a recipient sent mail to their mailbox.

In case that the Exchange client need to create an Automatic reply respond, the

client will use the following URL address:

<OOFUrl>https://outlook.office365.com/EWS/Exchange.asmx</OOFUrl>

4. Offline address book

The default setting for Outlook mail profile is Cache mode. When using the option

of cache mode, Outlook client will download an “off line” version of the Exchange

address book.

Outlook will need to know the exact URL address that he will need to use for

downloading the Offline address book + the name of the offline address book file

or file version.

<OABUrl>https://outlook.office365.com/OAB/226ce079-2845-4fac-be53-

6ccebb70c82a/</OABUrl>






34#36


In the next screenshot, we can see the setting under the EXPR section (the setting

for an External Outlook Anywhere).

Here we can see additional details that are relevant or unique only when using the

Outlook Anywhere profile.

We can see that under the “EXPR profile” (<Type>EXPR</Type>) we can see a similar

setting such as the Exchange web services URL address:

<Server>outlook.office365.com</Server>

<ASUrl>https://outlook.office365.com/EWS/Exchange.asmx</ASUrl>

<OOFUrl>https://outlook.office365.com/EWS/Exchange.asmx</OOFUrl>

<OABUrl>https://outlook.office365.com/OAB/226ce079-2845-4fac-be53-

6ccebb70c82a/</OABUrl>

And additionally, a specific setting that are unlike for Outlook Anywhere such as the

authentication and encryption requirements.

In our example, the Autodiscover responds “inform” the Outlook client that

1. The name of the Exchange CAS server

The name of the Exchange CAS server who server that provides the Outlook

Anywhere services (RPC Proxy) is – outlook.office365.com






34#36


<Server>outlook.office365.com</Server>

2. Encryption requirement

The communication channel between the Outlook client and the Exchange server

muse be implemented using HTTPS and the authentication protocol is – Basic

<SSL>On</SSL><AuthPackage>Basic</AuthPackage>

3. The RPC\HTTPS hostname provider and the public certificate

To be able to verify that the Exchange server is “reliable” and can be trusted, the

Outlook client will check if the server certificate includes the value that described in

the msstd.

<CertPrincipalName>msstd:outlook.com</CertPrincipalName>;





autodiscover flow in an exchange hybrid environment | part 3#3 | part 34#36

Documents