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

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

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 Bob@o365info.com 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 bob@o365info.com
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>e2437a8c-a37f-4e6a-bccd-26a71abd2543@o365info.com</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 (FreeBusy 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).

<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

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Autodiscover flow in an office 365 environment part 3#3 part 31#36 (20)

More from Eyal Doron (20)

Recently uploaded (20)

Autodiscover flow in an office 365 environment part 3#3 part 31#36