Article Series - Exchange and Autodiscover infrastructure | Table of content
Autodiscover flow in an Office 365 environment | The article series
The current article is the third article in a series of three articles.
The additional articles in the series are:
Step 7/20: Attempting to resolve the host name autodiscover-s.outlook.com in DNS.
In this step, the Autodiscover client query the DNS server for the IP address of a host named – autodiscover-s.outlook.com
In case that you are wondering from where the Autodiscover client gets this hostname, the answer is- from the URL address that was sent to him in the HTTP redirection response.
Step 7/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see the Autodiscover client address the DNS server looking for the IP address of the host – autodiscover-s.outlook.com
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
Step 8/20: Testing TCP port 443 on the host autodiscover-s.outlook.com to ensure it’s listening and open.
The Autodiscover client will try to verify if the potential Autodiscover Endpoint is listing on port 443 (HTTPS).
In our scenario, the HTTPS communication test succeeded, meaning that the destination host (the Autodiscover Endpoint) supports HTTPS communication.
Note –
- The fact that the “destination host” support HTTPS protocol doesn’t necessarily mean that the host is “right Exchange server” that can provide the required Autodiscover information.
- Even in case that the “destination host” support the HTTPS protocol + the “destination host” is a valid Exchange server, it doesn’t mean that he can provide the required Autodiscover information.
In our scenario, we will soon see that the “destination host” is not the “end of the journey” and he will not provide the Autodiscover client the required Autodiscover response but instead, an HTTPS redirection message.
Step 8/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see that the Autodiscover client tries to verify if the host – autodiscover-s.outlook.com, can communicate using TCP port 443.
Testing TCP port 443 on host autodiscover-s.outlook.com to ensure it’s listening and open: The port was opened successfully.
Step 9/20: Attempting to obtain the SSL certificate from the remote server autodiscover-s.outlook.com on port 443
The Autodiscover “relationships” between the Autodiscover client and the Autodiscover Endpoint is built on a “trust concept”.
The first phase is the step in which the Autodiscover client will need to trust the Autodiscover Endpoint and in the second phase, the Autodiscover Endpoint will need also to “trust” the Autodiscover client.
The “trust” begins with the step, in which the Autodiscover Endpoint, needs to prove his identity.
To be able to verify the Autodiscover Endpoint identity, the Autodiscover client will ask from the Autodiscover Endpoint to send him his public certificate.
Step 9/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see that the Autodiscover client asks from the host – autodiscover-s.outlook.com to send his certificate.
The server sends his certificate and, in the result, we can see the details of the certificate:
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.
Step 10/20: 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.
1. Validating the certificate name
The Autodiscover client addresses the potential Autodiscover Endpoint using the host name- autodiscover-s.outlook.com
To be able to know a specific host is “reliable”, Autodiscover client will check if the certificate includes the specified host name (autodiscover-s.outlook.com) or in a wildcard certificate scenario, the domain name – *.outlook.com
2. Validating the certificate trust
The public certificate that the server provide was created by a CA (certificate authority).
The Autodiscover client will need to also to validate the identity of the certificate authority 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.
Step 10/20: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see information about the three different tests that the Autodiscover client performs to the public certificate that was sent by the server:
1. Validating the certificate name
The Autodiscover client, verify that the server certificate includes the server FQDN or the server domain name.
The certificate name was validated successfully.
Hostname autodiscover-s.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.
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.
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.
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
Step 11/20: Checking the IIS configuration for client certificate authentication.
The “trust channel” between the Autodiscover client and the Autodiscover Endpoint, is built on the ability of each party to prove his identity.
In the former section, the Autodiscover client managed to successfully verify the server’s identity.
Now, we are getting to the second part, in which the Autodiscover client will need to prove his identity to the server for getting the required Autodiscover information.
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 prove his identity).
The use of a client certificate is very rare and, most of the time, the way that the client uses for “proof his identity” is by providing a user’s credentials.
Step 11/20: 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.
Step 12/20: Providing user credentials to the Autodiscover Endpoint
The Autodiscover proves his identity by providing a user’s credentials” (user name + password).
Step 13/20: Attempting to send an Autodiscover POST request to potential Autodiscover URLs
Autodiscover client “think” that the host – autodiscover-s.outlook.com is a potential Autodiscover Endpoint and for this reason, the Autodiscover client creates a request for the Autodiscover information.
Note that the term that is used for describing the Autodiscover Endpoint is – “a potential Autodiscover Endpoint”.
The word “potential”, tell us that the Autodiscover client is aware of the fact that the host he is addressing, could be the final node or a node that will redirect him to additional Autodiscover Endpoint.
In our scenario, the “answer” that the host autodiscover-s.outlook.com provide include a redirection message that redirects the Autodiscover client to additional potential Autodiscover Endpoint named – pod51049.outlook.com
Step 13/20: Analyzing the data from the ExRCA connectivity test
On the ExRCA result page, we can see the following information about the process:
The Autodiscover client, address the Autodiscover Endpoint and ask for the Autodiscover response.
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from the URL – https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml for user Bob@o365info.com The Autodiscover XML response was successfully retrieved.
However, instead of getting the required Autodiscover information, the Autodiscover client gets a redirection answer to additional host:
An HTTPS redirect was received in response to the Autodiscover request. The redirect URL is https://pod51049.outlook.com/Autodiscover/Autodiscover.xml.
Step 14/20: Attempting to resolve the host name pod51049.outlook.com in DNS
To be able to reach the host named – pod51049.outlook.com, the Autodiscover client will need to get information about the IP address of the specific host.
Autodiscover connects a DNS server and asks for the IP address on – pod51049.outlook.com
Step 14/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see that the Autodiscover address, the DNS server and the DNS server reply by providing a list of IP addresses (IP address that are mapped to the host name).
Attempting to resolve the host name pod51049.outlook.com in DNS. The host name resolved successfully.
IP addresses returned: 132.245.229.146, 132.245.226.34, 157.56.251.217, 157.56.255.60, 132.245.210.9, 132.245.212.98, 157.56.250.66, 157.56.254.178, 2a01:111:f400:803c::2
Step 15/20: Testing TCP port 443 on host pod51049.outlook.com to ensure it’s listening and open.
To be able to start the Autodiscover process with the potential Autodiscover Endpoint (pod51049.outlook.com), the Autodiscover client needs to verify that the destination host can communicate using the HTTPS protocol.
Step 15/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see that the Autodiscover client tries to verify of the destination host can communicate using HTTPS and that the test was successfully completed, meaning the destination host is listing the communication requests that are sent to port 443.
Testing TCP port 443 on host pod51049.outlook.com to ensure it’s listening and open. The port was opened successfully.
Step 16/20: Asking from the potential Autodiscover Endpoint to provide a public server certificate
The Autodiscover client needs to be sure, that the destination host can be trusted.
For this reason, the Autodiscover client asks for the destination host (pod51049.outlook.com) to prove his identity by providing a public certificate.
Step 16/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see that the Autodiscover client asks for the host – pod51049.outlook.com to send his certificate.
The server sends his certificate and, in the result, we can see the details of the certificate:
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.
Step 17/20: Testing the pod51049.outlook.com SSL certificate to make sure it’s valid.
The certificate validation test which the Autodiscover client performs, includes three different parts.
1. Validating the certificate name
The Autodiscover client addresses the potential Autodiscover Endpoint using the host name- pod51049.outlook.com
To be able to know a specific host is “reliable”, Autodiscover client will check if the certificate includes the specified host name (pod51049.outlook.com) or in a wildcard certificate scenario, the domain name – *.outlook.com
2. Validating the certificate trust.
The public certificate that the server provide was created by a CA (certificate authority).
The Autodiscover client, will need to also to validate the identity of the certificate authority who 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.
Step 17/20: Analyzing the data from the ExRCA connectivity test
In the Microsoft Remote Connectivity Analyzer result page, we can see information about the three different tests that the Autodiscover client performs to the public certificate that was sent by the server:
1. Validating the certificate name.
The client verifies that the server certificate includes the server FQDN or the server domain name.
The certificate name was validated successfully. Hostname pod51049.outlook.com was found in the Certificate Subject Alternative Name entry.
2. Validating the certificate trust.
The client verifies the trust chain that appears in the server certificate.
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 the 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 client verifies that the server certificate is still valid and was not expired. In our example, the test complete successfully.
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 18/20: Checking the IIS configuration for client certificate authentication
The Autodiscover client, check if the destination host (the Autodiscover Endpoint) needs a client certificate. A client certificate, is a method in which the client can prove his identity.
Step 18/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see that the Autodiscover client asks the server id he needs a client certificate; 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 19/20: Providing user credentials
After the certificate validation, test was successfully completed and the Autodiscover client can “trust” the destination host, the Autodiscover client will also need to prove his identity.
The Autodiscover client will identify himself by providing a user’s credentials”
(User name + password).
Step 20/20: Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
This is the “the last station” of the Autodiscover client journey.
In our specific scenario, the host pod51049.outlook.com is the Office 365 Public facing Exchange server that will provide the Autodiscover client the required Autodiscover information, the Autodiscover information that is needed for creating a new Outlook mail profile, information about the available Exchange CAS server web services and enable the mail client to access his Office 365 mailboxes.
Step 20/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see the Autodiscover steps in which the Autodiscover client reaches his final destination.
The Autodiscover addresses the Potential Autodiscover Endpoint by using the URL address – https://pod51049.outlook.com/Autodiscover/Autodiscover.xml and send a “Post request” asking for the Autodiscover information.
The Potential Autodiscover Endpoint (Exchange Online CAS server) accepts the request and sends Autodiscover response to his client.
The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://pod51049.outlook.com/Autodiscover/Autodiscover.xml for user bob@o365info.com
The Autodiscover XML response was successfully retrieved.
The Autodiscover response content
The Autodiscover response includes tons of information.
We will not review each of the “sections” that include in the Autodiscover responds, but just as an example, we can see a couple of details that include in the Autodiscover respond file:
1. The Autodiscover Exchange provider (number 1).
The exchange CAS server includes a couple of Outlook providers. The Autodiscover information includes a dedicated section for each of this provider.
In our example, we took a screenshot of the part that includes the information for the EXCH provider – <Type>EXCH</Type>
2. The “name” of the Exchange Online CAS server
The Exchange Online infrastructure is built on the Exchange 2013 version. In the Exchange 2013 environment, the mail client doesn’t use the Exchange CAS server name but instead, the Autodiscover client gets a “session id” that serves as an “address” for the mail client.
In our example, we can see the information about the “session address” that is provided to the mail client.
<Server>e2437a8c-a37f-4e6a-bccd-26a71abd2543@o365info.com</Server>
The Autodiscover response includes a detailed information about each of the Exchange CAS server web services that are “offered” to his clients.
In the following example, we can see the information about the available services:
- Availability services (Free\Busy time) (number 2).
The URL address that the Outlook client is instructed to use is:
<ASUrl>https://outlook.office365.com/EWS/Exchange.asmx</ASUrl>
- Automatic reply (Out of office) services (number 3).
The URL address that the Outlook client is instructed to use is:
<OOFUrl>https://ex01.o365info.local/ews/exchange.asmx</OOFUrl>
- Off line address book (number 4).
The URL address that the Outlook client is instructed to use is:
<OABUrl>https://outlook.office365.com/OAB/226ce079-2845-4fac-be53-6ccebb70c82a/</OABUrl>
Exchange Autodiscover | Article series index
We really want to know what you think about the article
The post Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36 appeared first on o365info.com.