autodiscover flow in an office 365 environment | part 3#3 | part 31#36

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

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

Autodiscover flow in an Office 365

environment | Part 3#3 | Part 31#36

The current article is the continuation of the previous article, in which we 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).

Autodiscover flow in an Office 365 environment | The article

series

The current article is the third article in a series of three articles.

The additional articles in the series are:

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

http://o365info.com/autodiscover-flow-in-an-office-365-environment-part-3-of-3-part-31-of-36

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

http://o365info.com/

http://o365info.com/autodiscover-flow-in-an-office-365-environment-part-2-of-3-part-30-of-36/





Step 7/20: Attempting to resolve the host name autodiscover-

s.outlook.com in DNS.

In this step, the Autodiscover client query the DNS server for the IP address of a

host named –autodiscover-s.outlook.com

In case that you are wondering from where the Autodiscover client gets this

hostname, the answer is- from the URL address that was sent to him in the HTTP

redirection response.

Step 7/20: Analyzing the data from the ExRCA connectivity test

In the ExRCA result page, we can see the Autodiscover client address the DNS

server looking for the IP address of the host – autodiscover-s.outlook.com

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

Step 8/20: Testing TCP port 443 on the host autodiscover-

s.outlook.com to ensure it’s listening and open.






The Autodiscover client will try to verify if the potential Autodiscover Endpoint is

listing on port 443 (HTTPS).

In our scenario, the HTTPS communication test succeeded, meaning that the

destination host (the Autodiscover Endpoint) supports HTTPS communication.

Note –

1. The fact that the “destination host” support HTTPS protocol doesn’t

necessarily mean that the host is “right Exchange server” that can provide the

required Autodiscover information.

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 the required Autodiscover information.

In our scenario, we will soon see that the “destination host” is not the “end of the

journey” and he will not provide the Autodiscover client the required Autodiscover

response but instead, an HTTPS redirection message.


In the ExRCA result page, we can see that the Autodiscover client tries to verify if

the host –autodiscover-s.outlook.com, can communicate using TCP port 443.

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

and open: The port was opened successfully.






Step 9/20: Attempting to obtain the SSL certificate from the

remote server autodiscover-s.outlook.com on port 443

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.


In the ExRCA result page, we can see that the Autodiscover client asks from the host

–autodiscover-s.outlook.com to send his certificate.






The server sends his certificate and, in the result, we can see the details of the

certificate:

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.

Step 10/20: 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.






1. Validating the certificate name

The Autodiscover client addresses the potential Autodiscover Endpoint using the

host name-autodiscover-s.outlook.com

To be able to know a specific host is “reliable”, Autodiscover client will check if the

certificate includes the specified host name (autodiscover-s.outlook.com) or in a

wildcard certificate scenario, the domain name – *.outlook.com

2. Validating the certificate trust

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

authority).

The Autodiscover client will need to also to validate the identity of the certificate

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

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




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





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

about the three different tests that the Autodiscover client performs to the public

certificate that was sent by the server:


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

or the server domain name.

The certificate name was validated successfully.

Hostname autodiscover-s.outlook.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 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.

One or more certificate chains were constructed successfully.


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






Step 11/20: 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.


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 12/20: Providing user credentials to the Autodiscover

Endpoint

The Autodiscover proves his identity 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

Step 13/20: Attempting to send an Autodiscover POST request

to potential Autodiscover URLs






Autodiscover client “think” that the host – autodiscover-s.outlook.com is a potential

Autodiscover Endpoint and for this reason, the Autodiscover client creates a

request for the Autodiscover information.

Note that the term that is used for describing the Autodiscover Endpoint is – “a

potential Autodiscover Endpoint”.

The word “potential”, tell us that the Autodiscover client is aware of the fact that the

host he is addressing, could be the final node or a node that will redirect him to

additional Autodiscover Endpoint.

In our scenario, the “answer” that the host autodiscover-s.outlook.com provide

include a redirection message that redirects the Autodiscover client to additional

potential Autodiscover Endpoint named – pod51049.outlook.com


On the ExRCA result page, we can see the following information about the process:

The Autodiscover client, address the Autodiscover Endpoint and ask for the

Autodiscover response.

The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover

response from the URL – https://autodiscover-






s.outlook.com/Autodiscover/Autodiscover.xml for user [email protected] The

Autodiscover XML response was successfully retrieved.

However, instead of getting the required Autodiscover information, the

Autodiscover client gets a redirection answer to additional host:

An HTTPS redirect was received in response to the Autodiscover request. The

redirect URL ishttps://pod51049.outlook.com/Autodiscover/Autodiscover.xml.

Step 14/20: Attempting to resolve the host name

pod51049.outlook.com in DNS

To be able to reach the host named – pod51049.outlook.com, the Autodiscover client

will need to get information about the IP address of the specific host.

Autodiscover connects a DNS server and asks for the IP address on

– pod51049.outlook.com







In the ExRCA result page, we can see that the Autodiscover address, the DNS server

and the DNS server reply by providing a list of IP addresses (IP address that are

mapped to the host name).

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

name resolved successfully.

IP addresses returned: 132.245.229.146, 132.245.226.34, 157.56.251.217,

157.56.255.60, 132.245.210.9, 132.245.212.98, 157.56.250.66, 157.56.254.178,

2a01:111:f400:803c::2

Step 15/20: Testing TCP port 443 on host

pod51049.outlook.com to ensure it’s listening and open.

To be able to start the Autodiscover process with the potential Autodiscover

Endpoint (pod51049.outlook.com), the Autodiscover client needs to verify that the

destination host can communicate using the HTTPS protocol.







In the ExRCA result page, we can see that the Autodiscover client tries to verify of

the destination host can communicate using HTTPS and that the test was

successfully completed, meaning the destination host is listing the communication

requests that are sent to port 443.

Testing TCP port 443 on host pod51049.outlook.com to ensure it’s listening and

open. The port was opened successfully.

Step 16/20: Asking from the potential Autodiscover Endpoint to

provide a public server certificate

The Autodiscover client needs to be sure, that the destination host can be trusted.

For this reason, the Autodiscover client asks for the destination host

(pod51049.outlook.com) to prove his identity by providing a public certificate.







In the ExRCA result page, we can see that the Autodiscover client asks for the host –

pod51049.outlook.com to send his certificate.

The server sends his certificate and, in the result, we can see the details of the

certificate:

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.

Step 17/20: Testing the pod51049.outlook.com SSL certificate to

make sure it’s valid.

The certificate validation test which the Autodiscover client performs, includes

three different parts.







The Autodiscover client addresses the potential Autodiscover Endpoint using the

host name-pod51049.outlook.com

To be able to know a specific host is “reliable”, Autodiscover client will check if the

certificate includes the specified host name (pod51049.outlook.com) or in a wildcard

certificate scenario, the domain name – *.outlook.com

2. Validating the certificate trust.

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

authority).

The Autodiscover client, will need to also to validate the identity of the certificate

authority who 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.






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


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

about the three different tests that the Autodiscover client performs to the public

certificate that was sent by the server:

1. Validating the certificate name.

The client verifies that the server certificate includes the server FQDN or the server

domain name.

The certificate name was validated successfully. Hostname pod51049.outlook.com

was found in the Certificate Subject Alternative Name entry.








2. Validating the certificate trust.

The client verifies the trust chain that appears in the server certificate.

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 the certificate

CN=outlook.com, OU=Exchange, O=Microsoft Corporation, L=Redmond,

S=Washington, C=US.

One or more certificate chains were constructed successfully.


The client verifies that the server certificate is still valid and was not expired. In our

example, the test complete successfully.

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 18/20: Checking the IIS configuration for client certificate

authentication

The Autodiscover client, check 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.


In the ExRCA result page, we can see that the Autodiscover client asks the server id

he needs a client certificate; 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 19/20: Providing user credentials

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

Note – the part of “providing user credentials “doesn’t appear in the ExRCA results.

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

to potential Autodiscover URLs.

This is the “the last station” of the Autodiscover client journey.






In our specific scenario, the host pod51049.outlook.com is the Office 365 Public

facing Exchange server that will provide the Autodiscover client the required

Autodiscover information, the Autodiscover information that is needed for creating

a new Outlook mail profile, information about the available Exchange CAS server

web services and enable the mail client to access his Office 365 mailboxes.







In the ExRCA result page, we can see the Autodiscover steps in which the

Autodiscover client reaches his final destination.

The Autodiscover addresses the Potential Autodiscover Endpoint by using the URL

address –https://pod51049.outlook.com/Autodiscover/Autodiscover.xml and send a

“Post request” asking for the Autodiscover information.

The Potential Autodiscover Endpoint (Exchange Online CAS server) accepts the

request and sends Autodiscover response to his client.

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 Autodiscover response content

The Autodiscover response includes tons of information.

We will not review each of the “sections” that include in the Autodiscover responds,

but just as an example, we can see a couple of details that include in the

Autodiscover respond file:






1. The Autodiscover Exchange provider (number 1).

The exchange CAS server includes a couple of Outlook providers. The Autodiscover

information includes a dedicated section for each of this provider.

In our example, we took a screenshot of the part that includes the information for

the EXCH provider – <Type>EXCH</Type>

Note – If you need more detailed information about the Exchange Outlook

providers, read the article – The content of the Autodiscover server response | Part

11#36

2. The “name” of the Exchange Online CAS server

The Exchange Online infrastructure is built on the Exchange 2013 version. In the

Exchange 2013 environment, the mail client doesn’t use the Exchange CAS server

name but instead, the Autodiscover client gets a “session id” that serves as an

“address” for the mail client.

In our example, we can see the information about the “session address” that is

provided to the mail client.

<Server>[email protected]</Server>

The Autodiscover response includes a detailed information about each of the

Exchange CAS server web services that are “offered” to his clients.

In the following example, we can see the information about the available services:

1. Availability services (Free\Busy time) (number 2).

The URL address that the Outlook client is instructed to use is:

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

2. Automatic reply (Out of office) services (number 3).


<OOFUrl>https://ex01.o365info.local/ews/exchange.asmx</OOFUrl>

3. Off line address book (number 4).





http://o365info.com/the-content-of-the-autodiscover-server-response-part-11-of-36

http://o365info.com/the-content-of-the-autodiscover-server-response-part-11-of-36



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

6ccebb70c82a/</OABUrl>




autodiscover flow in an office 365 environment | part 3#3 | part 31#36

Documents