in a “non-Active Directory environment.”
The Autodiscover Toolbox offers a verity of methods which the Autodiscover client can use when he tries to locate his Autodiscover Endpoint.
Autodiscover flow in non-Active Directory environment| Article Series
The Autodiscover flow in non-Active Directory environmentarticle series, including the following three articles:
- 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
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 3#3 | Part 28#36
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
- Exchange Autodiscover infrastructure – Introduction | Part 01#36
- The old Exchange environment versus “modern” Exchange environment | Part 02#36
- Who are the Exchange Autodiscover clients? | Part 03#36
- The Autodiscover information | Part 04#36
- The Autodiscover algorithm for locating the “source of information” | Part 05#36
- Exchange CAS server | Providing Exchange clients access to their mailbox | Part 06#36
- Exchange CAS server as information + Web service provider | Part 07#36
- The dual identity of the Exchange server | Part 08#36
Autodiscover infrastructure | FQDN and URL address
- The basics of Domain name, FQDN and URL address | Exchange infrastructure |Part 09#36
- Exchange Web services | Manage the Internal and external URL address | Part 10#36
Exchange Autodiscover flow in different environments
- The content of the Autodiscover server response | Part 11#36
- Outlook client protocol connectivity flow in an internal network environment | Part 12#36
- Exchange clients and their Public facing Exchange server | Part 13#36
- Outlook Autodiscover decision process | Choosing the right Autodiscover method | Part 14#36
- Autodiscover flow in Active Directory based environment | Part 15#36
- Autodiscover scenarios in enterprise environment | Part 16#36
Autodiscover infrastructure | Exchange infrastructure and namespace convention
- Should I use a single namespace for Exchange Infrastructure? | Part 1#2 | Part 17#36
- Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36
- Public SAN certificate | Deprecated support in the internal server name | Part 19#36
Exchange, Autodiscover and security infrastructure
Autodiscover Troubleshooting tools
- Outlook Test E-mail AutoConfiguration | Autodiscover troubleshooting tools | Part 1#4 | Part 21#36
- Microsoft Remote Connectivity Analyzer (ExRCA) | Autodiscover troubleshooting tools | Part 2#4 | Part 22#36
- Microsoft Connectivity Analyzer (MCA) | Autodiscover troubleshooting tools | Part 3#4 | Part 23#36
- Using Fiddler for Autodiscover troubleshooting scenarios | Part 4#4 | Part 24#36
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 Office 365 environment | Part 1#3 | Part 29#36
- Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36
- Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36
Autodiscover flow in an Exchange Hybrid environment
- Autodiscover flow in an Exchange Hybrid environment | Part 1#3 | Part 32#36
- Autodiscover flow in an Exchange Hybrid environment | Part 2#3 | Part 33#36
- Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36
Exchange Stage migration and Autodiscover infrastructure
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.
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 situation of a client that needs to create a new Outlook mail profile, in an environment that described as non-Active Directory environment.
- By default, the Autodiscover client will try to locate his Autodiscover Endpoint by query the DNS for a specific host name (root domain) that he gets from the recipient E-mail address.
- In case that the Autodiscover client doesn’t manage to complete the process with the host, he will try to use a different hostname using the naming convention Autodiscover + domain name.
- In case that the Autodiscover client doesn’t manage to complete the process with the host, he will try to ask for a “redirection” instruction to the required host.
- In case that the Autodiscover client doesn’t manage to complete the process with the host, he will query the DNS server looking for an SRV record that includes the host name of the required Autodiscover Endpoint.
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 layout is complicated and, by looking at the graph 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 of making the diagram digestible.
For example, regarding the security mechanism that implemented as part of the Autodiscover process, the Autodiscover flow description that is provided in the next section, includes a very general reference to the security flaw that implemented.
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 hosted on Exchange On-Premise server.
Scenario 1: company website that uses the public domain name | no HTTPS support
The Autodiscover client (Outlook in our example) 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 particular scenario, the company website 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 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 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 attempting 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 underlying 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 knows 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 hostname – 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 accommodated in the Exchange Online server.
The cloud infrastructure doesn’t 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 the 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 for 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” of 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 stop our scenario in this phase.
The Autodiscover client verifies if the “new Autodiscover Endpoint” can communicate using HTTPS. 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 unique 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 process in an Active Directory environment.
Until now, the Autodiscover process that the Autodiscover client uses 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 particular organization owns multiple public domains, the IT needs to configure the required DNS record for each of the domains and also, 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 previous scenarios, only, then he will try to use the SRV Autodiscover method.
There could be a couple of scenes, 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 example 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 application for 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.
The next article in the current article series
It is important for us to know your opinion on this article