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
The use of Transport rule for implementing the option of Force TLS comes in flavors:
Option 1 – using a “simple” TLS Transport rule, in which define that the mail communication with the “destination mail server” must be encrypted using TLS if a specific condition is realized.
Option 2 – using the option of Transport rule + Conditional Mail Routing.
This option is based on a combination of two separated Exchange components: Transport rule + mail connector.
The option of – Conditional Mail Routing “bind” mail connector to an Exchange Transport rule, and by doing so, enables us to define more specific settings that relate to the TLS communication channel that will need to be implemented between our mail server and the destination mail server.
When using option of – “simple” TLS Transport rule, which will “enforce” the use of TLS, we cannot define specific TLS parameters that are related to the communication with the “other mail server”.
I try to look for information about the specific actions that will be implemented when the transport rule “enforce” TLS, but I couldn’t find the information.
The logical assumption is that when we use the transport rule that Force TLS, the transport rule will ensure that the mail communication is secured by using the TLS protocol but, there is no option to configure a specific setting that relates to the TLS session such as the option of enforce a requirement in which the external mail server will need to prove his identity by providing a public certificate and so on.
When we use option 2 (Conditional Mail Routing) by using a combination of Transport rule + mail connector, the advantage is that we can use the Exchange Online mail connector for configuring a very specific setting that relates to the TLS communication channel such as – the conditions in which the “other mail server” will need to prove his identity by providing a trusted certificate and additional requirements such as that the server certificate should include a specific host name or domain name.
The decision about which option to use depends on your business need and the specific scenario.
Case 1 – In case that the main concern is that the communication channel between your mail server (Exchange Online in our scenario), and the “other mail server” will be encrypted and, there is no specific need to Identify beyond doubt the “other side” option 1 is quite enough.
Case 2 – In case that the main concern is that the communication channel between your mail server (Exchange Online in our scenario), and the “other mail server” will be encrypted + we need to identify and approve the “other mail server”, option 2 needs to be implemented because we will set the required TLS configuration settings on the Exchange Online mail connector.
The subject of the current article and the next article
- In the current article, we will review the required steps that are needed for creating a “simple” TLS Transport rule.
- In the next article – Implementing Force TLS by using Transport rule & Conditional Mail Routing | Exchange online | Part 11#12, we will review the required steps that are needed for creating a Transport rule + Conditional Mail Routing.
Note – as mentioned, the option for using the transport rule for implementing Force TLS is supported in Exchange Online server and Exchange 2013 on-Premises but in the current article, we will relate only to the Exchange Online infrastructure.
Implementing Force TLS using mail connector versus Implementing Force TLS using Transport rule
In the former articles in this article series, we have reviewed how to implement the option of Force TLS using mail connectors.
The “trigger” that activates the mail connector is quite simple – mail that is sent from a specific domain name (outgoing mail) or mail that is sent from a specific IP address (incoming mail).
In some scenarios, this “trigger” can fulfill our needs, but in other scenarios, we will need to use more “sophisticated triggers” that will activate the option of Force TLS.
The good news is that – in Exchange Online (and Exchange 2013 on-Premises server); we have this ability to use implemented the option of Force TLS by Define a simple or a complicated “condition”, which will activate the option of Force TLS using Transport rule.
The Exchange Transport rule feature is a very sophisticated “rules engine” that enables us to configure nearly endless mail flow scenarios.
The “condition” that triggers the Force TLS option can be very simple or very complicated, and we can choose the condition from a variety of options such as specific recipient, specific sender, group memberships, specific mail subject and so on.
In the following screenshot, we can see an example of a range of possibilities:
The basic logic of Exchange transport rule
The logic of Exchange transport rule is based on the following logic:
IF X (the condition), THEN Y (the action).
When using option 1 – “simple” TLS Transport rule, the condition that we define, will be the “trigger” that will activate the requirements of Force TLS
When using option 2 – Conditional Mail Routing Transport rule, the condition that we define, will be the “trigger”, the Conditional Mail Routing Transport rule will “activate” the Exchange mail connector and the Exchange mail connector will be configured to use Force TLS + a specific setting that relates to the TLS communication channel.
Scenario description |Force TLS option using an Exchange Online Transport rule
Our scenario characters are as follows: our organization is hosted at Exchange Online and it represented by the public domain name – o365pilot.com
We have a business partner, which use the domain name – thankyouforsharing.org
Bob ([email protected]) is the account manager of our company, and we need to ensure that each time that bob sends E-mail message to the account manager of our business partner, to a recipient named – [email protected], the mail communication must be implemented over a secure communication channel meaning -using TLS protocol for encrypting the communication line.
Creating an Exchange Online TLS transport rule
In the following section, we will demonstrate the steps that are needed for configuring “simple TLS Transport rule.
The steps that need to implemented are as follows:
- Login to Exchange Online admin center
- On the left bar menu, choose the mail flow menu
- On the top bar menu, choose the rules menu
- Click on the plus sign to create a new mail connector
- Choose the option – Create a new rule…
- In the *Name text box, add a descriptive name that is suitable for your needs.
- In the “Apply this rule if…” box chose the option The Sender is…
In our specific scenario, we want to ensure that when [email protected] send an E-mail message to his business partner, the mail must be “transferred” using TLS.
Choose the required recipient name and, choose add ->
An important issue that I would like to emphasize is that the Exchange Online transport rule wizard interface is a little tricky!
By default, the wizard interface of the transport rules will display only a limited set of options.
To “reveal” the additional options that are available, click on the More options… link
Now we can see that a “new button” appears named- add condition.
Click on the add condition option.
- In the “Apply this rule if…” box choose the option The recipient… and on the sub menu choose – is this person.
As mentioned, we want to use the option of Force TLS each time that bob will be sent an E-mail message to the recipient named- [email protected]
Most of the times, in case that the destination recipient is an external recipient, the recipient name will not appear in the GAL (Global address list).
To be able to add the E-mail address of the destination recipient, we will write the E-mail address in the check name text box
Until now, we have configured the first part of the Exchange Online transport rule, the part which defines the “condition” (IF X).
Now, we are getting to configure the second part which define is the “action” (THEN Y).
In the option box – *Do the following… choose the menu – Modify the message security… and in the sub menu choose the option – Require TLS Encryption.
In the following screenshot, we can see the result. The Exchange Online transport rule includes all the required conditions and the actions.
It’s important to emphasize that the Exchange Online TLS transport rule doesn’t tell us how he is going to implement the TLS communication with the “other side.”
For example, we do not know how the Exchange Online server locates the destination mail server (I know that the answer is by looking for an MX record), and we don’t know if the Exchange Online requires from the destination server to prove his identity by providing a valid server certificate and so on.
Recap and the next article
In the current article, we have reviewed the required configuration setting for implementing the option of Force TLS using an Exchange Online transport rule.
As I mention, there is not clear information that answer, this question, and the logic assumptions are that Exchange Online will “enforce” the use of TLS, but, without the requirement for the destination mail server to prove his identity, etc.
Only in a scenario in which we need to set more accurately the nature of the TLS session between the Exchange Online and the destination mail server, we will need to add an additional component – Exchange Online outbound connector. This option will be reviewed in the next article (Implementing Force TLS by using Transport rule & Conditional Mail Routing | Exchange online | Part 11#12)
It is important for us to know your opinion on this article