Post on 22-Jul-2016
description
transcript
Page 1 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Autodiscover flow in an Exchange
Hybrid environment | Part 3#3 | Part
34#36
The current article, is the continuation of the previous article , in which we will
continue to review in details the Autodiscover journey in Exchange Hybrid based
environment
Autodiscover flow in an Exchange Hybrid environment | The
article series
The current article is the last article in a series of three articles.
The additional articles in the series are:
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
Page 2 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Step 16/30: redirect (HTTP 301/302) response
The Autodiscover client is “programmed” to use an HTTP redirect request, in case
that the potential Autodiscover Endpoint cannot communicate using HTTPS.
In our example, because the potential Autodiscover Endpoint cannot communicate
using HTPTS, the Autodiscover client will “draw back” and, try to communicate with
the Autodiscover Endpoint using the HTTP protocol.
The Autodiscover client HTTP request will include requests for information about
“other Autodiscover Endpoint” name that can provide the required information.
In our scenario, the Autodiscover client addresses the host
– autodiscover.o365info2.mail.onmicrosoft.com
The autodiscover.o365info2.mail.onmicrosoft.com host, is a special Office 365
component, which serve as a “logical router”, that is responsible for redirecting
Autodiscover clients to an additional nodes or elements (Autodiscover Endpoints),
that can help the Autodiscover client to reach his final destination.
Page 3 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
In our scenario, the HTTP redirect message that the Autodiscover Endpoint provide
to his Autodiscover client, include the URL address of a Potential Autodiscover
Endpoint named
– autodiscover-s.outlook.com
Page 4 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
In the following diagram, we can see the specific Autodiscover phase in which the
Autodiscover client is redirected to the “next hop” – autodiscover-s.outlook.com
Step 16/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information-
The Autodiscover Endpoint reply, using a redirection message code (HTTP 301/302)
and provide to the Autodiscover client the “full URL” address of the destination
Page 5 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Autodiscover Endpoint – https://autodiscover-
s.outlook.com/Autodiscover/Autodiscover.xml
The Microsoft Connectivity Analyzer is checking the host
autodiscover.o365info2.mail.onmicrosoft.com for an HTTP redirect to the
Autodiscover service. The redirect (HTTP 301/302) response was received
successfully. Redirect URL:
https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
Step 17/30: Attempting to resolve the hostname autodiscover-
s.outlook.com
Autodiscover client query the DNS server for the IP address of the host –
autodiscover-s.outlook.com
Before we continue, it’s important to stop for a minute and ask ourselves-
Q1: Who is, or what is, the host autodiscover-s.outlook.com?
A1: The host named – autodiscover-s.outlook.com, is an additional Office 365
component that serves also as a “logical router.
Q1: If the autodiscover-s.outlook.com, considers also as a logical router, what is the
difference from the former HTTP redirect mechanism?
A2: The former process was based on the HTTP protocol and the current
redirection process is based on HTTPS redirect mechanism.
Q3: So… what is the big difference between HTTP versus HTTPS redirection?
Page 6 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
A3: The difference is that when using the HTTPS redirection method, the
Autodiscover client will need to verify the Autodiscover Endpoint certificate so he
will be able to “believe” him,
The “redirect game”, is a very interesting concept that is implemented in the Office
365 cloud environment.
In a “standard” Exchange on-Premises environment, that Autodiscover client that
communicates with his Exchange server, expects from the server to provide an SSL
certificate that includes the FQDN of the Autodiscover Endpoint or the domain
name (in case that the server use wildcard certificate).
For example, in our scenario, the Autodiscover client will use Alice E-mail address,
domain name and when the Autodiscover client will start the HTTPS session with
the Exchange server, the Autodiscover client will look at the server certificate
looking for the hostname –autodiscover.o365info.com or for the domain name
– o365info.com
In case that the server certificate will not include the specified name, the
Autodiscover client is “obliged” to stop the communication process and, move on to
another method or display an error message.
In the Office 365 cloud environment, the interesting fact is that there is no “real”
Exchange server that have a public certificate that include the “required hostname”
such as –
autodiscover.o365info.com
In reality, there is no option to purchase a dedicated public certificate for each of
the Office 365 tenants.
In this case, theoretically, the Autodiscover process should fail.
The solution for this “enigma” is – a process is which the Autodiscover client will be
“instructed” to communicate with “other” Autodiscover Endpoint, that have a
different host name from the “original host name” that the Autodiscover client try
to use.
Page 7 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
If you are a suspicious fellow, a paranoid thought could appear in your mind – if the
Autodiscover client looks for a very specific host name (such
as autodiscover.o365info.com in our scenario) and the “cloud” redirect the
Autodiscover client to other Autodiscover Endpoint hostname such as
– autodiscover-s.outlook.com , how can we know that this is not a fraud or a
conspiracy that could lead the “Autodiscover client” to un-trusted elements?
Page 8 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
The answer to this “fears” is that the Autodiscover Endpoint which the Autodiscover
client is “redirected to” (the autodiscover-s.outlook.com) will have to prove his
identity and to the fact that he is trustworthy, by providing a public certificate.
The Autodiscover Endpoint – autodiscover-s.outlook.com have a public certificate
that includes all of the required “parts” that will be verified by the Autodiscover
client.
Only after all of the “certificate parts” will be tested and verified by the Autodiscover
client, then the Autodiscover client will be able to “believe” that the host –
autodiscover-s.outlook.com is a reliable source of information.
Page 9 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
In the next sections, we will see that the autodiscover-s.outlook.com is not the last
hope in our Autodiscover journey, but for now, let’s carry on with the description of
the Autodiscover steps.
The Autodiscover client query the DNS server for the IP address of the host –
autodiscover-s.outlook.com
The DNS answer includes a range of IP address because, in reality, Office 365
infrastructure is a couple of “nodes” or “hosts” that “play the role” of
the autodiscover-s.outlook.com host.
Step 17/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information:
Attempting to resolve the host name autodiscover-s.outlook.com in DNS. The host
name resolved successfully. IP addresses returned: 157.56.241.102, 157.56.245.166,
157.56.232.166, 157.56.245.70, 157.56.236.214, 157.56.236.6.
Page 10 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Step 18/30: Testing TCP port 443 on host autodiscover-s.outlook.com to ensure
it’s listening and open
The Autodiscover client will try to verify if the autodiscover-s.outlook.com , supports
an HTTPS communication.
In our scenario, the test completes successfully meaning that autodiscover-
s.outlook.com support HTTPS communication.
Note – in case that you are wondering about the name of the host – “autodiscover-
s”, I could not find any formal explanation for the “S” in the host name but my belief
is that the “S” stand for security.
Step 18/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information:
Autodiscover client checks if the destination host can communicate using port 443
(HTTPS).
The results of the “HTTPS test” is -success.
Testing TCP port 443 on host autodiscover-s.outlook.com to ensure it’s listening
and open. The port was opened successfully.
Page 11 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Step 19/30: Attempting to obtain the SSL certificate from remote server
autodiscover-s.outlook.com
The Autodiscover client, ask from the Autodiscover Endpoint (autodiscover-
s.outlook.com) to prove his identity by providing a valid public certificate.
Step 19/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information:
The Autodiscover client request from the Autodiscover Endpoint to send him
his certificate.
The Autodiscover Endpoint sends his certificate.
The certificate was successfully accepted by the Autodiscover client.
Page 12 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from
remote server autodiscover-s.outlook.com on port 443. The Microsoft Connectivity
Analyzer successfully obtained the remote SSL certificate.
Remote Certificate Subject: CN=outlook.com, OU=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=WA, C=US, Issuer: CN=Microsoft IT SSL
SHA2, OU=Microsoft IT, O=Microsoft Corporation, L=Redmond, S=Washington,
C=US.
In the information details, we can see that the certificate “belong” to the Microsoft
Corporation (OU=Microsoft Corporation) and, that the certificate include the
domain name -outlook.com (Remote Certificate Subject: CN=outlook.com).
Step 20/30: Testing the autodiscover-s.outlook.com SSL certificate to
make sure it’s valid
The certificate validation test which the Autodiscover client performs, includes
three distinct different parts.
Page 13 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
1. Validating the certificate name
The Autodiscover client, address the potential Autodiscover Endpoint using the host
name –autodiscover-s.outlook.com
To be able to know that this is the valid or reliable source of information, the
Autodiscover client will check if the certificate includes the specified host name –
autodiscover-s.outlook.com or the domain name – *.outlook.com in a scenario of
wildcard certificate.
2. Validating the certificate trust
The public certificate that the server provide was provided 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
Page 14 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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
Step 20/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information:
1. Validating the certificate name
The Autodiscover client, verify that the server certificate includes the server FQDN
or the server domain name.
Validating the certificate name. The certificate name was validated successfully.
Host name autodiscover-s.outlook.com was found in the Certificate Subject
Alternative Name entry.
Page 15 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
2. Validating the certificate trust
The Autodiscover client verifies the trust chain that appears in the server
certificate.
The Autodiscover client successfully manages to verify the trust chain.
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=outlook.com, OU=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=WA, C=US.
3. Verify that the certificate date is valid.
The Autodiscover client verifies that the server certificate is still valid and was not
expired.
In our example, the test complete successfully meaning the server certificate is
valid.
Testing the certificate date to confirm the certificate is valid. Date validation passed.
The certificate hasn’t expired. The certificate is valid.
NotBefore = 2/18/2014 11:41:01 PM, NotAfter = 2/18/2016 11:41:01 PM
Page 16 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Step 21/30: Checking the IIS configuration for client certificate
authentication
The Autodiscover client, verify if the destination host (the Autodiscover Endpoint)
needs a client certificate. A client certificate, is a method in which the client can be
proof his identity.
Step 21/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see that.
The Autodiscover client asks the server if a client certificate is required.
The server replies that he doesn’t need a client side certificate.
Checking the IIS configuration for client certificate authentication. Client certificate
authentication wasn’t detected. Accept/Require Client Certificates isn’t configured.
Page 17 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Step 22/30: Providing user credentials to the Autodiscover Endpoint
After the certificate validation, test was successfully completed and the
Autodiscover client can “trust” the destination host, the Autodiscover client will also
need to proof his identity.
The Autodiscover client will identify himself by providing a user’s credentials”
(user name + password).
Step 22/30: Analyzing the data from the ExRCA connectivity test
Note – the part of “providing user credentials“, doesn’t appear in the Microsoft
Remote Connectivity Analyzer result page.
Page 18 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Step 23/30: Attempting to send an Autodiscover POST request to
autodiscover-s.outlook.com
The Autodiscover client will attempt to send an Autodiscover POST request to the
Autodiscover Endpoint for, getting the required Autodiscover information.
The host named – autodiscover-s.outlook.com is not the last node in our
Autodiscover journey but instead, “additional router” that will route the
Autodiscover Endpoint to his final destination – his Exchange server.
The redirection is implemented by using an additional – “HTTPS redirection”.
The Autodiscover client “trust” the host autodiscover-s.outlook.com but, the
autodiscover-s.outlook.com is not the “expected Exchange CAS server”.
In our specific scenario, autodiscover-s.outlook.com send an HTTPS redirection
message that includes the following URL address –
https://pod51049.outlook.com/Autodiscover/Autodiscover.xml
The Autodiscover client will “extract” from this URL address the host name –
Pod51049.outlook.com and in the next step, we will see the process in which the
Autodiscover Endpoint tries to communicate with this host for completing the
Autodiscover process.
Page 19 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
In the following diagram, we can see the phase in which we are located in our
Autodiscover journey
Step 23/30: Analyzing the data from the ExRCA connectivity test
Page 20 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information:
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover
response from
URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml for user
Alice@o365info2.mail.onmicrosoft.com. The Autodiscover XML response was
successfully retrieved. An HTTPS redirect was received in response to the
Autodiscover request. The redirect URL is
https://pod51049.outlook.com/Autodiscover/Autodiscover.xml.
Step 24/30: Attempting to resolve the host name
pod51049.outlook.com
The Autodiscover client creates a DNS query looking for the host
named- Pod51049.outlook.com
From the DNS server answer, we can see that the resolution for this specified host
name (Pod51049.outlook.com) include a range of IP addresses.
Despite the logical assumption that the host – Pod51049.outlook.com is a single
server, in reality, the host “Pod51049.outlook.com” represent many “units” of Office
365 Exchange server who serve Office 365 clients requests.
Page 21 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Step 24/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the range of
the IP4 and the IP6 address that are mapped to the specified host name.
Attempting to resolve the host name pod51049.outlook.com in DNS. The host
name resolved successfully. IP addresses returned: 157.56.250.66, 157.56.254.178,
132.245.229.146, 132.245.226.34, 157.56.251.217, 157.56.255.60, 132.245.210.9,
132.245.212.98, 2a01:111:f400:9434::2, 2a01:111:f400:9850::2,
2a01:111:f400:8000::9, 2a01:111:f400:9428::2, 2a01:111:f400:9800::12,
2a01:111:f400:882a::2, 2a01:111:f400:803c::2, 2a01:111:f400:9814::9
Step 25/30: Testing TCP port 443 on host pod51049.outlook.com to
ensure it’s listening and open.
The Autodiscover client, will try to verify if the host named
– Pod51049.outlook.comAutodiscover Endpoint, support an HTTPS communication.
In our scenario, the test complete successfully meaning
that, Pod51049.outlook.com support HTTPS communication.
Page 22 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Step 25/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information:
The Autodiscover client tries to verify if the “destination host” support the HTTPS
protocol and the answer is “yes”.
Testing TCP port 443 on host pod51049.outlook.com to ensure it’s listening and
open. The port was opened successfully.
Step 26/30: Asking from the potential Autodiscover Endpoint to provide
a public server certificate
Autodiscover client, ask from the Autodiscover Endpoint (Pod51049.outlook.com) to
proof his identity by providing a valid public certificate.
Page 23 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Step 26/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information:
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from
remote server pod51049.outlook.com on port 443. The Microsoft Connectivity
Analyzer successfully obtained the remote SSL certificate.
Remote Certificate Subject: CN=outlook.com, OU=Exchange, O=Microsoft
Corporation, L=Redmond, S=Washington, C=US, Issuer: CN=Microsoft IT SSL SHA1,
OU=Microsoft IT, O=Microsoft Corporation, L=Redmond, S=Washington, C=US.
Step 27/30: Testing the pod51049.outlook.com SSL certificate to make
sure it’s valid.
Page 24 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
The certificate validation test which the Autodiscover client performs, includes
three distinct different parts.
1. Validating the certificate name
The Autodiscover client address the potential Autodiscover Endpoint using the host
named –Pod51049.outlook.com
To be able to know that this is the “real host”, Autodiscover client will check if the
certificate includes the specified host name (Pod51049.outlook.com) or, the domain
name – *.outlook.com
2. Validating the certificate trust
The public certificate that the server provides, was provided by a CA (certificate
authority). The Autodiscover client will need to validate also the CA certificate that
provides the server hos certificate.
Page 25 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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
Step 27/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information:
1. Validating the certificate name
The Autodiscover client, verify that the server certificate includes the server FQDN
or the server domain name.
Page 26 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Validating the certificate name. The certificate name was validated successfully.
Host name pod51049.outlook.com was found in the Certificate Subject Alternative
Name entry.
2. Validating the certificate trust
The Autodiscover client verifies the trust chain that appears in the server
certificate.
The Autodiscover client successfully manages to verify the trust chain.
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=outlook.com, OU=Exchange, O=Microsoft
Corporation, L=Redmond, S=Washington, C=US.
One or more certificate chains were constructed successfully
3. Verify that the certificate date is valid.
The Autodiscover client verifies that the server certificate is still valid and was not
expired.
Page 27 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
In our example, the test complete successfully meaning the server certificate is
valid.
Testing the certificate date to confirm the certificate is valid. Date validation passed.
The certificate hasn’t expired. The certificate is valid.
NotBefore = 7/24/2014 6:34:15 PM, NotAfter = 7/23/2016 6:34:15 PM
Step 28/30: Checking the IIS configuration for client certificate
authentication
The Autodiscover client, verify if the destination host (the Autodiscover Endpoint)
need a client certificate. A client certificate, is method in which the client can proof
his identity.
Step 28/30: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see that
Page 28 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
The Autodiscover client asks the server if a client certificate is required.
The server replies that he doesn’t need a client side certificate.
Checking the IIS configuration for client certificate authentication. Client certificate
authentication wasn’t detected. Accept/Require Client Certificates isn’t configured.
Step 29/30: Providing user credentials to the Autodiscover Endpoint
After the certificate validation, test was successfully completed and the
Autodiscover client can “trust” the destination host, the Autodiscover client will also
need to proof his identity.
The Autodiscover client will identify himself by providing a user’s credentials” (user
name + password).
Step 29/30: Analyzing the data from the ExRCA connectivity test
Note – the part of “providing user credentials“, doesn’t appear in the Microsoft
Remote Connectivity Analyzer result page.
Page 29 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Step 30/30: Attempting to send an Autodiscover POST request to
potential Autodiscover
URL: https://pod51049.outlook.com/autodiscover/autodiscover.xml
This is the last stop on Outlook Autodiscover journey in the Hybrid environment.
Outlook or the “Autodiscover client”, fined his Exchange CAS server.
In this phases all the “pre requirements tasks” have already successfully completed-
Autodiscover manage to verify the Autodiscover Endpoint identity and provides his
identity to the Autodiscover Endpoint.
The last step, is the step in which the Autodiscover Endpoint (Exchange CAS server
named –Pod51049.outlook.com) will generate and send the Autodiscover response
to our Autodiscover client.
Page 30 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
In our scenario, the “client” is an Outlook client that will use the information in the
Autodiscover response for two main purposes:
1. Creating a new Outlook mail profile
The “declared mission” in our scenario was to enable Alice to create a new Outlook
mail profile.
The information that included in the Autodiscover response, will include all the
required information that is needed for creating a new Outlook mail profile using
the Outlook Anywhere settings.
2. Using the URL address of the Exchange web services
After the task of creating new Outlook mail profile is completed, Outlook will us the
URL address of the different Exchange web services that was included in the
Autodiscover answer, each time that Outlook will need a specific Exchange to serve
such as availability services (Free/Busy time), OAB (Offline address book) and so on.
Step 30/30: Analyzing the data from the ExRCA connectivity test
The Exchange CAS server Autodiscover responds is implemented as an XML file that
includes tons of “information lines” (XML Tags).
Page 31 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
We will not get into a detailed review of each of this “information bank line” but
instead, review just a small sample of the Autodiscover respond content.
In the Microsoft Remote Connectivity Analyzer result page, we can see the following
information:
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover
response from URL https://pod51049.outlook.com/Autodiscover/Autodiscover.xml
for user Alice@o365info2.mail.onmicrosoft.com.
The Autodiscover XML response was successfully retrieved.
The information in the Exchange Autodiscover response is dived into section.
The purpose of these sections is – to provide a different information for a different
mail profile of Outlook clients.
Exchange relates to the “different Outlook mail profile” as Outlook providers.
The different type classified as EXCH, EXPR, WEB and EXHTTP
EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings.
In the following screenshot, we can see an example for the XML tag’s names and
the information that included between these XML tags.
For example:
1. Outlook GUID\session ID
Page 32 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
In an Exchange 2013 environment, the Outlook client doesn’t use the name of the
Exchange CAS server but instead, use a unique session ID.
The value of the unique session ID is provided by using the <Server> XML tag.
<Server>61b3c3e6-97ba-4714-bcbb-d45efe969e56@o365info.com</Server>
2. Availability services (Free/busy time)
Each time that a user accesses his calendar and, ask to view the Free/busy time of
other users, the Outlook client will send a query to the Exchange web service’s URL
address that is dedicated to this purpose.
<ASUrl>https://outlook.office365.com/EWS/Exchange.asmx</ASUrl>
3. Automatic reply (Out of office)
The Exchange Automatic reply web services, enable Exchange clients, to respond
with an Automatic reply when a recipient sent mail to their mailbox.
In case that the Exchange client need to create an Automatic reply respond, the
client will use the following URL address:
<OOFUrl>https://outlook.office365.com/EWS/Exchange.asmx</OOFUrl>
4. Offline address book
The default setting for Outlook mail profile is Cache mode. When using the option
of cache mode, Outlook client will download an “off line” version of the Exchange
address book.
Outlook will need to know the exact URL address that he will need to use for
downloading the Offline address book + the name of the offline address book file
or file version.
<OABUrl>https://outlook.office365.com/OAB/226ce079-2845-4fac-be53-
6ccebb70c82a/</OABUrl>
Page 33 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
In the next screenshot, we can see the setting under the EXPR section (the setting
for an External Outlook Anywhere).
Here we can see additional details that are relevant or unique only when using the
Outlook Anywhere profile.
We can see that under the “EXPR profile” (<Type>EXPR</Type>) we can see a similar
setting such as the Exchange web services URL address:
<Server>outlook.office365.com</Server>
<ASUrl>https://outlook.office365.com/EWS/Exchange.asmx</ASUrl>
<OOFUrl>https://outlook.office365.com/EWS/Exchange.asmx</OOFUrl>
<OABUrl>https://outlook.office365.com/OAB/226ce079-2845-4fac-be53-
6ccebb70c82a/</OABUrl>
And additionally, a specific setting that are unlike for Outlook Anywhere such as the
authentication and encryption requirements.
In our example, the Autodiscover responds “inform” the Outlook client that
1. The name of the Exchange CAS server
The name of the Exchange CAS server who server that provides the Outlook
Anywhere services (RPC Proxy) is – outlook.office365.com
Page 34 of 34 | Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part
34#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
<Server>outlook.office365.com</Server>
2. Encryption requirement
The communication channel between the Outlook client and the Exchange server
muse be implemented using HTTPS and the authentication protocol is – Basic
<SSL>On</SSL><AuthPackage>Basic</AuthPackage>
3. The RPC\HTTPS hostname provider and the public certificate
To be able to verify that the Exchange server is “reliable” and can be trusted, the
Outlook client will check if the server certificate includes the value that described in
the msstd.
<CertPrincipalName>msstd:outlook.com</CertPrincipalName>;