In the current article, we will review the required configuration settings for implementing Force TLS…
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.
Table of content | Click to expand
Opportunistic TLS and Force TLS in Exchange environment | Article Series
- Using TLS in Exchange-based environment | Introduction | Part 1#12
- Opportunistic TLS versus Force TLS in Exchange-based environment | Part 2#12
- Exchange architecture and default opportunistic TLS settings | Part 3#12
- Configuring the option of Force TLS in Exchange on-Premises environment | Part 4#12
- Force TLS | Exchange Online environment versus Exchange on-Premises environment | Part 5#12
- Configure Force TLS in Exchange Online environment | Settings of outbound connector | Part 6#12
- Configure Force TLS in Exchange Online environment | Settings of inbound connector | Part 7#12
- Configure Force TLS on Exchange on-Premises environment | Settings of Send connector | Part 8#12
- Configure Force TLS on Exchange on-Premises environment | Settings of Receive connector | Part 9#12
- Implementing Force TLS by using Transport rule | Exchange online | Part 10#12
- Implementing Force TLS by using Transport rule & Conditional Mail Routing | Exchange online | Part 11#12
- Exchange Force TLS | Troubleshooting and verifying secure mail flow | Part 12#12
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”.
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 |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…
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
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.
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
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
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 – 22.214.171.124
In the Remote Network setting screen, add the IP address – 126.96.36.199
On the next screen, we can see a summary of the configuration settings.
On the next screen, we can see the PowerShell commands that used for creating the required configuration settings.
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.
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
In the following screenshot, we can see that the value was updated.
- PermissionGroups – the value of PermissionGroups was updated to AnonymousUsers
- RequireTLS – the value of RequireTLS was set to true
[Source of information – New-ReceiveConnector]
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.
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
The combination will look like
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
To be able to save this information about a variable, we will define a variable named – $ip
Run the following PowerShell command:
$ip = Get-HybridMailflowDatacenterIPs
Just for curiosity, if you want to see the content of the $ip variable, all you need to do is just the type $ip
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.
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.