Skip to content

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 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:

Table of contents

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 of 20 - Attempting to resolve the host name autodiscover-s.outlook.com in DNS-01

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 7 of 20 - Attempting to resolve the host name autodiscover-s.outlook.com in DNS-02

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.

Step 8 of 20 - Testing TCP port 443 on host autodiscover-s.outlook.com to ensure it's listening and open-01

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

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 8 of 20 - Testing TCP port 443 on host autodiscover-s.outlook.com to ensure it's listening and open-02

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 also need 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.

Step 9 of 20 - Attempting to obtain the SSL certificate from remote server autodiscover-s.outlook.com-01

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

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 9 of 20 - Attempting to obtain the SSL certificate from remote server autodiscover-s.outlook.com-02

Step 10/20: Testing the autodiscover-s.outlook.com SSL certificate to make sure it’s valid

Step 10 of 20 - Testing the autodiscover-s.outlook.com SSL certificate to make sure it's valid-01

The certificate validation test which the Autodiscover client performs includes three distinctly 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 provides, created by a CA (certificate authority).
The Autodiscover client will also need 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.

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

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

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

Step 10 of 20 - Testing the autodiscover-s.outlook.com SSL certificate to make sure it's valid-02

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.

Step 10 of 20 - Testing the autodiscover-s.outlook.com SSL certificate to make sure it's valid-03

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

Step 10 of 20 - Testing the autodiscover-s.outlook.com SSL certificate to make sure it's valid-04

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 previous section, the Autodiscover client managed to verify the server’s identity successfully.
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.

Step 11 of 20 - Checking the IIS configuration for client certificate authentication-01

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

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 11 of 20 - Checking the IIS configuration for client certificate authentication-02

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

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

Step 13 of 20 - Attempting to send an Autodiscover POST request to autodiscover-s.outlook.com-01

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

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 is https://pod51049.outlook.com/Autodiscover/Autodiscover.xml.

Step 13 of 20 - Attempting to send an Autodiscover POST request to autodiscover-s.outlook.com-02

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

Step 14 of 20 - Attempting to resolve the host name pod51049.outlook.com in DNS-01

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

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 mapped to the hostname).

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 14 of 20 - Attempting to resolve the host name pod51049.outlook.com in DNS-02

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.

Step 15 of 20 - Testing TCP port 443 on host pod51049.outlook.com to ensure it's listening and open-01

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

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 15 of 20 - Testing TCP port 443 on host pod51049.outlook.com to ensure it's listening and open-02

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.

Step 16 of 20 - Asking form the potential Autodiscover Endpoint to provide a public server certificate-01

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

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 16 of 20 - Asking from the potential Autodiscover Endpoint to provide a public server certificate-02

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.

Step 17 of 20 - Testing the pod51049.outlook.com SSL certificate to make sure it's valid-01

1. Validating the certificate name
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 provides created by a CA (certificate authority).
The Autodiscover client will also need to validate the identity of the certificate authority which 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.

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

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

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.

Step 17 of 20 - Testing the pod51049.outlook.com SSL certificate to make sure it's valid-02

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.

Step 17 of 20 - Testing the pod51049.outlook.com SSL certificate to make sure it's valid-03

3. Verify that the certificate date is valid.
The client verifies that the server certificate is still valid and was not expired. In our example, the test completes 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 17 of 20 - Testing the pod51049.outlook.com SSL certificate to make sure it's valid-04

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.

Step 18 of 20 - Checking the IIS configuration for client certificate authentication-01

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

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 18 of 20 - Checking the IIS configuration for client certificate authentication-02

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 19 of 20 - Providing user credentials to the Autodiscover Endpoint-01

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

Step 20 of 20 - send an Autodiscover POST request to potential Autodiscover URL pod51049.outlook.com-01

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

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 response, 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>

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 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 provided to the mail client.

<Server>e2437a8c-a37f-4e6a-bccd-26a71abd2543@o365info.com</Server>

The Autodiscover response includes 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>

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

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

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

  1. Off line address book (number 4).

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

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

Step 20 of 20 - send an Autodiscover POST request to potential Autodiscover URL pod51049.outlook.com-02
o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 5 Comments

  1. Hello,

    Excellent write up on the autodiscover process. I have installed an Exchange 2016 server as my only server in a hybrid config. I have pointed autodiscover to it, internal and external. Autodiscover works perfect for on-premise mailboxes. For mailboxes migrated to Office 365, I receive an HTTP 500 error when it should get the redirection URL. Do you know why I would receive this error and not a redirection URL?

     

    Thank you,.

  2. Thank you for this information. This was extremely helpful towards understanding the autodiscover process for Office 365. I have not found anything close to this documented on the web.
    Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *