Configure Force TLS on Exchange on-Premises environment | Settings of Receive connector | Part 9#12 5/5 (1)

11 min read

In the current article, we will review the required configuration settings for implementing Force TLS in Exchange on-Premises based environment.

In our specific scenario, we need to configure the Force TLS option for the “incoming mail flow”.

The meaning is – mail that sent from external mail server to the Exchange on-Premises server that represents a particular domain name.
The Force TLS configuration setting will be applied to the Receive connector.

Force TLS on the Inbound connector | Scenario description

The complete scenario description appears in the former article

In this article, we will implement the following part from the complete scenario:

This scenario, is the fourth part of our complete scenario, in which we need to implement the configuration of Force TLS on two different partner organizations.

A quick reminder for our scenario:

  • We have a business relationship with another organization (partner).
  • Our organization use Exchange on-Premises mail infrastructure.
  • The partner mail infrastructure is hosted at Exchange Online.
  • The partner public domain is – o365pilot.com

We want to ensure that every mail that is sent from our business partner to our recipients, will be encrypted and in addition, we want to be able to identify the “partner mail server” so we will be able to know that the mail server is Legitimate and can be trusted.

Specific characters of Exchange on-Premises Inbound connector

Versus the other scenario that we have reviewed in the former articles, which relate to Exchange Online infrastructure and Exchange on-Premises Send connector, the main disadvantage of the Exchange on-Premises Receive mail connector is that we are not able to choose the specific verification method of the “other mail server”.

For example, we cannot use the option of identifying the external server by asking for a server certificate.

The only way that we can use for the identification of the external mail server is by IP address.

The method in which we identify the “other mail server” by IP address, can become complicated, in a scenario in which the external mail server uses a broad range of IP address and also, a dynamic environment in which the IP address of the external mail server can often be updated.

This is the exact scenario “issue” that we have when our business partner is hosting his mail infrastructure on the Exchange Online based environment.

In this situation, we will need to find a method for “knowing” what is the particular IP address or IP address range, of the Exchange Online server which represents the mail server of our partner.

In the following diagram, we can see an illustration for the business requirement – using the option of Force TLS for incoming mail, which sent from “external mail server”.

Exchange on-Premises -Force TLS - inbound Connector

How to identify the external mail server?

To be able to fulfil the requirement, in which each E-mail message sent by an external mail server (Exchange Online in our scenario), to our recipients, will be encrypted, we will create a new Receive mail connector.

The way that we use for identifying the external mail server is – by adding the IP address or the IP range of the “external mail server” (Exchange Online in our scenario) to the Exchange on-Premises Receive mail connector

Exchange on-Premises -Force TLS - creating a new Inbound connector

Exchange on-Premises |Creating the required configuration for Force TLS | Receive connector

Phase 1#2 – creating a Receive connector using the Exchange management interface

The following demonstration is implemented by using the Exchange 2010 server version.

Open the Exchange management console. Choose Server configuration, Hub Transport.

Right-click on the empty space and choose – New Receive Connector…

Creating the required configuration for force TLS - Exchange on-Premises – Receive connector -01

In the Name text box, write the name that is suitable to your needs.

My recommendation is to use a descriptive name so in the future, in the case of a troubleshooting process, it would be easy to understand the purpose of a particular mail connector.

In the option box – select the intend using for this Receive connector, choose custom

Creating the required configuration for force TLS - Exchange on-Premises – Receive connector -02

The next screen, present information about the port number that Exchange on-Premises uses for “listing” to incoming communication (port 25 by default) and the Exchange on-Premises IP address that is “attached” to the Receive connector.

Leave the default configurations and move on to the next screen.

Creating the required configuration for force TLS - Exchange on-Premises – Receive connector -03

In the following screenshot, we can see that by default, the Receive connector will apply our specific setting to every external mail server that tries to address the Exchange on-Premises.

We will need to remove this default setting because in our scenario, we want to “activate” the Receive connector only in a scenario in which a specific mail server tries to address the Exchange on-Premises server (our partner mail server).

Click on the X sign to remove the default IP range
Creating the required configuration for force TLS - Exchange on-Premises – Receive connector -04

The main challenge in our scenario is – how to get the IP address that represents the Exchange Online infrastructure.

Technically, we can use a simple operation such as using the nslookup command tool for getting the MX record and the host name of the Exchange Online that represent our partner organization.

However, it’s important to emphasize that this “solution” is not a complete solution because the Exchange Online environment is represented by many IP addresses, and even if we “fetch” a specific IP address, the IP address can be changed or updated.

Let’s start with the simplest process in which we “carry” the IP address of the Exchange Online server which represents the domain name – o365pilot.com and later on; we will review more advanced step, which will help us to define all the IP ranges that are used by Exchange Online infrastructure.

Fetching the IP address of the Exchange Online server

In our scenario, the public domain name of our business partner is – o365pilot.com

In the first step, we will use the nslookup tool for getting the host name of the Exchange Online server who represents o365pilot.com

  • Open the command prompt and type – Nslookup
  • Type set type=mx
  • In our specific scenario, we would like to know what the MX for the domain – o365pilot.com
  • Type the domain name

In the following screenshot, we can see that the hostname of the mail server (Exchange Online) that represents the domain name – o365pilot.com is: o365pilot-com.mail.protection.outlook.com

Creating the required configuration for force TLS - Exchange on-Premises – Receive connector -05

To be able to get the IP address of this hostname, we will open a new command prompt and ping using the hostname – o365pilot-com.mail.protection.outlook.com

In the following screenshot, we can see the result, the IP address of the host name
o365pilot-com.mail.protection.outlook.com is – 213.199.154.87

Creating the required configuration for force TLS - Exchange on-Premises – Receive connector -06

In the Remote Network setting screen, add the IP address – 213.199.154.87

Creating the required configuration for force TLS - Exchange on-Premises – Receive connector -07

On the next screen, we can see a summary of the configuration settings.

Creating the required configuration for force TLS - Exchange on-Premises – Receive connector -08

On the next screen, we can see the PowerShell commands that used for creating the required configuration settings.

Creating the required configuration for force TLS - Exchange on-Premises – Receive connector -09

In the current phase, a new Receive connector was created but, it’s important to emphasize that the new Exchange on-Premises Receive connector, doesn’t include all the required configurations, which we need to implement in our scenario.

In our scenario, we will need to “activate” the option of force TLS that is not activated by default.

To be able to display the settings of the new Receive connector that was created in the former phase, we will use the following PowerShell command:

Get-ReceiveConnector “EX01\Force TLS – Mail sent from o365pilot.com must be encrypted”

In the following screenshot, we can see the Receive connector settings.

The AuthMechanism is set for TLS

The value of RemoteIPRanges includes the IP address that was set in the former phase (the Exchange Online IP address)

Notice that the value of – RequireTLS is False. The meaning is that the option of Force TLS is not activated.

Reviewing the properties of an Exchange on-Premises custom receive connector -01

We will need to update two additional settings for the Exchange on-Premises Receive connector

1. PermissionGroups – update the parameter of the permissionGroups to allow Anonymous access (access by non-authenticated mail server) that will be set by using the value AnonymousUsers

2. RequireTLS – set the value of RequireTLS is set to true

To be able to implement these settings we will use the following PowerShell command:

Set-ReceiveConnector “EX01\Force TLS – Mail sent from o365pilot.com must be encrypted” -RequireTLS $true –permissionGroups AnonymousUsers

Reviewing the properties of an Exchange on-Premises custom receive connector -02

In the following screenshot, we can see that the value was updated.

  1. PermissionGroups – the value of PermissionGroups was updated to AnonymousUsers
  2. RequireTLS – the value of RequireTLS was set to true

Reviewing the properties of an Exchange on-Premises custom receive connector -03

RequireTLS parameter

The RequireTLS parameter specifies that all messages received by this connector require TLS transmission. Valid values for this parameter are $true or $false. The default value is $false. When the RequireTLS parameter is set to $true, all messages received by this connector require TLS transmission.

[Source of information – New-ReceiveConnector]

The PermissionGroups parameter specifies the groups or roles that can submit messages to the Receive connector and the permissions assigned to those groups. A permission group is a predefined set of permissions granted to well-known security principals.
The valid values for this parameter are as follows: None, AnonymousUsers, ExchangeUsers, ExchangeServers,ExchangeLegacyServers Partners, and Custom. The default permission groups assigned to a Receive connector depend on the connector usage type that was specified by the Usage parameter when the Receive connector was created. For more information about Receive connector usage types, see Receive connectors.

[Source of information – New-ReceiveConnector]

Fetching the IP address range of Exchange Online infrastructure

As mentioned, the task of configuring the specific IP address that is used by the Exchange Online server is a little tricky because, we don’t have a clear information about this IP address.

The good news is that Exchange Online enables us to get this required information by using a remote PowerShell session for connecting to Exchange Online infrastructure and, uses a particular PowerShell command named – Get-HybridMailflowDatacenterIPs, that will help us to “fetch” the complete list of Exchange Online IP ranges.

To be able to finalize the task of getting the required IP ranges, we will use a three-step process.

Step 1#3 – Creating a remote PowerShell session to Exchange Online

In the first step, we will use the Exchange on-Premises PowerShell console for, creating the required remote PowerShell session to Exchange Online.

Notice that to be able to complete the remote PowerShell session; you need to provide Office 365 global administrator credentials.

Note – if you require more information about how to create a remote PowerShell to Exchange Online, read the following article – Connect to Exchange Online using PowerShell

In the case that you don’t have Office 365 accounts, instruct your partner how to implement this procedure.

Step 2#3 – getting the list of Exchange Online IP ranges

When we use the PowerShell command Get-HybridMailflowDatacenterIPs the information is displayed in a non-clear presentation.

To be able to optimize the PowerShell command output from the >Get-HybridMailflowDatacenterIPs command, we will use the additional PowerShell parameter

$FormatEnumerationLimit =-1

The combination will look like

$FormatEnumerationLimit =-1

Get-HybridMailflowDatacenterIPs

In the following screenshot, we can see the result- of the PowerShell command
Get-HybridMailflowDatacenterIPs, that we use for “fetching” all the available Exchange Online IP address ranges

Get the IP address of Exchange Online data center -01

To be able to save this information about a variable, we will define a variable named – $ip

Run the following PowerShell command:
$FormatEnumerationLimit =-1
$ip = Get-HybridMailflowDatacenterIPs

Get the IP address of Exchange Online data center -02

Just for curiosity, if you want to see the content of the $ip variable, all you need to do is just the type $ip

Get the IP address of Exchange Online data center -03

Step 3#3 – importing the Exchange Online IP range into the Receive connector

In our specific scenario, the new Receive connector name is “EX01\Force TLS – Mail sent from o365pilot.com must be encrypted

To be able to import the content of the $ip variable into the Receive connector setting, we will use the following PowerShell command

Get-ReceiveConnector “EX01\Force TLS – Mail sent from o365pilot.com must be encrypted” | Set-ReceiveConnector -RemoteIPRanges $ip.DatacenterIPs

In the following screenshot, we can see the result.

The Exchange on-Premises Receive connector was populated with the Exchange Online IP ranges.

Get the IP address of Exchange Online data center -04

Recap and the next article

In the current article, we have reviewed the required configuration setting for Force TLS that need to be implemented for “incoming mail flow” meaning, mail that is sent to Exchange on-Premises by an external mail server that represent a specific domain name (o365pilot.com).

The Force TLS settings were configured by using the Exchange on-Premises Receive Connector

In our scenario, the Force TLS setting will be “activated”, each time that E-mail message is sent from a recipient that uses the domain name – o365pilot.com

In the next article (Implementing Force TLS by using Transport rule | Exchange online | Part 10#12), we will review how to Implement Force TLS in Exchange Online environment using Transport rule.

Opportunistic TLS and Force TLS in Exchange environment | Article series index

Now it’s Your Turn!
It is important for us to know your opinion on this article

Summary
Configure Force TLS on Exchange on-Premises environment | Settings of Receive connector | Part 9#12
Article Name
Configure Force TLS on Exchange on-Premises environment | Settings of Receive connector | Part 9#12
Description
In the current article, we will review the required configuration settings for implementing Force TLS in Exchange on-Premises based environment.In our specific scenario, we need to configure the Force TLS option for the “incoming mail flow”.The meaning is – mail that sent from external mail server to the Exchange on-Premises server that represents a particular domain name.
Author
Publisher Name
o365info.com
Publisher Logo
Print Friendly

Related Post

Please rate this

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

Leave a Reply

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