Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 3#3 | Part 28#36 5/5 (1)

14 min read

The current article is the continuation of the previous article, in which we review the Autodiscover flow that implemented in Autodiscover flow in a non-Active Directory environment.
In this article, we will inspect the Autodiscover flow by using the Microsoft web-based tool, the Microsoft Remote Connectivity Analyzer (ExRCA).

Autodiscover flow in non-Active Directory environment| Article Series

The Autodiscover flow in non-Active Directory environmentarticle series, including the following three articles:


Article Series Table of content | Click to expand

Exchange and Autodiscover infrastructure | Article Series

Exchange Autodiscover – Article series – INDEX

Exchange and Autodiscover infrastructure | The building blocks

Autodiscover infrastructure | FQDN and URL address

Exchange Autodiscover flow in different environments

Autodiscover infrastructure | Exchange infrastructure and namespace convention

Exchange, Autodiscover and security infrastructure

Autodiscover Troubleshooting tools

Autodiscover major flow scenarios

Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment

Autodiscover flow in an Office 365 based environment

Autodiscover flow in an Exchange Hybrid environment

Exchange Stage migration and Autodiscover infrastructure

To be able to review each of the steps and each of the parts that include a particular Autodiscover step, we will use the powerful tool- the Microsoft remote connectivity analyzer.

The Microsoft remote connectivity analyzer includes many tabs and options. In our specific scenario, we want to test Exchange on-Premises infrastructure. To be able to implement the required test, we will choose the Exchange server tab, Microsoft Office Outlook Connectivity test and then, the option of – Outlook Autodiscover.

Exchange remote connectivity analyzer – Outlook Autodiscover test

Note – in case that you need to get more details about the Microsoft remote connectivity analyzer web tool you can read the article –Microsoft Remote Connectivity Analyzer (ExRCA) | Autodiscover troubleshooting tools | Part 2#4 | Part 22#36

Scenario description

To demonstrate the Autodiscover workflow that is implemented, in a “non-Active Directory environment” when using an Exchange on-Premises infrastructure, let’s use the following scenario:

John is an organization’s user who needs to access his mailbox that is hosted on the Exchange on-Premise server.

John is physically located on a public network and, for this reason, he cannot use the Autodiscover process that implemented in an Active Directory environment.

The John E-mail address is – john@o365info.com
John task is- creating a new Outlook mail profile that will enable him to connect his mailbox. The Outlook profile based on the Outlook Anywhere service.

Note that the company has a public website that is published using the host named- o365info.com

Autodiscover in non Active Directory environment - Exchange On-Premise environment - Scenario description

Analyzing the Autodiscover process by using ExRCA

Before we will “dive in” into the details let’s start from a High-level view of the Autodiscover test results.

In the following screenshot, we can see that the Autodiscover processes complete successfully.
By looking at the Autodiscover results reports structure, we can see that the “first part” failed (did not complete successfully) but the second part (B section) successfully completed.

Note – Autodiscover flow will “contain” a couple of “steps failure” 99% of times but, still ended as a successful process.

The second part (B section) includes the “high level” description of each of the five Autodiscover steps that were implemented and documented in the result report (we will review in details each of these steps in the next section).

Autodiscover process in Exchange on-Premises server environment 01

Analyzing the Autodiscover process | Steps described in details

Step 1/9: Attempting to resolve the host name o365info.com in DNS

By default, Autodiscover client will try to locate a “potential Autodiscover Endpoint”, by using a host name that 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 – john@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 particular organization public server’s and services infrastructure.

For example, most of the organizations have a public website and, most of the time, the public domain name is “mapped” to the public IP of the website.

In our scenario, the DNS 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 assigned to a standard web server.
Step 1 of 9 - resolve the host name o365info.com in DNS -01

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

In the ExRCA result page, we can see the following information:

The ExRCA tests results start with an error message that the connection attempt to the host named – o365info.com failed.

Attempting to test potential Autodiscover URL https://o365info.com:443/Autodiscover/Autodiscover.xml
Testing of this potential Autodiscover URL failed.

(We will get more details about the reason for the failure in the next section).

Note that when we look at the details of the workflow that was performed by the Autodiscover client, we can see that some of the steps to complete successfully.

For example, the resolution step in which the Autodiscover client asks for the DNS server the IP address of the host o365info.com complete successfully.

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 1 of 9 - resolve the host name o365info.com in DNS -02

Step 2/9: Testing TCP port 443 on host 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 is listing on port 443 (HTTPS).

In our scenario, the HTTPS communication test fails because the “destination host” doesn’t support HTTPS communication.

Step 2 of 9 - Testing TCP port 443 on host o365info.com -01

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

In the ExRCA result page, we can see the following information about the Testing TCP port 443 on host o365info.com:

The specified port is either blocked, not listening, or not producing the expected response. A network error occurred while communicating with the remote host.

Step 2 of 9 - Testing TCP port 443 on host o365info.com -02

Step 3/9: Attempting to resolve the host name autodiscover.o365info.com in DNS

Because the communication attempt with the potential Autodiscover Endpoint using the hostname o365info.com fails, Autodiscover client move 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 – john@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 – autodiscover.o365info.com

Step 3 of 9 - resolve the host name autodiscover.o365info.com in DNS -01

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

In the ExRCA result page, we can see the following information about the Attempting resolve the hostname o365info.com:

Attempting to resolve the host name autodiscover.o365info.com in DNS.
The host name resolved successfully. IP addresses returned: 212.25.80.239

Step 3 of 9 - resolve the host name autodiscover.o365info.com in DNS -02

Step 4/9: Testing TCP port 443 on host autodiscover.o365info.com to ensure it’s listening and open.

The Autodiscover client, address 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 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.

Step 4 of 9 - Testing TCP port 443 on host autodiscover.o365info.com -01

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

In the ExRCA result page, we can see the following information about the Testing TCP port 443 on host autodiscover.o365info.com :

Testing TCP port 443 on host autodiscover.o365info.com to ensure it’s listening and open. The port was opened successfully.

Step 4 of 9 - Testing TCP port 443 on host autodiscover.o365info.com -02

Step 5/9: Asking from the potential Autodiscover Endpoint to provide a public server certificate

The Autodiscover client “assume” that the destination host is a “potential Autodiscover Endpoint”, that can provide him the required Autodiscover information.

Before the Autodiscover client asks for the required information, he will have to a successfully complete couple of steps.

The Autodiscover client needs “to be sure” that the destination host is a reliable\trust wordy.

To be able to trust the potential Autodiscover Endpoint, the Autodiscover client will ask for the server to prove his identity by providing a valid public certificate.

Step 5 of 9 - Asking from the potential Autodiscover Endpoint to provide a public server certificate -01

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

In the ExRCA result page, we can see the following information about the step in which the Autodiscover client asks for the potential Autodiscover Endpoint to provide a server public certificate:

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.

Step 5 of 9 - Asking form the potential Autodiscover Endpoint to provide a public server certificate -02

Step 6/9: Testing the SSL certificate to make sure it’s valid

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

1. Validating the certificate name
The Autodiscover client addresses the potential Autodiscover Endpoint using the host name – autodiscover.o365info.com

To be able to know that this is the “real host”, Autodiscover client will check if the certificate includes the specified host name (autodiscover.o365info.com )

Note – this description is relevant to a scenario in which the server uses an SAN certificate.
In case that the potential Autodiscover Endpoint uses a wildcard certificate, the client will validate only the domain name (in our scenario, the domain name that the client will validate is – o365info.com).

2. Validating the certificate trusts
The public certificate that the server provides, created 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.

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

Step 6 of 9 - Testing the SSL certificate to make sure it's valid -01

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

1. Validating the certificate name

In the ExRCA result page, we can see the following information about the validation test for the Autodiscover Endpoint name:

The certificate name was validated successfully.
Host name autodiscover.o365info.com was found in the Certificate Subject Alternative Name entry.

Step 6 of 9 - Testing the SSL certificate to make sure it's valid -02

2. Validating the certificate trust

In the ExRCA result page, we can see the following information about the validation test for the certificate trust:

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=mail.o365info.com, OU=Domain Control Validated, O=mail.o365info.com.
One or more certificate chains were constructed successfully.

Step 6 of 9 - Testing the SSL certificate to make sure it's valid -03

3. Verify that the certificate date is valid

In the ExRCA result page, we can see the following information about the validation test for the certificate data:

Testing the certificate date to confirm the 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 6 of 9 - Testing the SSL certificate to make sure it's valid -04

Step 7/9: Checking the IIS configuration for client certificate authentication

The Autodiscover client checks 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 by providing a certificate.

The use of the client certificate is very rare and most of the time, the way that the client uses for “proof his identity” is by providing user credentials.

Step 7 of 9 - Checking the IIS configuration for client certificate authentication -01

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

On the ExRCA result page, we can see the following information about the client certificate authentication test:

Checking the IIS configuration for client certificate authentication. Client certificate authentication wasn’t detected. Accept/Require Client Certificates isn’t configured.

Step 7 of 9 - Checking the IIS configuration for client certificate authentication -02

Step 8/9: 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 user credentials” (Username + password).

Note – the part of “providing user credentials “doesn’t appear in the ExRCA results.

Step 8 of 9 - providing user credentials -01

Step 9/9: Attempting to send an Autodiscover POST request to potential Autodiscover URLs

This is the final step in the Autodiscover journey.

After a successful compilation of all the steps, the Autodiscover client completes his mission – getting the Autodiscover file.

The Autodiscover Endpoint will generate the Autodiscover response that was “customized” to the particular Autodiscover client that requires the information (John in our scenario).

Step 9 of 9 - Attempting to send an Autodiscover POST request to potential Autodiscover URLs -01

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

In the ExRCA result page, we can see the following information about the Autodiscover response that was sent by the Exchange CAS server to the client:

Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
The Microsoft Connectivity Analyzer successfully retrieved Autodiscover settings by sending an Autodiscover POST.

The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.o365info.com:443/Autodiscover/Autodiscover.xml for user john@o365info.com. The Autodiscover XML response was successfully retrieved.

The Autodiscover response included 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:

The Autodiscover Exchange provider

Exchange CAS server include a couple of Outlook providers.
The Autodiscover will include a dedicated section for each of this provider.

In our example, we took a screenshot from the part that include the information for the EXCH provider – <Type>EXCH</Type>

Note – If you need more detailed information about the Exchange CAS server Autodiscover provider read the article – The content of the Autodiscover server response | Part 11#36

In the following screenshot, we can see that the Autodiscover response includes the “private” or the “hidden name” of the Exchange CAS server that provide the Autodiscover services – <Server>EX01.o365info.local</Server>
The Autodiscover response, includes a detailed information about each of the available Exchange web services.

In the following example we can see the information about the available services: <ASUrl>https://ex01.o365info.local/ews/exchange.asmx</ASUrl>

And about the Automatic reply (Out of office) services: <OOFUrl>https://ex01.o365info.local/ews/exchange.asmx</OOFUrl>

Step 9 of 9 - Attempting to send an Autodiscover POST request to potential Autodiscover URLs -02

Now it’s Your Turn!
It is important for us to know your opinion on this article

Summary
Article Name
Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 3#3 | Part 28#36
Description
The current article is the continuation of the previous article, in which we review the Autodiscover flow that implemented in Autodiscover flow in a non-Active Directory environment. In this article, we will inspect the Autodiscover flow by using the Microsoft web-based tool, the Microsoft Remote Connectivity Analyzer (ExRCA).
Author
Publisher Name
o365info.com
Publisher Logo
Print Friendly

Related Post

Please rate this

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

Leave a Reply

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