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

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 HTTPS, the Autodiscover client will “draw back” and, try to contact 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 unique Office 365 component, which serves 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.

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

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 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 previous HTTP redirect mechanism?

A2: The above process based on the HTTP protocol, and the current redirection process relies on HTTPS redirect mechanism.

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

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 fascinating 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 has a public certificate that includes 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, which has a different hostname from the “original hostname” that the Autodiscover client try to use.

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?

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.

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

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.

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

In the Microsoft Remote Connectivity Analyzer result page, we can see the following 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.

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.

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

In the Microsoft Remote Connectivity Analyzer result page, we can see the following 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.

Step 19/30: Attempting to obtain the SSL certificate from remote server autodiscover-s.outlook.com

The Autodiscover client, ask from the Autodiscover Endpoint (autodiscover-s.outlook.com) to prove his identity by providing a valid public certificate.

Step 19/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 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.

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

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 provides, provided by a CA (certificate authority). The Autodiscover client will also need 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

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 20/30: Analyzing the data from the ExRCA connectivity test

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

1. Validating the certificate name

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.

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.

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

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.

Step 21/30: 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 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.”
(username + password).

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

Step 23/30: Attempting to send an Autodiscover POST request to autodiscover-s.outlook.com

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

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

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

In the Microsoft Remote Connectivity Analyzer result page, we can see the following 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 Alice@o365info2.mail.onmicrosoft.com. 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.

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

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.com Autodiscover Endpoint, support an HTTPS communication.

In our scenario, the test complete successfully meaning that, Pod51049.outlook.com support HTTPS communication.

Step 25/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 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.

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

In the Microsoft Remote Connectivity Analyzer result page, we can see the following 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.

The certificate validation test which the Autodiscover client performs, includes three distinct different parts.

1. Validating the certificate name
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

2. Validating the certificate trust
The public certificate that the server provides, provided by a CA (certificate authority). The Autodiscover client will need to validate also 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.

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 27/30: Analyzing the data from the ExRCA connectivity test

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

1. Validating the certificate name

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

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

Step 28/30: 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 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” (username + password).

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

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”, find his Exchange CAS server.

In this phases all the “pre requirements tasks” have already successfully completed- Autodiscover manages 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.

In our scenario, the “client” is an Outlook client that will use the information in the Autodiscover response for two primary 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 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 included in the Autodiscover answer, each time that Outlook will need a particular Exchange to serve such as availability services (Free/Busy time), OAB (Offline address book) and so on.

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

The Exchange CAS server Autodiscover responds is implemented as an XML file that includes tons of “information lines” (XML Tags).

We will not get into a detailed review of each of this “information bank line” but instead, examine just a small sample of the Autodiscover respond content.

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

The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://pod51049.outlook.com/Autodiscover/Autodiscover.xml for user Alice@o365info2.mail.onmicrosoft.com.
The Autodiscover XML response was successfully retrieved.

The information in the Exchange Autodiscover response dived into a sections.

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 of the XML tag’s names and the information that included between these XML tags.

For example:
1. Outlook GUID\session ID

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>61b3c3e6-97ba-4714-bcbb-d45efe969e56@o365info.com</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 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 response 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 “offline” 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>

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 particular setting that is 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 which server that provides the Outlook Anywhere services (RPC Proxy) is – outlook.office365.com

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