autodiscover flow in an exchange on-premises | non-active directory | part 2#3 | part 27#36

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

Directory environment| Part 2#3 | Part 27#36

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

Autodiscover flow in an Exchange on-

Premises environment | non-Active

Directory environment| Part 2#3 | Part

27#36

The current article and the next article, will be dedicated for detailed review of the

Autodiscover flow, that is implemented in an Autodiscover flow in an Exchange on-

Premises 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

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

The additional articles in the series are:

http://o365info.com/autodiscover-flow-in-an-exchange-on-premises-environment-non-active-directory-environment-part-2-of-3-part-27-of-36


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/

http://o365info.com/autodiscover-flow-in-an-exchange-on-premises-environment-non-active-directory-environment-part-3-of-3-part-28-of-36/




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


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


Note – you can read more information about how to use the Microsoft Remote

Connectivity Analyzer (ExRCA) tool in the article – Microsoft Remote Connectivity

Analyzer (ExRCA) | Autodiscover troubleshooting tools | Part 2#4 | Part 22#36

The essence of the Autodiscover journey

The main purpose of the “Autodiscover journey” that is implemented by the

Autodiscover client is to find his Autodiscover Endpoint.









http://o365info.com/microsoft-remote-connectivity-analyzer-exrca-autodiscover-troubleshooting-tools-part-2-of-4-part-22-of-36

http://o365info.com/microsoft-remote-connectivity-analyzer-exrca-autodiscover-troubleshooting-tools-part-2-of-4-part-22-of-36




Technically speaking, there are many types of scenario in which the Autodiscover

client will initialize the Autodiscover process and different type of Autodiscover

clients.

For this reason, we will need to focus on specific examples of the variety of possible

scenarios.

To demonstrate the process of Autodiscover in a non-Active Directory environment,

we will review the scenario of a client that needs to create a new Outlook mail

profile, in an environment that described as non-Active Directory environment.








In the following diagram, we can see the flow of the Autodiscover algorithm which

the Autodiscover client is “programmed” to use.

Do you get the feeling that the diagram is complicated and, by looking at the

diagram you start to feel a slight headache?

Well, I agree, but at the same time, I must inform you that this is a “minimized

version” of the Autodiscover workflow.

When drowning the diagram, I have dropped many “parts” such as the mutual

authentication process and other parts for making the diagram more digestible.

For example, regarding the security mechanism that is implemented as part of the

Autodiscover process, the Autodiscover flow description that will be provided in the

next section includes a very general reference to the security flaw that is

implemented.








If you want to read more detailed information about the subject of security in

Autodiscover environment, read the article – Autodiscover process and Exchange

security infrastructure | Part 20#36

Autodiscover workflow into a non-Active Directory

environment | Optional scenarios

To demonstrate some of the optional Autodiscover scenarios in a non-Active

Directory environment, let’s use the following organization infrastructure:

The public domain name of the organization is – o365info.com

The company has a public website that is published using the host name

– o365info.com

An external user named Bob that has the E-mail address – [email protected] ,

needs to create a new Outlook mail profile for connecting to his mailbox that is

hosted on Exchange On-Premise server.

Note – the Autodiscover method that will be implemented cannot be based on the

Active Directory Autodiscover method because the Autodiscover client is located on

external\public network, and he doesn’t have access to the organization Active

Directory.





http://o365info.com/autodiscover-process-and-exchange-security-infrastructure-part-20-of-36

http://o365info.com/autodiscover-process-and-exchange-security-infrastructure-part-20-of-36




Scenario 1: company website that uses the public domain name | no

HTTPS support

The Autodiscover client (Outlook in our scenario) will take the “right part” of the

recipient’s email address and will relate to the SMTP domain name as the host

name of a Potential Autodiscover Endpoint.

Autodiscover client will contact a DNS server and query the DNS about an IP

address of a host named – o365info.com

In our scenario, the DNS has an IP that is “mapped” to this hostname.








Note that this IP address, will point to the company’s public website that is not an

Autodiscover Endpoint but the Autodiscover client doesn’t know it!

The Autodiscover client uses that IP address that he gets from the DNS server and

tries to check if the Potential Autodiscover Endpoint support communication using

the HTTPS protocol.

In this specific scenario, the company web site doesn’t support HTTPS (doesn’t have

a public certificate).

When the HTTPS communication test with the host o365info.com host fails, the

Autodiscover Client “understand” that he will need to “move on” to the additional

Autodiscover method.








The Autodiscover client starts a new session, but this time; the Autodiscover client

will now try to look for a Potential Autodiscover Endpoint using the host name

– autodiscover.o365info.com

In our scenario, an A record was created using the hostname- Autodiscover and the

IP address that is mapped to this hostname point to the Exchange On-Premise

server.

Autodiscover client checks if the host- autodiscover.o365info.com support HTTPS.

The Autodiscover Endpoint (Public facing Exchange CAS server) approves that he

can communicate using the HTTPS protocol.

The Autodiscover client will ask from the Autodiscover Endpoint (Public facing

Exchange CAS server) to prove his identity, by providing a public certificate.

In case that the server certificate was successfully verified, the Autodiscover client

will send his user credentials to the Autodiscover Endpoint.








The last step is the step in which the Autodiscover client asks from the Autodiscover

Endpoint the required Autodiscover information for building a new Outlook

Anywhere profile.

Scenario 2: company website that uses the public domain name | HTTPS

support

The following scenario is a little confusing because, this time we deal with a public

website that is mapped to the “root domain name” + support HTTPS.

This scenario will cause the Autodiscover client to “believe” that he had found his

Autodiscover Endpoint but in the reality, the host that he tries to communicate

with, is not the required host.

Autodiscover client will contact the DNS server looking for the hostname

– o365info.com








After he gets the IP address, the Autodiscover client tries to check if the host (the

Potential Autodiscover Endpoint) supports HTTPS communication.

In our scenario, the company website supports HTTPS communication and has a

public certificate.

The basic assumption of the Autodiscover Endpoint is that this is the “right host”

and now; the Autodiscover client will generate a request for Autodiscover

information.

The request will be accepted by the host- o365info.com but this host is not an

Autodiscover Endpoint, and he doesn’t “understand” the meaning of – “request for

Autodiscover information”.

The Autodiscover client understands that he tries to communicate with the “wrong

host” and the next step is – moving forward the next Autodiscover methods in

which the Autodiscover client will try to look for the Autodiscover Endpoint using a

different host name –autodiscover.o365info.com








Scenario 3: HTTP redirection

In this scenario, we will “deviate” from our original scenario that is based on

Exchange On-Premise infrastructure in favor of a scenario that is common in an

environment such as Office 365 and Exchange Online.

In this scenario, the user mailbox is hosted on the Exchange Online server.

The cloud infrastructure, doesn’t really publish hostnames using the “supposed

naming convention” but instead, when the Autodiscover client “think” that he got

his Potential Autodiscover Endpoint, the host redirects him to the Office 365

Autodiscover infrastructure for continuation of the Autodiscover process.

In the following diagram, we can see that the Autodiscover client gets from the DNS

server the IP address of – autodiscover.o365info.com

When he tries to check if the Potential Autodiscover Endpoint

(autodiscover.o365info.com) support HTTPS connections, he gets a negative

response.








The Autodiscover client will “move on” to the next Autodiscover method in which he

tries to ask from the Potential Autodiscover Endpoint information about a “new

name” of Autodiscover Endpoint.

This method described as an HTTP redirection because the host redirects the

Autodiscover client to “additional Potential Autodiscover Endpoint”








In the following diagram, we can see that the Autodiscover client addresses the

host-autodiscover.o365info.com using the HTTP protocol instead using the standard

HTTPS protocol.

Because the Office 365 host is “aware” to the process in which he needs to redirect

the Autodiscover client to other Potential Autodiscover Endpoint, the Office 365

host send the hostname- autodiscover.outlook.com in the redirection response.

Autodiscover client will try now to communicate with the “new Autodiscover

Endpoint named-Autodiscover-s.outlook.com using the HTTPS protocol (I have

dropped the DNS name resolution process).

In the Office 365 environment the Autodiscover flow, will not end at this point, but

for the time being, I will end our scenario in this phase.








The Autodiscover client verifies if the “new Autodiscover Endpoint” can

communicate using HTTPS and if the answer is “yes”, the Autodiscover process will

continue from this point.

Scenario 4: looking for an Autodiscover SRV record

The following scenario, describe a special Autodiscover method that is based on a

special DNS record, the SRV record.

The use of the SRV Autodiscover method enables to implement the Autodiscover

method in a non-Active Directory environment that is very similar to the

Autodiscover method in an Active Directory environment.

Until now, the Autodiscover method that the Autodiscover client use, was based on

a method in which the Autodiscover client “generate” or guess the Autodiscover

Endpoint name by using the “right part” from the recipient E-mail address (the

SMTP domain name).

In a scenario in which a specific organization owns multiple public domains, the IT

needs to configure the required DNS record for each of the domains and in








addition, add the name of the Autodiscover host for each of the domains to the

server public certificate.

Using the option of the SRV record, unable to “point” mail client that uses a

different SMTP domain name to a – “single point of authority” meaning, an

Autodiscover Endpoint that can serve the different client.

For example, the DNS SRV record can point a recipient from the domain

– o365info.com + the domain o365info.org to the one Autodiscover Endpoint named

– mail3.otherdomain.com

It’s important to emphasize that the SRV Autodiscover method is the “last

Autodiscover method on the list”.

Only if the Autodiscover client drains out all the Autodiscover methods, which we

review in the former scenarios, only, then he will try to use the SRV Autodiscover

method.

There could be a couple of scenarios, which will “lead” the Autodiscover client to

use the SRV Autodiscover method.

In this scenario, the Autodiscover client tries to query the DNS server for the IP

address of the hosts – o365info.com and autodiscover.o365info.com

The A record for this host was not added to the DNS deliberately.

The intention was to “enforce” the Autodiscover client to “fail back” to the SRV

Autodiscover method.

The next step of the Autodiscover client is – to query the DNS for an Autodiscover

SRV record.

In our example, the SRV record was a created and was configured with the host

named –mail3.otherdomain.com

The Autodiscover client will try to get the IP address of the host

– mail3.otherdomain.com

When the Autodiscover finds the host, he will try to verify that the host can

communicate using HTTPS and so on.








Another passable scenario is a scenario in which the Autodiscover client finds

information about a Potential Autodiscover Endpoint

named- autodiscover.o365info.com

The “problem” is that this host doesn’t respond to an HTTPS communication

request and additionally, cannot relate to the HTTP redirection request of the

Autodiscover client.








In this case, the Autodiscover client will “revert” to the Autodiscover method of

trying to query the DNS server about an SRV record.





autodiscover flow in an exchange on-premises | non-active directory | part 2#3 | part 27#36

Documents