Autodiscover Flow in An Office 365 Environment Part 3-3 - Part 31 of 36

Page 1 of 24 | Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36
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
Written by Eyal Doron | o365info.com | Copyright 2012-2015
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 its 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 doesnt
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 doesnt 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 its 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 its 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 hasnt 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
servers 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 users 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 doesnt need a client side certificate.
Checking the IIS configuration for client certificate authentication. Client certificate
authentication wasnt detected. Accept/Require Client Certificates isnt configured.
Step 12/20: Providing user credentials to the Autodiscover

Endpoint
The Autodiscover proves his identity by providing a users credentials (user name +
password).
Note the part of providing user credentials, doesnt 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 its 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 its 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 its 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 hasnt 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 doesnt need a client side
certificate.
Checking the IIS configuration for client certificate authentication. Client certificate
authentication wasnt detected. Accept/Require Client Certificates isnt 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 users credentials
(User name + password).
Note the part of providing user credentials doesnt 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 doesnt 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 (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).
<OABUrl>https://outlook.office365.com/OAB/226ce079-2845-4fac-be536ccebb70c82a/</OABUrl>

Autodiscover Flow in An Office 365 Environment Part 3-3 - Part 31 of 36

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Autodiscover Flow in An Office 365 Environment Part 3-3 - Part 31 of 36

Încărcat de

Drepturi de autor:

Formate disponibile

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

Autodiscover flow in an Office 365

Autodiscover flow in an Office 365 environment | The article

Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

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

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

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

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

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

Step 10/20: Testing the autodiscover-s.outlook.com SSL

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

1. Validating the certificate name

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

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

2. Validating the certificate trust

3. Verify that the certificate date is valid.

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

Step 11/20: Checking the IIS configuration for client certificate

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

The Autodiscover client asks the server if a client certificate is required.

Step 12/20: Providing user credentials to the Autodiscover

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

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

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

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

s.outlook.com/Autodiscover/Autodiscover.xml for user Bob@o365info.com The

Step 14/20: Attempting to resolve the host name

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

IP addresses returned: 132.245.229.146, 132.245.226.34, 157.56.251.217,

Step 15/20: Testing TCP port 443 on host

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

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

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

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

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

1. Validating the certificate name

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

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

2. Validating the certificate trust.

3. Verify that the certificate date is valid.

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

Step 18/20: Checking the IIS configuration for client certificate

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

Step 19/20: Providing user credentials

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

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

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

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

1. The Autodiscover Exchange provider (number 1).

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

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

S-ar putea să vă placă și