Configuring the option of Force TLS in Exchange on-Premises environment |Part 4#12

In the current article, we will review the subject of Force TLS in Exchange on-Premises based environment.

In Exchange on-Premises based environment, we can choose to implement the option of Force TLS using two options.

1. Domain Security

This option defines a set of mail connectors and configuration settings that serve for creating a secure communication channel meaning, data encryption and, Mutual authentication, in a scenario in which the two parties are using Exchange on-Premises mail infrastructure.

In other words, we cannot use the option of Domain Security in case that the “other side” mail infrastructure is not based on Exchange server architecture.

The option of Domain Security (Mutual TLS) is implemented by activating an option named – DomainSecureEnabled

2. TlsAuthLevel

To be able to configure the option of Force TLS with non-Exchange on-Premises mail infrastructure, we will need to configure a specific parameter named –TlsAuthLevel.

Using the option of TlsAuthLevel enables us to define a mandatory need for using TLS and also, include the option for specifying that exact method that we want to use for identifying the “other party” that involved in the mail flow.

Exchange on-Premises vs. Exchange Online

Regarding the subject of Force TLS, there are a couple of major differences between the Exchange on-Premises environment and Exchange Online based environment.

1. Exchange Online doesn’t support the option of Domain Security future.

Although the Exchange Online architecture based on Exchange 2013 architecture, the Exchange Online mail infrastructure is different from the Exchange on-Premises architecture.

In case that we need to implement a scenario of Force TLS between Exchange on-Premises mail infrastructure and Exchange Online mail infrastructure, we will need to use the “other option” named – TlsAuthLevel.

2. Management interface

In Exchange on-Premises based environment, the only way of configuring the option of Force TLS using the TlsAuthLevel parameter is by using the PowerShell command interface.

In Exchange Online based environment, the process of configuring Force TLS is implemented by using the Exchange Online web admin graphic interface.

The setting of the Force TLS is implemented by using a graphical wizard, which we use for configuring all the required parameters that we need for Force TLS.

The Exchange Online includes the option to set all the required settings for Force TLS by using a PowerShell command interface but, most of the time we will use the Exchange Online web admin graphic interface.

Configuring TLS settings in Exchange on-Premises environment and mix mail environment | The challenges

Before we begin with the description of Force TLS configuring in Exchange on-Premises based environment, it’s important that we will be aware of a couple of “obstacles” that can easily lead to confusion and disorientation.

• The difference between Exchange GUI interface and Exchange PowerShell – the Exchange Graphic interface doesn’t include all the options that exist when using the Exchange PowerShell. Some of the options that relate to the TLS settings exists only when using PowerShell.
• The difference between Exchange versions, GUI interface – in our article, we will provide examples of the TLS configuration by using the interface of Exchange 2010 on-Premises server. The logic that is implemented in Exchange 2013 on-Premises are similar but, there are some differences between the two Exchange version’s graphic interfaces.
• The difference between Exchange on-Premises and Exchange Online – technicality speaking, Exchange Online uses a very similar architecture and concept compared to an Exchange 2013 server. Regarding the subject of Mail connectors and TLS setting, the Exchange Online management option and configuration settings that relate to the Exchange mail connector and TLS setting, are significantly different from the “Exchange on-Premises” interface and options.
• The required setting that needs to be implemented on the Send + Receive connector and, the different parameter between the Send + Receive connector.
  Technically speaking, the configurations of TLS do not have a mandatory requirement of being configured on the booth of the Exchange connector meaning – Exchange Send + Receive connector.
  However, many times, the business requirement for using Force TLS will dictate the need for configuring the TLS on the booth of the connector. This “need” poses another difficulty because, the options and the interface of Exchange on-Premises Send connector vs. Exchange on-Premises Receive connector are not identical.

Configuring the option of force TLS in Exchange on-Premises environment

In the current article, we will review how to configure the option of “Force TLS” in Exchange 2010 on-Premises.

Just a quick reminder – by default, Exchange server is configured to use the option of opportunistic TLS.

• Each time that Exchange server tries to connect another mail server, he will try to establish the communication channel by using TLS.
• Each time that the external mail server tries to communicate with the Exchange server, the Exchange server will “offer” to establish the communication channel by using TLS.

By default, Office 365 sends mail using TLS encryption, provided that the destination server also supports TLS. If your partner organization supports TLS, you only need to create a connector if you want to enforce certain security restrictions – for example, you always want TLS applied, or you require certificate verification whenever mail is sent from your partner to your organization.

[Source of information – Set up connectors for secure mail flow with a partner organization]

The question that can appear in our mind could be:

Q: If Exchange is configured to use the option of opportunistic TLS and always try to create a secure communication link, why or when should I use the option of Force TLS?

A: The answer to this question could be

1. The business needs to ensure that only TLS communication is enabled.

Security need or a specific regulatory requirement, which dictate the need to verify that the communication channel between our Exchange server and the destination server is an encrypted communication channel that uses the TLS protocol.

In other words – we are not willing to take the chance that the communication link to a particular organization or a specific mail server will implement by using non-encrypted protocols such as SMTP. It’s a black-and-white scenario, in which the only we that we agree to create the mail communication channel is – by using TLS protocol.

2 The need to identify the “other mail server.”

Besides the mandatory need for creating a secure mail communication channel, we want to define additional security settings that will relate to the TLS session with the destination mail server.

For example, each of the mail servers, need to have a certificate which will use for encrypting the data that flow in the communication channel and can use for authentication – each mail server can “present” his certificate as a way for proof his legitimate identity.

In some scenarios, besides of the mandatory need for encrypting the communication channel by using TLS, we also need to prove beyond doubt, the identity of the “other mail server” by specifying a particular parameter that should appear on his server certificate.

For example, verify that the destination mail server uses a public certificate and checks that his host name appears in the public certificate.

To be able to fulfill these requirements, we will need to use the option of Force TLS.

1. Configuring the option of Domain Security (Mutual TLS) in Exchange on-Premises environment

As mentioned, in an Exchange-based environment, there are two flavors of the configuring of Force TLS using mail connectors.

1. Domain Security (Mutual TLS)
2. TlsAuthLevel

In the current section, we will briefly review the Exchange on-Premises feature – Domain Security and in the next section, we will review the option of TlsAuthLevel
The option of Domain Security is relevant only for a scenario in which the “two sides” uses Exchange on-Premises mail infrastructure.

The option of Domain Security (Mutual TLS) can be used in Exchange 2010 and 2013 server version.

A proper disclosure is, that I could get a clear and informative information about the specific parameters that are implemented when using the option of Domain Security (Mutual TLS).

The solution of Domain Security (Mutual TLS) is implemented in a scenario that described as “partner relationship”. Two different Exchange organization that wants to build a secure communication channel between them.

The required configurations for Domain Security (Mutual TLS), need to be implemented in each of the “sides” that are involved in the relationships.

When using the Domain Security (Mutual TLS) option, the Exchange clients such as Outlook are also involved in the process, and they have the ability to “understand” when an E-mail address was sent from the “other organization” that uses Domain Security (Mutual TLS) with “our Exchange organization”.

In the following diagram, we can see an example of the Domain Security (Mutual TLS) between two Exchange based organizations.

The “trust” is created between Exchange organization named o365pilot.com and Exchange organization (other organization) that is represented by the public domain name – thankyouforsharing.org

We will not get into the specific details of the required configuration for using the option of Domain Security (Mutual TLS)

However, in general, to accomplish the task of configuring the option of Domain Security (Mutual TLS) in Exchange on-Premises environment, we will need to create two mail connectors:

Send connector and Receive connector that will be used to serve the incoming and outgoing mail flow with the “partner”.

Phase 1#2 – configuring the option of Enable domain security |Send + Receive connectors

When we create the required Send connector, in the Network tab we will need to check the option – Enable domain security (mutual Auth TLS).

When we create the required Receive connector, in the Network tab we will need to check the option – Enable domain security (mutual Auth TLS).

Phase 2#2 – using PowerShell command Set-TransportConfig

We will need to use two PowerShell commands, which will set the required parameters on the Send connector and Receive connector

In our scenario, the PowerShell command that we will use for configuring the Domain Security (Mutual TLS) with the “other Exchange organization” that is represented by the domain name thankyouforsharing.orgis:

Set-TransportConfig -TLSSendDomainSecureList thankyouforsharing.org

The next PowerShell command will configure the Receive connector

Set-TransportConfig –TLSReceiveDomainSecureList o365info.com

Attached some quotes from a Microsoft article, about the subject of – Domain Security (Mutual TLS):

Mutual TLS Mutual TLS authentication differs from TLS as TLS is usually deployed. Typically, when TLS is deployed, it’s used only to provide confidentiality in the form of encryption. No authentication occurs between the sender and receiver.
Additionally, sometimes when TLS deployed, only the receiving server is authenticated. This deployment of TLS is typical of the HTTP implementation of TLS. This implementation,
where only the receiving server authenticated, is SSL.
With mutual TLS authentication, each server verifies the identity of the other server by validating a certificate that’s provided by that other server. In this scenario, where messages are received from external domains over verified connections in an Exchange 2013 environment, Microsoft Outlook displays a Domain Secured icon.
Domain Security Domain Security is the set of features, such as certificate management, connector functionality, and Outlook client behavior that enables mutual TLS as a manageable and useful technology. Domain Security isn’t supported when outbound email is routed through an Exchange 2013 Client Access server.
DomainSecureEnabled
The DomainSecureEnabled parameter is part of the process to enable mutual Transport Layer Security (TLS) authentication for the domains serviced by this Send connector. Mutual TLS authentication functions correctly only when the following conditions met:
The value of the DomainSecureEnabled parameter must be $true.
The value of the DNSRoutingEnabled parameter must be $true.
The value of the IgnoreStartTLS parameter must be $false.
The wildcard character (*) is not supported in domains that are configured for mutual TLS authentication. The same domain must also be defined on the corresponding Receive connector and in the TLSReceiveDomainSecureList attribute of the transport configuration.
by validating a certificate that’s provided by that other server, so clients are not included at all. We establish secure SMTP channel between two Exchange Servers, usually over the Internet.
Mail client such as Outlook, and Outlook Web App, will be aware that Domain Security established. A green icon with a check mark will be shown on each message exchanged between servers on which Domain Security is implemented.
Domain Security refers to the set of functionality in Microsoft Exchange Server 2010 and Microsoft Office Outlook 2007 that provides a relatively low-cost alternative to S/MIME or other message-level security solutions. The purpose of the Domain Security feature set is to provide administrators a way to manage secured message paths over the Internet with business partners. After these secured message paths configured, messages that have successfully traveled over the secured path from an authenticated sender are displayed to users as Domain Secured in the Outlook and Microsoft Office Outlook Web App interface.
Domain Security uses mutual Transport Layer Security (TLS) authentication to provide session-based authentication and encryption. Mutual TLS authentication differs from TLS as it’s usually implemented. Typically, when TLS implemented, the client verifies that the connection securely connects to the intended server by validating the server’s certificate. This is received as part of TLS negotiation. In this scenario, the client authenticates the server before the client transmits data. However, the server doesn’t authenticate the session with the client.
With mutual TLS authentication, each server verifies the connection with the other server by validating a certificate that’s provided by that other server. In this scenario, where messages are received from external domains over verified connections in an Exchange 2010 environment, Outlook 2007 displays a Domain Secured icon.

2. Configuring force TLS in Exchange using TlsAuthLevel

In this section, we will review the implementation of Force TLS in Exchange on-Premises based environment using the option of TlsAuthLevel.

As mentioned, the use of the “TlsAuthLevel” will be implemented in a scenario in which the “other mail server” is not an Exchange-based server or not Exchange on-Premises based server.

For example, in case that we need to configure the option of Force TLS between our Exchange on-Premises Server and Exchange Online server, we will need to use the option of TlsAuthLevel, because despite the fact that Exchange Online based on the Exchange server architecture, Exchange Online is different from the Exchange on-Premises server.

The current section includes two parts

1. The required configuration for setting the option of Force TLS for Exchange on-Premises Send connector.
2. The required configuration for setting the option of Force TLS for Exchange on-Premises Receive connector.

1. Exchange on-Premises Send connector | Setting the option of force TLS

In the current section, we will be focused on the required configuration setting of Force TLS in a scenario in which the “other side” is not a necessary Exchange on-Premises server.

In this scenario, we will need to use a PowerShell command that will help us to set the required values for the parameter – TlsAuthLevel

When we turn on the TlsAuthLevel parameter, we “Turn on” the option of Force TLS.

The “activation” of the TlsAuthLevel parameter is followed one of three possible options that configure the relationship with the “other mail server”.

We can choose from three possible options as a value for the TlsAuthLevel

Option 1 – EncryptionOnly

The option of – EncryptionOnly, is suitable for a scenario in which the destination mail server uses a certificate that cannot use for “identify” the mail server. For example, a scene in which the target mail server uses a self-signed certificate.

In this scenario, the certificate of the destination mail server will use only for encrypting the data that passes via the communication channel.

In other words, when we configure the EncryptionOnly option, the meaning is that we don’t need to identify the mail server on the other side by checking his server certificate. The primary focus is on the need to encrypt the communication channel by using TLS.

Option 2 – CertificateValidation

The option of – CertificateValidation, is suitable for a scenario in which source mail server (Exchange server in our scenario) needs to verify the identity of the destination mail server.

The destination mail server can prove his identity by providing a public certificate that created by Public CA (certificate authority).

Option 3 – DomainValidation

The option of – DomainValidation can be considered is the most restrictive option.

In this case, the mandatory requirement will include the following sections:

• The need for encrypting the data that passes via the communication channel.
• The need to identify the destination server. The destination mail server will need to provide a legitimate public certificate that was created by CA.
• The certificate that the destination server provides must include one of the following options: the FQDN or the domain name that is configured by the additional parameter TlsDomain

When we use the option of DomainValidation we will also need to provide the additional value of the TlsDomain.

When using the option of TlsDomain, we will need to “activate” additional parameter named RequireTls

In the following diagram, we can see the variety of option and combination that relates to Force TLS.

To be able to demonstrate the required PowerShell command syntax that we need to use when we want to configure the option of Force TLS, let’s use the following scenario:

We want to implement a Force TLS configuration with our company partner who uses the public domain name – contoso.com

In our scenario, we have all created a dedicated Send connector that route E-mail message sent to the recipient from the domain contoso.com

The name of the send connector is – Contoso

Scenario 1 – using the option of Force TLS only for the purpose of encrypting the mail flow

In this scenario, there is no need for identifying the other mail server.

The TlsAuthLevel level will be set by configuring the parameter EncryptionOnly

The PowerShell command syntax is:

Set-SendConnector -Identity Contoso -TlsAuthLevel EncryptionOnly

Scenario 2 – encrypting the mail flow + request for a valid server certificate from the other mail server

In this scenario, we need for identifying the other mail server. The other mail server will need to provide a valid server certificate.

The TlsAuthLevel level will be set by configuring the parameter CertificateValidation

The PowerShell command syntax is:

Set-SendConnector -Identity Contoso -TlsAuthLevel CertificateValidation

Scenario 3 – encrypting the mail flow + request for a valid server certificate from the other mail server + verify that the server certificate includes a specific hostname

In this scenario, we want to use the option of Force TLS and besides the need to encrypt the communication line, we want to be able to identify the Contoso mail server, verify that he uses trusted public certificate and in addition, verify that the server certificate includes the domain name – contoso.com

The TlsAuthLevel level will be set by configuring the parameter DomainValidation

When using the option of – DomainValidation, we will need to set two additional parameters

TlsDomain parameter – the TlsDomain parameter is used for defining the specific host name or the domain name that needs to be included in the server certificate that the “other mail server” presented as a proof of his identity.
RequireTls $true

The PowerShell command syntax is:

Set-SendConnector -Identity contoso3 -RequireTls $true -TlsAuthLevel DomainValidation -TlsDomain *.contoso.com

Attached a quotation from a Microsoft TechNet article:

TlsAuthLevel
The TlsAuthLevel parameter specifies the TLS authentication level that used for outbound TLS connections established by this Send connector. Valid values are:
EncryptionOnly: TLS is used only to encrypt the communication channel. No certificate authentication performed.
CertificateValidation: TLS is used to encrypt the channel and certificate chain validation, and revocation lists checks performed.
DomainValidation: In addition to channel encryption and certificate validation, the Send connector also verifies that the FQDN of the target certificate matches the domain specified in the TlsDomain parameter. If no domain specified in the TlsDomain parameter, the FQDN on the certificate is compared with the recipient’s domain.
You can’t specify a value for this parameter if the IgnoreSTARTTLS parameter is set to $true, or if the RequireTLS parameter is set to $false.

[Source of information – Set-SendConnector ]

The TlsDomain parameter specifies the domain name that the Send connector uses to verify the FQDN of the target certificate when establishing a TLS secured connection.
This parameter used only if the TlsAuthLevel parameter set to DomainValidation.
A value for this parameter is required if:
The TLSAuthLevel parameter set to DomainValidation.
The DNSRoutingEnabled parameter is set to $false (smart host Send connector).

[Source of information – Set-SendConnector ]

2. Exchange on-Premises Receive connector | Setting the option of force TLS

Regarding the required configuration that is needed for implementing the Force TLS option on the Exchange on-Premises Receive connector, we will need to use a combination of two parameters:

1. AuthMechanism
2. RequireTLS – this value “activate” the option of Force TLS

In the following screenshot, we can see an example of the default parameters of Exchange on-Premises receive connector.

We can see that the parameter – AuthMechanism includes a couple of options, including TLS.
In addition, we can see that default value of the RequireTLS parameter is set to False>.

In our scenario, we want to implement the option of Force TLS regarding mail that is sent to us by a partner who is represented by the domain name – thankyouforsharing.org

We have already created Receive connector on Exchange on-Premises server named – EX01 and the connector name is – thankyouforsharing.org

To be able to configure the Exchange on-Premises Receive connector to use Force TLS, we will need to set the value of the RequireTLS parameter to be true.

The PowerShell commands that we will use in our scenario is:

Set-ReceiveConnector EX01\<strong><em>thankyouforsharing-receive</em></strong> -RequireTLS $true

Attached some quotes from Microsoft article:

The AuthMechanism parameter specifies the advertised and accepted authentication mechanisms. The authentication options are None, Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer, and ExternalAuthoritative. You can enter multiple values for the AuthMechanism parameter by separating the values with commas.
If the RequireTLS parameter is set to $true, the AuthMechanism parameter must be set to TLS (Transport Layer Security). If you set the AuthMechanism parameter to BasicAuthRequireTLS, you must also select BasicAuth and TLS.
The AuthMechanism parameter value ExternalAuthoritative may only coexist with the value Tls. If you set the AuthMechanism parameter to ExternalAuthoritative, the PermissionGroups parameter must also have the value

Next article

The next article (Force TLS | Exchange Online environment versus Exchange on-Premises environment | Part 5#12) in the TLS article series, is dedicated to the subject of – the differences that exist between the Exchange on-Premises based environment vs. the Exchange Online based environment regarding mail connectors and TLS settings and a description of the scenario characters that we will use on 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.