The current article and the next article, will be dedicated for detailed review of the Autodiscover flow, that is implemented in Exchange Hybrid environment, by using the Microsoft web-based tool, the Microsoft Remote Connectivity Analyzer (ExRCA).
Article Series - Exchange and Autodiscover infrastructure | Table of content
Autodiscover flow in an Exchange Hybrid environment | The article series
The current article is the second article in a series of three articles.
The additional articles in the series are:
A user in a Hybrid environment that his mailbox was migrating to the cloud, get a new desktop, double-click on the Outlook icon, Outlook is coughing and shivering and after a couple of seconds the user connects to his mailbox.
Sound simple, isn’t?
In reality, this “simple process” in which user create a new Outlook mail profile and automatically connect to his “cloud mailbox”, based on a very smart and complex Autodiscover process.
The reason for describing Exchange Hybrid Autodiscover flow as – “complicated” is, because for Exchange recipient whom their mailbox is hosted at the Exchange Online infrastructure, the Autodiscover flow in an Exchange hybrid environment will be implemented twice:
The first time using the Exchange on-Premises infrastructure and the second time, after the Exchange client gets a redirection message, the Autodiscover flow will be implemented against the Exchange Online infrastructure.
The magic of the Autodiscover journey in Exchange hybrid environment
In the current article and the next article (Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36), we will review in details, each of the many steps that include in the Autodiscover journey in Hybrid environment.
I have tried to separate each of these steps and came with a result of 30 different parts.
The number “30”, is just an arbitrary number because, the “Autodiscover Journey” can be dived even to more parts or fewer parts. The number of the “parts” depend on many variables.
So, if you have the required courage, come and join our long but interesting journey of reviling the Autodiscover flow in an Exchange hybrid environment!
This is your last chance. After this, there is no turning back. You take the blue pill—the story ends; you wake up in your bed and believe whatever you want to believe. You take the red pill—you stay in Wonderland, and I show you how deep the rabbit hole goes. Remember: all I’m offering is the truth, nothing more.
Quoted from the matrix part 1#3
Scenario description
To be able to demonstrate the Autodiscover process in Hybrid environment, we will use the following scenario:
An organization named – o365info.com, use a Hybrid Exchange configuration, which include a mixture of Exchange On-Premise mailboxes and cloud (Exchange Online) mailboxes.
In our scenario, a user named Alice that uses the following E-mail address – Alice@o365info.com, needs to create a new Outlook mail profile.
Alice’s mailbox was migrated to the cloud (Exchange Online).
The Autodiscover long journey in Hybrid environment
In the Hybrid environment, the Exchange On-Premise continues to serve as a “focal point” for the Autodiscover services.
Despite the fact that Alice mailbox is physically stored in the Exchange Online, the Autodiscover process will start with the Exchange On-Premise environment.
The Exchange client (Alice in our scenario) will try to connect their Exchange On-Premise server and in case that the user mailbox is “in the cloud”, the Exchange On-Premise is the element which will redirect the mail client to his “cloud mailbox” by providing him his “cloud E-mail address”.
Before we get into the details, it’s important that we will be able to see the “big picture” or the major nodes that will appear in our Autodiscover journey in the Hybrid environment.
In the following diagram, we can see the Autodiscover client, will need to pass through many nodes in his Autodiscover journey until he gets to his final destination, the Autodiscover Endpoint that will provide him the required Autodiscover information.
Using the Microsoft remote connectivity analyzer – the prefix
To be able to illustrate each of the Autodiscover steps that are involved in the Autodiscover flow, we will use a combination of diagrammatic and a screenshot from the result of the Microsoft remote connectivity analyzer.
In our scenario, we will use the ExRCA test named – Microsoft office Outlook Connectivity tests and, choose the Outlook Autodiscover test.
1. The Exchange “environment” | Exchange on-Premises
In our scenario, we examine the Autodiscover flow of a recipient whom his mailbox is hosted at the Exchange Online infrastructure.
Theoretically, we should have chosen the ExRCA “Office 365 tab” because the recipient mailbox is physically located at the Exchange Online infrastructure.
In the Exchange hybrid environment, the Exchange on-Premises serve as an “Autodiscover focal point”. The Autodiscover flow should be started by addressing the Exchange on-Premises serve and based on the ”redirection message” that will be provided to the Autodiscover client, continue the Autodiscover flow by addressing the Exchange Online infrastructure.
For this reason, we will choose the Exchange Server tab.
2. Login credentials
In a scenario in which we want to test an Autodiscover process, for user mailbox hosted in Exchange Online, we will have to use the UPN (User principal name) naming convention, although the process starts with Exchange On-Premise that enables to use the standard Active Directory login naming convention such as – o365info\Alice
The reason is that – in the first Autodiscover phase; the user identifies himself before the Exchange On-Premise but, in the next steps, the Autodiscover client will need to identify himself to the Exchange Online server who uses the Office 365 UPN naming convention such as – Alice@o365info.com
3. The two different Exchange infrastructures
Before we dive into the specific Autodiscover steps that are implemented in an Exchange hybrid environment, let’s start at the end, by looking at an example of ExRCA test that was completed.
In the following screenshot, we can see that the Autodiscover test was completed successfully.
The summary report displays information about two different Exchange environments:
- Exchange on-Premises environment
- Exchange Online environment
Using the Microsoft remote connectivity analyzer – the detailed description
In the following section and in the next article, we will review in details, each of the “30 steps” that are implemented in an Autodiscover flow in an Exchange hybrid environment.
Step 1/30: Attempting to resolve the hostname o365info.com
By default, Autodiscover client will try to locate a “potential Autodiscover Endpoint”, by using a host name who was “extracted” from the recipient E-mail address.
Autodiscover client will use the “right part” of the recipient E-mail address that includes the SMTP domain name.
In our scenario, the recipient E-mail address is – Alice@o365info.com
Based on this specific E-mail address; the Autodiscover client will create a DNS query looking for an IP address of a host named – o365info.com
The “answer” of the DNS server, depend on the specific organization, public server’s and services infrastructure.
For example, most of the organizations, have a public web site and, most of the time the public domain name is “mapped” to the public IP of the website.
In our scenario, the DNS server reply with a public IP address of the requested host name. The IP that was provided by the DNS server, doesn’t “belong” to an Exchange server (Autodiscover Endpoint) but instead, this public IP address is assigned to a standard web server.
Step 1/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following information:
The DNS name resolution step, in which the Autodiscover query the DNS server for the IP address of the host – o365info.com, complete successfully.
The DNS server reply with a list of public IP addresses.
Attempting to resolve the host name o365info.com in DNS. The host name resolved successfully. IP addresses returned: 104.28.12.85, 104.28.13.85
Step 2/30: Testing TCP port 443 on host o365info.com
The Autodiscover client addresses the potential Autodiscover Endpoint, using the IP address that he got in the former step.
The Autodiscover client, will try to verify if, the potential Autodiscover Endpoint can communicate using the HTTPS protocol (port 443).
In our scenario, the HTTPS communication test succeeds. The “server” approves that he can communicate using HTTPS.
Just a quick reminder
- Case 1 – the fact that the “destination host” support HTTPS protocol, doesn’t necessarily mean that the host is Exchange server who can provide the required Autodiscover services.
- Case 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 Autodiscover information to the Autodiscover client.
Step 2/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 o365info.com to ensure it’s listening and open. The port was opened successfully.
Step 3/30: Attempting to obtain the SSL certificate from remote server o365info.com
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.
Step 3/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 o365info.com on port 443.
The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
Additional Details
In the following section, we can see the content of the server public certificate that was sent to the Autodiscover client.
Remote Certificate Subject: CN=ssl2000.cloudflare.com, O=”CloudFlare, Inc.”, L=San Francisco, S=CA, C=US, Issuer: CN=GlobalSign Organization Validation CA – G2, O=GlobalSign nv-sa, C=BE.
Step 4/30: Testing the o365info.com SSL certificate to make sure it’s valid.
The Autodiscover client will need to implement three different verification test, to be able to “approve” the server certificate.
(In case that one of the three different tests failed, the certificate will not be considered as valid).
The first test, realities of the – ”Host name”. The Autodiscover client will check if the certificate includes the hostname of the Autodiscover Endpoint.
In our scenario, the Autodiscover client will try to look for the host name – o365info.com
In our example, the result is “failure” because, the certificate that was provided by the server doesn’t contain the hostname – o365info.com
Step 4/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see information about the fact that the server certificate doesn’t include the required host name.
Host name o365info.com doesn’t match any name found on the server certificate CN=ssl2000.cloudflare.com, O=”CloudFlare, Inc.”, L=San Francisco, S=CA, C=US.
Step 5/30: Attempting to resolve the host name autodiscover.o365info.com
Because the communication attempt with the potential Autodiscover Endpoint using the hostname Because, the communication attempt with failed, Autodiscover client will pass to the next method, in which Autodiscover client will look for a potential Autodiscover Endpoint using the following naming scheme – Autodiscover + <Recipient SMTP domain>
In our scenario, the recipient E-mail address is – Alice@o365info.com
Based on this specific E-mail address; the Autodiscover client will create a DNS query looking for an IP address of a host named – o365info.com
In our scenario, the host name autodiscover.o365info.com is mapped” to the Exchange on-Premises server
Note – Don’t forget that in a Hybrid environment, even if the recipient mailbox is hosted on the Exchange Online, the focal point is the Exchange On-Premise infrastructure.
The Autodiscover client will start the Autodiscover flow by addressing the Exchange
On-Premise and in a later phase will be “redirected”, to his “cloud mail infrastructure” (Exchange Online).
Step 5/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.o365info.com in DNS. The host name resolved successfully. IP addresses returned: 212.25.80.239
Step 6/30: Testing TCP port 443 on host autodiscover.o365info.com to ensure it’s listening and open.
The Autodiscover client addresses the potential Autodiscover Endpoint, using the IP address that he got in the former step.
The Autodiscover client, will try to verify if – the potential Autodiscover Endpoint can communicate using the HTTPS protocol (port 443).
In our scenario, the HTTPS communication test succeeds. The “server” approves that he can communicate using HTTPS.
Step 6/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following information:
Testing TCP port 443 on host autodiscover.o365info.com to ensure it’s listening and open. The port was opened successfully.
Step 7/30: Attempting to obtain the SSL certificate from remote server autodiscover.o365info.com
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 7/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.o365info.com on port 443.
The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
In the following section, we can see the content of the server public certificate that was sent to the Autodiscover client.
Remote Certificate Subject: CN=mail.o365info.com, OU=Domain Control Validated, O=mail.o365info.com, Issuer: SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=”GoDaddy.com, Inc.”, L=Scottsdale, S=Arizona, C=US.
In our scenario we can see that the server certificate was provided by GoDaddy.com
Step 8/30: Testing the autodiscover.o365info.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.o365info.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.o365info.com or the domain name – *.o365info.com in a scenario of a wildcard certificate.
2. Validating the certificate trust
The public certificate that the server provides, was provided by a CA (certificate authority). The Autodiscover client will need also to validate the CA certificate that provides the server (Autodiscover Endpoint) his certificate.
3. Verify that the certificate date is valid.
The Autodiscover client will need to verify that the server certificate date is valid.
Step 8/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.o365info.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 Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=mail.o365info.com, OU=Domain Control Validated, O=mail.o365info.com. 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.
Date validation passed. The certificate hasn’t expired. The certificate is valid. NotBefore = 1/26/2013 11:22:11 PM, NotAfter = 1/26/2015 11:22:11 PM
Step 9/30: 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.
Step 9/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 10/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 prove his identity.
The Autodiscover client will identify himself by providing a user’s credentials”
(User name + password).
Step 10/30: Analyzing the data from the ExRCA connectivity test
Step 11/30: Attempting to send an Autodiscover POST request to potential Autodiscover URL: https://autodiscover.o365info.com/autodiscover/autodiscover.xml
The Autodiscover client will attempt to send an Autodiscover POST request to the Autodiscover Endpoint, for getting the required Autodiscover information.
In our scenario, the Autodiscover Endpoint is Exchange on-Premises Public facing server.
If you remember, Alice’s mailbox is hosted on the Exchange Online server.
The Exchange On-Premise relates to Alice’s mailbox as a “Remote mailbox”.
Because the Exchange on-Premises is to the “owner” of Alice’s mailbox, the Exchange on-Premises answer will include a redirection to the “real” Exchange infrastructure that host Alice’s mailbox meaning – Exchange Online infrastructure.
Exchange on-Premises “inform” the user (Alice) that is should perform the Autodiscover process using a new or, updated E-mail address.
In our scenario, the Exchange On-Premise informs Alice that her “real E-mail address” is – Alice@o365info2.onmicrosoft.com
Hybrid environment and Office 365 “Hybrid domain name”
Before we continue with the Autodiscover process description, it’s important to understand the concept of the E-mail address in a Hybrid environment.
In our specific scenario, the SMTP domain name space that is used for “representing” Exchange Online recipients is – o365info2.mail.onmicrosoft.com
This “domain name” is not a real domain name that will be used for Autodiscover process, but instead, just a “logical pointer” that will “lead” Exchange Online recipients to the Exchange Online Autodiscover infrastructure.
When the Autodiscover client tries to look for a hosted named – o365info2.onmicrosoft.com, the process will fail, because the host name is not supposed to be published.
In the following diagram, we can see that the Exchange on-Premises Autodiscover response includes a redirection message.
The Exchange on-Premises inform Alice that her “real” E-mail address is-
Alice@o365info2.mail.onmicrosoft.com
Step 11/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 addresses the Autodiscover Endpoint asking for Autodiscover information.
- The Autodiscover Endpoint response includes a redirection message that includes “another” E-mail address.
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.o365info.com:443/Autodiscover/Autodiscover.xml for user alice@o365info.com. The Autodiscover XML response was successfully retrieved.
Autodiscover Domain Redirection
<Action>redirectAddr</Action>
<RedirectAddr>Alice@o365info2.mail.onmicrosoft.com</RedirectAddr>
Step 12/30: Attempting to resolve the host name o365info2.mail.onmicrosoft.com
Now, the Autodiscover flow is “moved” from the Exchange On-Premise environment into the “cloud environment” (Office 365 and Exchange Online).
The Autodiscover client “understand” that he needs to restart the Autodiscover process all over again. The Autodiscover process will be based on the “new E-mail Address” that was delivered to Alice – Alice@o365info2.mail.onmicrosoft.com
As we already know, the Autodiscover client will “extract” the “right part” of the recipient
E-mail address in try to start a DNS query looking for this host name.
The Autodiscover client will address a DNS server, looking for the IP address of the host named – o365info2.mail.onmicrosoft.com
The request for information will fail because, in reality, there is no such host.
Step 12/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 addresses the DNS server looking for The IP address of the host – mail.onmicrosoft.com
- The DNS answer is that he doesn’t have any information about the specific host name.
Attempting to resolve the host name o365info2.mail.onmicrosoft.com in DNS. The host name couldn’t be resolved. Host o365info2.mail.onmicrosoft.com couldn’t be resolved in DNS InfoNoRecords.
Step 13/30: Attempting to resolve the host name autodiscover.o365info2.mail.onmicrosoft.com
In case that the Autodiscover client cannot find his Autodiscover Endpoint using the “domain naming convention”, the Autodiscover client will try to look for the Autodiscover Endpoint using the FQDN using the following naming scheme – Autodiscover +<E-mail SMTP domain name>
In our scenario, the result of this “formula” is a named host-
autodiscover.o365info2.mail.onmicrosoft.com
The Autodiscover client will address a DNS server, looking for the IP address of the host named –autodiscover.o365info2.mail.onmicrosoft.com
The DNS Server “answer”, include a list of IP addresses. The reason for the “multiple IP address” is that in Office 365 we use a “logical host name” that in the reality, can be “mapped to” many physical servers.
Step 13/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following information:
The DNS reply includes a list of IP addresses that are “mapped” to the host named – autodiscover.o365info2.mail.onmicrosoft.com
Attempting to resolve the host name autodiscover.o365info2.mail.onmicrosoft.com in DNS. The host name resolved successfully. IP addresses returned: 157.56.244.217, 157.56.236.89, 157.56.232.9, 157.56.234.137
Step 14/30: Testing TCP port 443 on host autodiscover.o365info2.mail.onmicrosoft.com to ensure it’s listening and open
Autodiscover client, try to verify if he can continue the Autodiscover process with the host- autodiscover.o365info2.mail.onmicrosoft.com by checking if the destination host can communicate using HTTPS protocol.
The result of the “HTTPS test” is -failure.
This is an expected result, because the host autodiscover.o365info2.mail.onmicrosoft.com, is not a “real” Exchange server.
Step 14/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 check if the host – autodiscover.o365info2.mail.onmicrosoft.com can communicate using the HTTPS protocol. The result is that the specific host doesn’t listen to port 443 (the default HTTPS protocol).
Testing TCP port 443 on host autodiscover.o365info2.mail.onmicrosoft.com to ensure it’s listening and open. The specified port is either blocked, not listening, or not producing the expected response. Network error occurred while communicating with the remote host.
Step 15/30: Attempting to contact the Autodiscover service using the HTTP redirect method
The Autodiscover client algorithm is based on the following concept – in case that the Potential Autodiscover Endpoint cannot respond to an HTTPS request, the Autodiscover client is not willing to “surrender” and instead to give up; the Autodiscover client will try another method in which his address the Potential Autodiscover Endpoint using the HTTP protocol asking for instructions for- “How to get to his Autodiscover Endpoint”.
The Autodiscover client checks if the host autodiscover.o365info2.mail.onmicrosoft.com, can communicate using the HTTP protocol.
Step 15/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 check if the host – autodiscover.o365info2.mail.onmicrosoft.com can communicate using the HTTP protocol. The result is that the specific host listen to port 80 (the default HTTP protocol).
Testing TCP port 80 on host autodiscover.o365info2.mail.onmicrosoft.com to ensure it’s listening and open. The port was opened successfully.
The continuation of the Autodiscover flow in an Exchange hybrid environment appears in the next article – Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36
Exchange Autodiscover | Article series index
We really want to know what you think about the article
The post Autodiscover flow in an Exchange Hybrid environment | Part 2#3 | Part 33#36 appeared first on o365info.com.