Professional Documents
Culture Documents
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 onPremises environment | non-Active Directory environment, by using the Microsoft
web-based tool, the Microsoft Remote Connectivity Analyzer (ExRCA).
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
Note that this IP address, will point to the companys public website that is not an
Autodiscover Endpoint but the Autodiscover client doesnt 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 doesnt support HTTPS (doesnt 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 doesnt 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
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.
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
Its 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.
In this case, the Autodiscover client will revert to the Autodiscover method of
trying to query the DNS server about an SRV record.