Exchange clients and their Public facing Exchange server | Part 13#36

Page 1 of 26 | Exchange clients and their Public facing Exchange server | Part 13#36

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

Exchange clients and their Public

facing Exchange server | Part 13#36

The current article will be dedicated to the subject of Exchange clients that access

Exchange services from a public network.

The focus is on the “public Exchange clients” because, the characters of the

communication channel between the Exchange server and his Exchange client in a

public environment, have a different character from the communication channel

that is implemented between Exchange clients and Exchange server in an

environment that considers as “private” or “internal network” based environment.

The main characters of the public environment and the relationships of Exchange

server and his Exchange client are:

http://o365info.com/exchange-clients-public-facing-exchange-server-part-13-of-36

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

http://o365info.com/



1. Public facing Exchange server – to be able to address the Exchange server, the

Exchange server should be configured as “Public facing Exchange server”. The

translation of this term is – Exchange server who has public FQDN, public IP and,

public certificate. In addition, we will need to make all the required

configurations in the Firewall\Proxy infrastructure that will allow access from

external client to the “internal” Exchange server.

2. Autodiscover flow\process – the Autodiscover flow in a public environment in

which the Autodiscover client needs to locate his Autodiscover Endpoint, will not

be implemented by using access to Active Directory because in a public

environment, the Active Directory services are not available. Instead, the

Autodiscover client will try to locate his Autodiscover Endpoint by using a

predefined naming structure and DNS infrastructure for locating the required

Autodiscover Endpoint.

Q1: Does the Exchange server must be configured as Public facing Exchange

server?






A1: No, technicality we don’t have to expose the Exchange server to the Exchange

client that located in the public network. In most of the modern working

environment, the “business need” is to enable external Exchange client to access

organization mail services but, this is not a mandatory requirement.

Q2: In a scenario in which the organization has multiple sites, and each of the sites

includes multiple Exchange servers, do we need to “published” all the existing

Exchange servers?

A2: The answer is no. For example, in a site that includes multiple Exchange servers,

we need to “expose” only one specific Exchange server who will serve as a

representative for all the “internal Exchange infrastructure”.

When public Exchange clients address the Public facing Exchange server, the

Exchange server “know” how to route their request to internal Exchange resources

and provide the “answer” from the internal Exchange resource to the external

Exchange client.






In this scenario, the Public facing Exchange server will have two different identities

or interfaces:

One interface for the internal\private Exchange infrastructure

One interface for Public Exchange clients






Public facing Exchange CAS server | The two worlds

To be able to demonstrate the “two worlds” of Exchange server – the internal

versus the external interfaces and the characters of this different environment, let’s

use a scenario of an infrastructure that have the following characters:

The charters of the Exchange environment in our scenario are as follows:

Active directory internal domain name is – o365info.local

Public domain name is – o365info.com

The E-mail address of the organization users is based on the mail suffix

– o365info.com

Exchange\Active directory sites – the organization has two Exchange\Active

Directory sites: New York Site and Los Angles Site (the New York site, is the

headquarters of the company).

The name of the Exchange CAS server in New York Site is – exo1.o365info.local

The name of the Exchange CAS server in Los Angles Site is

– exo2.o365info.local






John is an organization’s user whom his mailbox is hosted on the New York

Exchange Site.

Alice is an organization’s user whom his mailbox is hosted on the Los Angles

Exchange Site.

Exchange CAS server – Internal and external FQDN

naming scheme

One of the main tasks when planning or building an Exchange infrastructure is the

subject of the naming scheme (namespace) that includes the internal and the

external Exchange server FQDN’s.

The result depends on the specific organization scenario, and the services that the

organization needs or wants to provide to his internal and external mail clients.

In our example, we will review three different optional scenarios, of public

Exchange client that needs access to their Exchange server (to the Public facing

Exchange server).

Many times, the small and midsize organization will “expose” only one Exchange

CAS server who will serve as a “Public facing Exchange CAS server”.






In a scenario of enterprise company, that have multiple sites in different

geographical locations, the Exchange public infrastructure, will include more than

one “Public facing Exchange CAS server”.

For example, each of the company sites can have a “Public facing Exchange CAS

server”.

In the following section, we will review four different scenarios:

Scenario 1 and scenario 2, will demonstrate an Exchange infrastructure that

has only one “Public facing Exchange CAS server”.

Scenario 3 and scenario 4, will describe Exchange infrastructure that uses a

“Public facing Exchange CAS server” for each of the company Exchange sites

(multiple Public facing Exchange servers).

We will begin with a simple scenario and move forward to more complicated or

advanced scenarios.

In the following table, we can see the naming scheme that was selected for the

specific organization (o365info.com )

Note – the following table, includes the information for all the scenarios that we will

be reviewing. Some of the simple or the basic scenario, doesn’t use all the

information that appears in the “Exchange FQDN’s” table.

New York Exchange CAS server

The Exchange CAS server of New York site, will be configured as a “Public facing

Exchange CAS server”.

The internal or the private name of the “New York Exchange CAS server” is

– exo1.o365info.local

We will use three “public names” for the “New York Exchange CAS server”:

autodiscover.o365info.com

mail.o365info.com

owa.o365info.com






Los Angles Exchange CAS server

The internal or the private name of the “Los Angles Exchange CAS server” is –

exo2.o365info.local

We will use two “public names” for the “Los Angles Exchange CAS server”:

mail-la.o365info.com

owa-la.o365info.com

An additional consideration

Public DNS and A records

This public name will have to re “registered” at a public DNS and mapped to the






“New York + Los Angles Exchange CAS server” public IP.

Public IP address

In our scenario, despite the fact the Public facing Exchange server has multiple host

names, only one Public IP address is allocated for the “New York Exchange CAS

server”

The mail client is not “interested” in this fact.

The reason for using a multiple hosts name (FQDN’s) is just for convenience

purposes.

For example, most of the time, the popular naming convention for accessing the

Exchange web mail services is by using the host name such as – owa.o365info.com






Exchange CAS server public certificate

The certificate that will be provided to the external mail client by the “Public facing

Exchange server”, will need to include all the different FQDN names whom we

mention.

Note that the public server includes the internal names (FQDN’s) of the “New York

and Los Angles Exchange CAS servers.

The external mail client doesn’t relate to this “Internal FQDN’s” and doesn’t need to

verify this “Internal FQDN’s”.

This internal name, will be used only by an internal mail client that connects the

Exchange CAS server from “inside” of the organization’s private network.






Public facing Exchange CAS server | Naming scheme and

Exchange services

A simple question that we can ask ourselves is – why to use more than one public

name and what did we choose these “specific names”?

The answer is that these public names are based on a standard naming convention.

Technically speaking, we could have used only one public name, choose additional

public names or choose different host names (the exception is the Autodiscover

host name who considers as a reserved name).

The public names who were chosen for the “Public facing Exchange server” are just

“standard names” that use most of the time.

The Autodiscover public FQDN

External Exchange client (Autodiscover client) that will look for an Autodiscover

Endpoint will look for a specific host name – autodiscover.o365info.com

For this reason, this host name is mandatory, and we cannot choose another or

different name.






Note – there is an additional Autodiscover method based on an SRV record that

allows us to use a different name for the “Public facing Exchange CAS server” that

provide the Autodiscover services, but we will not review this option in the current

article.

Exchange web mail services public FQDN

External web mail clients, will address the Public facing Exchange server by using

the host name – owa.o365info.com

Many organizations use the naming convention – OWA + <Public domain name> for

publishing the Exchange services that provide external mail the option to access

their mailbox by using a web browser (web mail client).

As mentioned before, the organization can choose any name who will suit his needs

and there is no mandatory requirement to choose this specific host name (OWA)

The “general public FQDN” of the Public facing Exchange server

The public hostname – mail.o365info.com, will be used for all the rest of the

Exchange web services such as – Availability services (Free\Busy time), Automatic

reply (Out of office), unified messaging and so on.

Most of the time, this public name (mail.o365info.com) will also be used for

publishing the Exchange MX record.

LOS ANGLES SITE.

The “Public facing Exchange server Los Angles Exchange server”, will have to use a

different host name because, we cannot use the same host names for a different

Exchange server.

Note – in the last scenario, we will review an exception for this rule. The ability to

use the same host names for a different Exchange server could be implemented by

using a GeoDNS.

Los Angles Exchange web mail services public FQDN






External webmail clients will address the Public facing Exchange server by using the

hostname – owa-la.o365info.com

Los Angles – “general public FQDN” of the Public facing Exchange server

The public hostname – mail-la.o365info.com, will be used for all the rest of the

Exchange web services such as – Availability services (Free\Busy time), Automatic

reply (Out of office), unified messaging and so on.

External Exchange mail client access – scenarios

In the following section, we will review a couple of options of – ”External Exchange

client access scenarios”

The description of the workflow in each of the scenarios doesn’t include all the

details that are involved in the communication process between the Exchange mail

client and the Public facing Exchange CAS server.






The main purpose is just to provide a high level view of the communication channel

that is implemented between the public Exchange clients and the Public facing

Exchange server.

How public Autodiscover client locates their Autodiscover Endpoint.

How does the Public facing Exchange server identify himself by providing a public

certificate?

How does the Autodiscover client get the required Autodiscover information (the

Autodiscover server response).

Note – as part of the description of the Autodiscover flow, we will display a sample

of the Autodiscover response. A standard Autodiscover response includes many

lines of information. To simplify the process, I have been chosen to display only a

small sample of the content of the autodiscover.xml that include the URL address

for the following Exchange web services:

1. ECP URL address

The ECP (Exchange Control Panel) is used by the webmail client such as OWA for

managing and configuring many user settings using the OWA web interface.

2. EWS URL address – the EWS (Exchange Web Services) URL is used by Exchange

for providing a variety of web services such as: Availability services (Free/Busy

time), Auto Replay (Out of office), Mail tips and more.

Scenario 1: Exchange mail services for external mail clients |

Simple scenario

In this scenario, John is trying to access his mailbox that is hosted on the New York

Exchange site from a public network. John would like to create a new Outlook mail

profile.

The information that John will need to provide is – his E-mail address

([email protected] ) + his user credentials.

In this scenario we will “ignore” the other company Exchange site (Los Angles) and

concentrate only on the Autodiscover workflow when an external mail client

accesses the “New York Public facing Exchange CAS server”.






Step 1: external mail client | Autodiscover process

Because John is located on a public network, the Autodiscover method, in which the

Autodiscover client connects the local Active Directory for getting information about

the available Exchange CAS server\s is not available for him because, the internal

Active Directory is not “exposed” to the public network.

In that case, the Autodiscover process of “locating a potential Autodiscover

Endpoint” is implemented by looking for an Autodiscover Endpoint hostname,

which is extracted from the recipient E-mail address.

In our example, John will look for an Autodiscover Endpoint by using the hostname

–o365info.com (number 1).






In our scenario, this host name is not published and because the Autodiscover

client will not find such host name, the Autodiscover client will create a new DNS

query looking for the hostname – autodiscover.o365info.com

Step 2: connecting the Public facing Exchange CAS server

In our scenario, the organization uses the “New York Exchange CAS server” as a

Public facing Exchange CAS server.

The external mail client initiates a connection attempt to the Public facing Exchange

server by using the HTTPS protocol.

The mail client will ask for the server to prove his identity by providing a public

certificate (number 2).

Step 3 – Verify the Exchange server public certificate

The mail client will verify that the server certificate includes the FQDN –


Note – in case that the Public facing Exchange server uses a wildcard certificate; the

Autodiscover client will verify only the part of the domain name, in our case

– o365info.com .

In case that the external mail client verifies that the Exchange certificate is “OK”, the

client will also provide his identity (username and password).

Step 4 – Exchange client request from the Exchange server to provide the

autodiscover.xml file

The external mail client will ask from Exchange server to provide him the required

autodiscover.xml file (number 4).

Step 5 – Exchange server provides to the Exchange client the autodiscover

response (autodiscover.xml)

The Exchange server sends the external mail client the required autodiscover

response (number 5).

In the following screenshot, we can see a small example from the content of the

autodiscover.xml file.






Exchange EWS services – we can see that the URL address of the Exchange EWS

services is provided by using the hostname – o365info.com

Exchange ECP – the URL address of the Exchange control panel (the web address

that is used by the webmail client to configure user settings) includes the host

name – o365info.com


Single Public facing Exchange CAS server | Multiple Exchange

sites

In the next scenario, Alice is trying to connect to her mailbox from a public network.

As mentioned, the organization has two Exchange sites. Alice’s mailbox is hosted on

the Exchange CAS server who resides in the Los Angeles site.

The Exchange CAS server in Los Angles site is a “non-Public facing Exchange CAS

server”.

In simple words, an external mail client cannot directly connect this Exchange

server.

To be able to provide mail services to the external mail client, the Exchange CAS

server who was selected as a “representative” that will have a public availability

(Public facing Exchange CAS server) is the Exchange CAS server from New York site.

Step 1: external mail client | Autodiscover process

When Alice starts, he Outlook client, the mail client will try to look for Autodiscover

Endpoint.

In that case, the Autodiscover process is implemented by looking for an

Autodiscover Endpoint hostname, which is extracted from the recipient E-mail

address.






In our example, Alice Outlook client will look for an Autodiscover Endpoint by using

the hostname – o365info.com (number 1).

In our scenario, this host name is not published and because the Autodiscover

client will not find such host name, the Autodiscover client will create a new DNS

query looking for the hostname – autodiscover.o365info.com

Step 2: connecting the Public facing Exchange CAS server

In our scenario, the organization uses the “New York Exchange CAS server” as a

Public facing Exchange server.

Note that Alice’s mailbox, is located on the Exchange CAS server at the Los Angles

site.

The external mail client initiates a connection attempt to the Public facing Exchange

server by using the HTTPS protocol.

The mail client will ask for the server to prove his identity by providing a public

certificate (number 2).

Step 3 – Verify the Exchange server public certificate

The mail client will verify that the server certificate includes the FQDN –


In case that the external mail client verifies that the Exchange certificate is “OK”, the

client will also provide his identity (user name and password).

Step 4 – Requesting from the Exchange server to provide the autodiscover.xml

file

The external mail client will ask from Exchange server to provide him the required

autodiscover.xml file (number 4).

Step 5 – Exchange provides the mail client the autodiscover.xml

The Exchange server sends the external mail client the required autodiscover.xml

file (number5).

In the following diagram, we can see an example form the content of the

autodiscover.xml file.






Exchange EWS services – we can see that the URL address of the Exchange EWS

services is provided by using the host name – o365info.com

Exchange ECP – the URL address of the Exchange control panel (the web address

that is used by the web mail client to configure user settings) includes the host

name –

o365info.com

Step 6 – access to the mailbox data by the external mail client | Proxy

mechanism

Pay attention to the interesting fact that Alice, cannot connect directly her Los

Angles Exchange CAS server – exo2.0365info.com

Instead, each time that Alice will need to access data in her mailbox, the request will

reach the New York Exchange server (the Exchange server with public availability);

the New York Exchange server will create an LDAP query looking for the Exchange

CAS server who host Alice’s mailbox.

When the New York Exchange CAS server finds that the Exchange CAS server that

hosts Alice’s mailbox is – exo2.0365info.com he will create a connection request,

asking to “fetch” the information from Alice’s mailbox (number 6).

The method in which Exchange CAS server sends a record for data from another

Exchange CAS server (the Exchange CAS server who provides access to the required

user mailbox) described as “Proxy”.

Step 7 – returning the required data

The Los Angles Exchange CAS server (exo2.0365info.com) returns the required

mailbox data to the New York Exchange CAS server (exo1.0365info.com).






The New York Exchange server, send or provide the required mailbox data to the

external mail client (number 7 and Number 8).

PREFIX

The following two scenarios relate to Exchange infrastructure that includes multiple

Exchange sites and additionally, multiple Public facing Exchange CAS servers.

In theory, there could be only one “focal point” that represents the domain

Autodiscover Endpoint.

Later (in scenario 4), we will see how to implement a different network

infrastructure that will enable us to override this theoretical limitation.


Multiple Public facing Exchange CAS servers | Multiple Exchange

sites






In the following scenario, each of the Exchange site is represented by a Public facing

Exchange server.

Before we begin with the details of the Autodiscover workflow, it’s important to

understand that the Autodiscover client knows how to look for a predefined host

name who represents the Autodiscover Endpoint.

In our example, the Autodiscover Endpoint name whom the external mail client will

look for is –autodiscover.o365info.com

The challenge that we face now is – “how can we publish two different Public facing

Exchange CAS servers using the same host name?

Should we point the autodiscover.o365info.com DNS record to the New York site

Exchange CAS server to or, should we point the

autodiscover.o365info.com DNS record to the Los Angles site Exchange CAS server

on the ?

In our scenario, we will continue to point the autodiscover.o365info.com record to

the public IP address of the Public facing New York Exchange CAS server.






When an external mail client that their mailbox is hosted at the Los Angles site will

connect the Public is facing New York Exchange CAS server, the Public facing New

York Exchange CAS server will reply with a special redirection message that will

point the external mail client to their “Public facing Los angles Exchange CAS

server”.

To make the Autodiscover workflow more “digestible” I will omit some parts of the

process.

Step 1, 2, 3 and 4 – the external mail client finds the public IP address of the host –

autodiscover.o365info.com and tries to create an HTTPS session.

The external mail client will ask for the server certificate and verify the certificate is

valid.

Because the certificate test was completed successfully, the external mail client

assumes that he reaches the “right Exchange CAS server”.

The mail client will request from the server the autodiscover.xml file






Now, is the main difference between the former scenarios: instead of providing to

the mail client the required autodiscover.xml file, the New York Public facing

Exchange CAS server sends a redirection message.

The redirection message includes the host name who is used by the Los Angles

Public facing Exchange CAS server.

In our scenario, the host name is – mail-la.o365info.com

Now, the journey of the external mail client starts all over again.

The external mail client will need to get the public IP address of the host –


After the external mail client gets the required Public IP address, the mail client

checks if the host – mail-la.o365info.com can communicate using the HTTPS

protocol.

In case that the Los Angles Public facing Exchange server is “open” to

communication using port 443, the external mail client will send a request for a

server certificate.

When the Los Angles Public facing Exchange CAS server will provide his certificate,

the mail client will check that the server certificate includes the host name –


After the completion of the mutual authentication process, the external mail client

requests the autodiscover.xml file.

In the following diagram, we can see; we can see a small example form the content

of the autodiscover.xml file.

Note that the URL address includes the Public FQDN that “belong” to the Los Angles

Public facing Exchange CAS server






Scenario 4: Exchange mail services for external mail clients

|Multiple Public facing Exchange CAS servers | Multiple

Exchange sites | GeoDNS

In the following scenario, we will review a nice solution which is based on using

features that described as: GeoDNS.

The term – “GeoDNS” describe a technology of “smart DNS server”.

Instead of a standard DNS session in which the DNS client query the DNS server for

a specific host name and the DNS server reply using the information that he has in

his database, the feature of GeoDNS enables the DNS server to recognize the

geographical location of his “client” and based on this information provide different

answers.

In the following scenario, we will use the option of GeoDNS for publishing the

information about the Autodiscover records.

The host name – Autodiscover will point to two different Exchange server at the

same time.

When a user who is geographical location is in New York query the DNS server

regarding the host name – autodiscover.o365info.com , the DNS server will

“recognize” his geographical location and provide him the public IP address of the

“New York Public facing Exchange server”.

The same goes for Exchange client that their geographical location is at Los Angles.






Each time that a “Los Angeles” mail client will query the DNS for the public IP of the

host- autodiscover.o365info.com , the DNS server will provide him the public IP

address of the “Los Angles Public facing Exchange server”.

John is a user whom his mailbox is hosted at the New York Exchange site, and Alice

is a user whom his mailbox is hosted at the Los Angles Exchange site.

Let’s assume that both passed through all the phases of finding the Public facing

Exchange CAS server, authentication and so on.

When John asks his “Autodiscover Endpoint” for the autodiscover.xml that include

the required information about existing public Exchange services, the answer will

be sent by the New York Public facing Exchange CAS server and will include the

public host names (FQDN’s) that are “mapped” to the public IP address of the New

York Public facing Exchange CAS server.

When Alice gets her autodiscover.xml, the content of the file will include different

information that points to the public host’s names of the Los Angles Public facing

Exchange CAS server.









Date post:	22-Jul-2016
Category:	Documents
Upload:	o365infocom
View:	226 times
Download:	2 times

Exchange clients and their Public facing Exchange server | Part 13#36

Documents