Skip to content

Force TLS | Exchange Online environment vs. Exchange on-Premises environment | Part 5#12

In the current article, is consists of two parts:

  1. The part in which we provide a high-level review of the differences that exists between the Exchange on-Premises based environment vs. the Exchange Online based environment regarding mail connectors and TLS settings. The reason for examining these differences is, that there are much essential deferences’s begging with the naming convention, the management interface and the available option that relates to force TLS in each Exchange infrastructure.
  2. Description of the scenario characters that we will use in the next articles in the TLS article series that will help us to demonstrate on optional TLS flow between Exchange on-Premises and Exchange Online based environments. The second part of the current article, is dedicated to the description of the imaginary scenario in which two organizations (organization A and organization B) need to fulfil a mandatory security requirement in which the mail flow that existed between this organization must be encrypted using TLS and in addition, each party needs to clearly identify the other side.

Force TLS | Exchange on-Premises vs. Exchange Online | the Unique characteristics of each environment

Although Exchange Online based on the architecture of Exchange server, regarding the subject of force TLS, there are many differences between Exchange Online and Exchange on-Premises such as – Mail connectors naming convention and, different options and parameters when using the admin interface (the graphic admin interface and the PowerShell interface).

Also, there is a specific character of the Exchange Online based environment vs. a “standard organization network” environment.

Mail connector – Naming convention

As mentioned in the previous article, Exchange on-Premises use a different naming convention for incoming and outgoing mail connectors compared to Exchange Online.

In a scenario which involved Exchange on-Premises infrastructure and Exchange Online infrastructure, we will need to pay attention to term that we use for describing the mail connector in each of the different environment.

Exchange - Mail connectors naming convention

The challenges of configuring force TLS with Exchange Online mail based environment.

In Exchange on-Premises environment, the use of Force TLS is implemented differently regarding Receive connectors vs. Send connectors.

The two main challenges- configuring Force TLS setting between - mail server and Exchange Online

Exchange on-Premises Server Receive connector and The Exchange Online servers IP range.

In Exchange on-Premises server, when we configure the setting of the incoming mail connector (Receive connector), we identify the “other mail server” by specifying his IP address.

In a scenario in which the “other mail server” is the Exchange Online server, we are facing a couple of challenges:

  1. The Exchange Online infrastructure is not represented by using a specific IP address but instead, by a very wide IP range
  2. The information about the Office 365 and Exchange Online IP ranges is quite complicated. In case that we need to get a details information about this IP range we can use the information that appear in the article – Office 365 URLs and IP address ranges. But, in case that you try to read the information, you find that it’s not so easy task
  3. Given that we have the required information about the specific IP ranges that represent the Exchange Online and EOP (Exchange Online protection), the task of adding this information to the Exchange on-Premises Server Receive connector is also not an easy task which can be exposed to a large number of human errors.

We will review this subject in more details in the section – xx

Exchange on-Premises Server Send connector and The Exchange Online server public certificate

An additional element that we should understand is, the fact that the Exchange Online infrastructure represented by a “single public certificate” that serves for all the Office 365 tenants and doesn’t contain references for a particular public domain name which hosted at the Exchange Online infrastructure.

The meaning is that in Exchange on-Premises environment, when we need to relate to the server certificate on the “other side” (Exchange Online) we cannot define a specific host name or domain name that need to “appear” in Exchange Online certificate but instead, relate to the domain name that is displayed in the Exchange Online public certificate – outlook.com

When we say that Exchange Online server represent a particular organization such as o365pilot.com, it’s different from a “standard scenario” in which the organization uses a dedicated mail server.

For example, in a scenario in which Exchange Online represents the domain name o365pilot.com, there is no “dedicated public certificate” that relates to the domain name – o365pilot.com

Exchange Online represents thousands of different domains and organizations.
For this reason, there is no option to create a dedicated public certificate for each of these domains.

Exchange Online uses a “general public certificate” that represents all of the tenants that are hosted at Office 365 and use Exchange Online as their mail infrastructure.

We will review this subject in more details in the section – xx

The major characters of Exchange Online and Exchange on-Premises server based environment | Force TLS and mail connectors

In the following section, we will review that aspect of the Exchange Online and Exchange on-Premises server environment in relation to the subject of configuring the option of Force TLS

Exchange Online environment and Force TLS settings

Let’s make it simple – the Exchange Online management interface is more “friendlier” vs. the Exchange on-Premises management interface because, we can implement all the required configuration settings using the Exchange Online web admin interface without a need for a sophisticated and complex PowerShell command.

The additional advantage of the Exchange Online is – the consistency of the available option that we can use for incoming and outgoing mail connectors.

Exchange Online environment – outbound connector

The only option for identifying the “other side” (the mail server that Exchange Online address) is by using the option of the server certificate.

We can choose the “level of security” staring with some very basic requirements in which the destination server needs to have a certificate but, the certificate can be even a self-sign certificate, define a mandatory need for a public certificate that provided by a trusted CA (Certificate Authority) or, “hardens” the security requirements by specifying a particular host name or a domain that needs to be included in the server certificate.

Exchange Online environment – inbound connector

Regarding the available options of Exchange Online inbound connector, for identify the “other side” (the mail server that addresses Exchange Online) we can choose a different verification method:

Option 1 – verification based on IP address – accept mail only from the external mail server that is represented by a particular IP address.

Option 2 – verification based on a server certificate – accept mail only from the external mail server that can prove his identity by providing a certificate (and again, we can choose a different level of security requirements such as a self-sign certificate, public certificate or a public certificate that includes a particular host\domain name).

Exchange Online- characters of mail connectors - Force TLS -01

Exchange on-Premises server environment and Force TLS settings

Compared to Exchange Online, the management interface that we use for creating and configuring the mail connectors and the available options are less sophisticated vs. Exchange Online options.

Exchange on-Premises environment – send connector

The available option that we can use for configuring Exchange on-Premises Send connector is identical to Exchange Online options.

The main difference is that the configuration settings that relate to the need to identify the “other side” (the mail server, which Exchange on-Premises address) by asking the server to prove his identity by providing a sever certificate, will need to be configured by using PowerShell and not by using the Exchange on-Premises graphical management interface.

Exchange on-Premises environment – Receive connector

When relating to the options that are available for configuring the Exchange on-Premises Receive connector, we don’t have the option for configuring an option for identifying the “other side” (external mail server that addresses Exchange on-Premises) by requiring a server certificate.

The only way that we can use for identifying the other side is by configuring an IP address or IP address range that represents the other side.

Exchange on-Premises - characters of mail connectors - Force TLS -02

Scenario description – implementing Force TLS configuration between two mail infrastructures.

To make the required technical steps more “alive”, let’s based on a scenario that has the following characters:

Characters of organization A

An origination that hosts his mail infrastructure in Office 365 by using the Exchange Online and the EOP (Exchange Online Protection infrastructure).

The public domain name of the organization A is – o365pilot.com

Characters of organization B

Organization B, use Exchange on-Premises infrastructure.

The public domain name of organization B is – thankyouforsharing.org

The task

The business need is to create the required mail infrastructure in which we can ensure that the mail flow between this organizations, must be encrypted by using TLS (there should be no option for send E-mail using a standard SMTP protocol).

To be able to fulfill this requirement, we need to configure the option of Force TLS on both sides.

An additional mandatory requirement is that each of the parties will be able to identify the mail server, which he addresses or the mail server which addresses him.

For example-

  • Outgoing mail – when organization A sends E-mail message to organization B, the mail server of the organization A, need to be sure beyond a reasonable doubt, that the “talk” with the “real mail server” of organization B.
  • Incoming mail – when organization A mail server is addressed by the mail server of organization B, the mail server of the organization A need to be sure beyond a reasonable doubt, that the “talk” with the “real mail server” of organization B.

A quick reminder

  • Organization A uses the public domain name org and the mail infrastructure is hosted at Exchange Online.
  • Organization B uses the public domain name com and the mail infrastructure is hosted at Exchange on-Premises.

Exchange on-Premises |Force TLS |The required configuration.

1. Exchange on-Premises incoming mail

The requirements of the Exchange on-Premises incoming mail, will be implemented by creating a new Receive connector that will apply the following requirements:

When the partner mail server that represents the o365pilot.com recipients addresses the Exchange on-Premises server, the mail flow must be implemented using a secure communication channel.

The Exchange on-Premises will “agree” to accept the mail only when the following requirements fulfilled:

  • The mail communication will need to be implemented by using encrypted communication line (TLS).
  • The “external server” (Exchange Online) must support TLS.
  • The “external server” (Exchange Online) must be identified by using a specific IP address.

Note – notice that the Exchange on-Premises Server Receive connector doesn’t include a configuration option to identify the other mail serve by using a server certificate.

2. Exchange on-Premises – outgoing mail

When the Exchange on-Premises needs to send E-mail message to some recipients with a domain name – o365pilot.com (a recipient who hosted at Exchange Online), the Exchange on-Premises server will “agree” to create the mail flow only when the following terms will fulfilled:

  • The mail communication will need to be implemented by using encrypted communication line (TLS).
  • The “external server” (Exchange Online) must support TLS.
  • The “external server” (Exchange Online) must identify himself using a trusted public certificate.
  • The public certificate of the “external server” must include a specific host name that will approve the identity of the mail server – *.outlook.com

Note – later in the section xxx, we will discuss the meaning of this domain name because the Exchange Online server cannot use a public certificate with a specific Office 365 tenant domain name.

Next article

The next article is Configure Force TLS in Exchange Online environment | Settings of outbound connector | Part 6#12).

o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *