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

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

Directory environment| Part 1#3 | Part 26#36

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

Autodiscover flow in an Exchange on-

Premises environment | non-Active

Directory environment| Part 1#3 | Part

26#36

The Autodiscover protocol for discovering the Autodiscover Endpoint is a very

smart protocol, which was designed to get the required results in a different

environment such as Active Directory-based environment and a “non-Active

Directory environment”.

In a “non-Active Directory environment”, the Autodiscover client has an arsenal of

methods and tools, which can help him to find his Autodiscover Endpoint.

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


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

http://o365info.com/




Autodiscover flow in an Exchange on-Premises environment |

non-Active Directory environment | The article series

The current article is the first article on a series of three articles.

The main focus of the first article is -presenting the logic and, the involved

components in the Autodiscover flow that is implemented in Exchange on-Premises

environment.

In the next two articles, we will review the Autodiscover flow that is implemented in

Exchange on-Premises environment, by using the Microsoft web-based tool, the

Microsoft Remote Connectivity Analyzer (ExRCA).

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


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













Locating the Autodiscover Endpoint host | Active

Directory versus none- Active Directory environment

Before we get into the details of the Autodiscover process that is implemented in a

non-Active Directory environment, it’s important to understand the major

difference of the Autodiscover method that is performed on each of these

environments.

In an Active Directory environment, the Autodiscover client doesn’t know the name

of the Autodiscover Endpoint and instead, relate to the Active Directory as a trusted

source of infrastructure that can provide him the “names” of available Autodiscover

Endpoints (Exchange CAS servers).

In a non-Active Directory environment, the “missing part” is the Active Directory.

Instead of addressing the Active Directory for information about the name\s of the

Autodiscover Endpoint, the Autodiscover client will need to use another method.

The Autodiscover method that is used by the Autodiscover client is based on a

following flow:

1. The Autodiscover Endpoint “guess” or “generate” the URL address of a potential

Autodiscover Endpoint based on the SMTP domain that he gets from the recipient

E-mail address.

2. In case that the Autodiscover client manage to locate and communicate with the

“Potential Autodiscover Endpoint” but the “destination host” cannot provide him the

required information, the Autodiscover client will ask for a redirection to another

potential Autodiscover Endpoint.

Note – we use the term “Potential Autodiscover Endpoint” because when the

Autodiscover client addresses a specific host as “Autodiscover Endpoint” he

assumes that the destination host is an Autodiscover Endpoint, but he cannot be

sure of the destination host is indeed Autodiscover Endpoint.

3. In case that the potential Autodiscover Endpoint from “step 1” could not provide

the required Autodiscover information + couldn’t provide a redirection to a








potential Autodiscover Endpoint, the Autodiscover client will try to query the DNS

looking for SRV record that will include the host name of a potential Autodiscover

Endpoint.

Pay attention to the fact the in a non-Active Directory environment, the

Autodiscover client can consider as “blind client” because, there is no “formal

source of information” that can provide him the specific host name (the URL if we

want to be more accurate”) of the potential Autodiscover Endpoint.








The possible scenario in which Autodiscover client

cannot use the Active Directory Autodiscover method.

The four possible scenarios in which client cannot use the Autodiscover method

that is based on an LDAP query and On-Premises Active Directory are:

1. The desktop is not a Domain joined

As the name implies, this scenario can relate to one of the following options:

A user’s desktop that is not configured as a domain member (domain joined)

A user’s desktop that is configured as a domain member (domain joined) but the

user login locally to his desktop and not to the “Domain profile”.

2. The desktop is a Domain joined but, there is no option to communicate

with Active Directory

An example could be a user whom his notebook, consider as a Domain joined, but

the organization user is working from home or a public network.








In that case, despite the fact that the desktop is a “Domain joined”, the

communication attempt to the Active Directory will fail because by default, the

Active Directory considers as protected or internal resources, and it’s not exposed

to access by the host from the public network.

3. The desktop is a Domain joined, there is an option to communicate with

Active Directory but the SMTP Domain that the client look for doesn’t

“belong” to the Exchange on-Premises server (the Exchange is not

authoritative for the specific domain name).

Whoa!! This is a very long name for a scenario title!

An example of this scenario could be a user who wants to create a new Outlook

mail profile using a recipient E-mail address.

The SMTP domain part of the recipient E-mail address doesn’t “belong” to the

organization Domains (Domain that Exchange sees himself as authoritative for

them).

In that situation, although the domain is not part of the local Exchange

infrastructure, the Autodiscover client will request a list of available Exchange CAS

server from the Active Directory and try to communicate with each of the Exchange

CAS servers in the list looking for the required Autodiscover information.

Only after the Autodiscover client exhausts all the possible “internal Autodiscover

Endpoints”, the Autodiscover client will “surrendered” and start to use an additional

Autodiscover method.

4. An Exchange on-Premises server is not available.

The charters of this scenario are:

The user desktop is a Domain joined.

The Autodiscover client manages to query the local Active Directory and gets a

list of potential Autodiscover Endpoints.

The Autodiscover client tries to communicate the Autodiscover Endpoint

(Exchange CAS server) but the Exchange CAS server is not available (not

responding, etc.).








In this case, the Autodiscover client will “surrendered” and start to use an additional

Autodiscover method.

The journey for the Lost Treasure- Autodiscover.xml file

To simplify the concept of Autodiscover process, let’s use the following metaphor:

The process of Autodiscover is very similar to a “the search for the lost treasure”.

We heard from someone, about very precious treasure.

We want this treasure very much, and we know that “somewhere” there is a person

that holds this precious treasure.

All we need is a “map” that could lead us to the person that hold our precious

treasure!








Let’s return to the “real world” and try to understand what process each of this

Imaginary figure represent.

1. The “searcher”

The “searcher” could be any Autodiscover client. In our scenario, the Autodiscover

client is Outlook that needs configuration setting for creating a new Outlook mail

profile.

2. The lost treasure – Autodiscover information

The assent of “Autodiscover journey” is very simple – find the Autodiscover

information (the lost treasure).








3. The “source”

The “element” that holds our precious treasure is the Exchange CAS server or if we

want to use the formal term – potential Autodiscover Endpoint.

Technically speaking, we use the term “potential” because, in reality, when the

Autodiscover client addresses a specific host he doesn’t know if the host (the

potential Autodiscover Endpoint) replies to his communication request or, in case

that the host reply, we cannot be sure that the specific host is the “right one”.

For this reason, we use the term “potential” because the host the Autodiscover

client address has the potential to be the “right Autodiscover Endpoint” but, at the

same time, the Autodiscover client will need to know how to deal with a scenario in

which the host is not the “right Autodiscover Endpoint”.








4. The “Map”

In our story, the “map” should lead us to the person that hold our desirable

treasure.

In the Autodiscover world, the “map” is implemented as a web address (URL).

If we want to be more precise, the client (Outlook) has already most of the map, the

only missing part in the “map” is the name of the Autodiscover Endpoint who “hold”

the information (hold our precious treasure).

Autodiscover URL (the map to the lost treasure)








Continuing our metaphor, the” map” (the address) to the lost treasure, aka the

Autodiscover information is implemented by using a URL address.

Let’s look at the structure of the Autodiscover URL address, so we can understand

better the Autodiscover method that is used by the Autodiscover client in a non-

Active Directory environment.

The Autodiscover URL address, includes the following parts:

The protocol name (HTTPS or HTTP)

The host name of the Autodiscover Endpoint

The path that includes the name of the folder (Autodiscover) and the name of

the required file (autodiscover.xml or autodiscover.svc)

Autodiscover client knows what is the URL address structure that he should use for

addressing the Autodiscover Endpoint.

The default communication protocol is HTTPS (another option is HTTP in a scenario

of a redirection requests).

Note that the name of the FQDN of the Autodiscover Endpoint is not known to the

Autodiscover client!

In the next section, we will learn how the Autodiscover client solves this problem,

but it’s important to emphasize that in a non-Active Directory environment the

Autodiscover client cannot know “in advance” the host name if the Autodiscover

Endpoint.

The default path of the Autodiscover URL is based on the following naming

convention.

<Folder name><File name>

The default path of Autodiscover services is:

/Autodiscover/autodiscover.xml








In the following diagram, we can see the presentation of the “well know the

Autodiscover URL address” concept.

The Autodiscover client, “knows” most of the “parts” of the Autodiscover URL

address.

The only “missing part” is the host name of the Autodiscover Endpoint.








The great mystery revealed! Generating the

Autodiscover Endpoint host name

When an Autodiscover client uses the “Active Directory Autodiscover method”, the

Autodiscover client, trust or relies on the Active Directory as a source for

information about the available Autodiscover Endpoint.

But in case that the Autodiscover client cannot use the Active Directory as a “source

for information”, how can the Autodiscover client know what the name of

Autodiscover Endpoint is? Is there more than one potential Autodiscover Endpoint?








I’m excited!

Today we are going to reveal the big secret which only a few people in the whole

world know!

The way that the Autodiscover client use for “finding” the host name of the

Autodiscover Endpoint is maybe not the “big secret which only a few people in the








whole world know!” however, it’s still an interesting process that some of us are not

familiar with.

The mission is – creating a new Outlook mail profile.

The agent name is – Bob

The location – Bob is located on a public network and for this reason, he

cannot access the organization Active Directory.

The obstacles – how to find the Exchange CAS server (the Autodiscover

Endpoint) that will enable Bob to connect to his mailbox + provides all the

required information for creating the Outlook Anywhere mail profile.








The secret method which the Autodiscover client use is based on a little trick.

As mentioned before, the URL address of the Autodiscover Endpoint is based on a

predefined naming convention.

For the Autodiscover client which needs to find his Autodiscover Endpoint, the only

missing part is the host name of the Autodiscover Endpoint.

The trick that the Autodiscover client use is based on the E-mail address of the

recipient. Every standard E-mail address is consisted of two parts:

1. The “left part” this is the recipient alias or the recipient name.

2. The “Left part”, this part represents the domain name or the SMTP domain

name of the organization of the company that the user belongs to.

Autodiscover clients know how to use the “right part” of the E-mail address by

“taking” the SMTP domain name and is it for “Fill in the missing part of the puzzle”.

In our scenario, when Bob starts the Outlook wizard, Bob will have to provide his E-

mail address – [email protected]

The Autodiscover client (Outlook), take the domain name form the E-mail address

and “put the name” in the Autodiscover URL.








In our example, Outlook will start the journey by connecting DNS server and ask for

the IP address of the host named – o365info.com

In case that the DNS server can provide an IP address, Outlook (Autodiscover client)

will relate to the host as a potential Autodiscover Endpoint.

The basic Outlook assumption is that this host – o365info.com is a potential

Autodiscover Endpoint meaning an Exchange CAS server or element that can

provide him the required Autodiscover information for creating the Outlook

Anywhere mail profile.








Most of the time, the method in which Autodiscover relates to the SMTP domain

name is the host name of the potential Autodiscover Endpoint will not yield the

required results because in a modern environment, the “root domain name” is

usefully mapped to the public company web site.

In now days, we can “reach” most of the public web site without using the formal

naming convention such as – www.<Domain name> but instead, we use only the

domain name.

Let’s assume that in our scenario, Outlook manage to find the IP address of a host

named –o365info.com, but “this host” is not the required Autodiscover Endpoint

(Exchange CAS server) but instead, just a simple website.

In that situation, the Autodiscover client uses an additional naming convention, but

this time; Outlook will try to address the Autodiscover Endpoint by using the

following hostname –autodiscover.o365info.com

The host name – Autodiscover is a preserved name.

Each organization that wants to point Autodiscover clients to their Autodiscover

Endpoint, need to create under the domain name in the DNS zone an A record, that








includes the host name – Autodiscover and mapped to the IP address of the

Exchange CAS server who operate as Autodiscover Endpoint.

Q: Is this is the end of the Autodiscover journey? Can we assume that the story has

a good end?

A: Yes and no








This could be the end of the Autodiscover journey in case that the host –

autodiscover.o365info.com is the “real deal” and this is the “right Exchange CAS

server” that can enable the Outlook to connect to user mailbox + provide all the

required configuration settings for building a new Outlook Anywhere mail profile.

Other passable scenarios is that the host the Outlook considers as a “potential

Autodiscover Endpoint”, is not the host who can “end the process”.

For example, there is an option in which Outlook finds the IP address of a host

named-autodiscover.o365info.com but the “host” doesn’t respond to the HTTPS

request that Outlook sends. (The Autodiscover process is based on the HTTPS

protocol).

In this case Outlook “understand” that this is not the “the last station” in his

Autodiscover journey.

In case that the Autodiscover Endpoint did not respond to the HTTPS

communication request, the Autodiscover client still has “some belief” that the host

can still help him in another way.

HTTP Redirection

Because of the destination, host doesn’t support HTTPS communication, the

Autodiscover client “understand” that this is not the element that can provide him

the require Autodiscover information.

Instead of “give in”, Outlook client will address that host who doesn’t support

HTTPS, and ask him if he knows about a Potential Autodiscover Endpoint.

The Autodiscover Endpoint addresses the host by using HTTP protocol instead of

HTTPS.








In case that the host responds to the HTTP request, the Autodiscover client

assumes that he can ask for help.

The Autodiscover client will try to request from the host, information about the

name if the Autodiscover Endpoint.








So… is this is the end?

The answer is not it!

In case that the host whom the Autodiscover client address doesn’t support HTTP

or cannot provide the name of a potential Autodiscover Endpoint, the Autodiscover

client will use the “last method, he carries his sack”

This Autodiscover method is based on a special DNS record named – SRV record.

The uniqueness of a DNS SRV record is that this type of record enables DNS client

to query DNS about the host name to provide a specific service with Outlook the

need to know the host name. In other words, when using the SRV query, looking for

a specific service, the DNS replay with the host name\s that provide the specific

service.

In case that the organization publishes in the DNS an SRV record that includes the

host name of the Exchange CAS server (Autodiscover Endpoint) that can provide

Autodiscover services, the Autodiscover client will use the name and relate to the

host as a potential Autodiscover Endpoint.








Note – it’s important to mention that the SRV Autodiscover method is not

supported in Office 365 and Exchange Online environment.





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

Documents

Transcript of Autodiscover flow Exchange on-Premises environment | non-Active Directory | Part 1#3 | Part 26#36