Page 1 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

Autodiscover flow in an Exchange onPremises environment | non-Active

Directory environment| Part 3#3 | Part
28#36

The current article is the continuation of the previous article, in which we review the
Autodiscover flow that is implemented in Autodiscover flow in an Exchange onPremises environment | non-Active Directory environment, by using the Microsoft
web-based tool, the Microsoft Remote Connectivity Analyzer (ExRCA).

Autodiscover flow in an Exchange on-Premises environment |

non-Active Directory environment | The article series

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

Page 2 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

The current article is the third article in a series of three articles.

The additional articles in the series are:

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

Directory environment| Part 1#3 | Part 26#36
Autodiscover flow in an Exchange on-Premises environment | non-Active
Directory environment| Part 2#3 | Part 27#36

To be able to review each of the steps and each of the parts that include a specific
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.

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

Page 3 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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, lets
use the following scenario:

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

Page 4 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

John is an organizations 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 is 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 will be based on the Outlook Anywhere service.
Note that the company has a public website that is published using the host
named-o365info.com

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

Page 5 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

Analyzing the Autodiscover process by using ExRCA

Before we will dive in into the details lets 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) was
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).

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

Page 6 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

Analyzing the Autodiscover process | Steps described

in details

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

Page 7 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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 specific organization public servers
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 doesnt belong to an Exchange server
(Autodiscover Endpoint) but instead, this public IP address is assigned to a standard
web server.

Step 1/9: Analyzing the data from the ExRCA connectiv ity test
In the ExRCA result page, we can see the following information:

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

Page 8 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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 2/9: Testing TCP port 443 on host o365info.com to ensure

its 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
doesnt support HTTPS communication.

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

Page 9 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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

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

Page 10 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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/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 4/9: Testing TCP port 443 on host

autodiscover.o365info.com to ensure its 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).

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

Page 11 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

In our scenario, the HTTPS communication test succeeded, meaning that the
destination host (the Autodiscover Endpoint) supports HTTPS communication.

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 its listening and
open. The port was opened successfully.

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 will ask for the required information, he will have to
a successfully complete couple of steps.

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

Page 12 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

The Autodiscover client need 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/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 public server 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.

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

Page 13 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

Step 6/9: Testing the SSL certificate to make sure its 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 provide was created by a CA (certificate
authority).
The Autodiscover client will need also 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

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

Page 14 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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.

2. Validating the certificate trust

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

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

Page 15 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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.

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 hasnt expired.
The certificate is valid. NotBefore = 1/26/2013 11:22:11 PM, NotAfter = 1/26/2015
11:22:11 PM

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.

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

Page 16 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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

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 wasnt detected. Accept/Require Client Certificates isnt configured.

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.

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

Page 17 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

The Autodiscover client will identify himself by providing user credentials

(Username + password).
Note the part of providing user credentials doesnt appear in the ExRCA results.

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 specific Autodiscover client that requires the information (John
in our scenario).

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

Page 18 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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

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

Page 19 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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>

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

Page 20 of 20 | Autodiscover flow in an Exchange on-Premises environment | non-Active

Directory environment| Part 3#3 | Part 28#36

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