Exchange Server 2010 : Setting Up Message Routing (part 4) - Configuring Foreign Connectors for Compliance & Using TLS and MTLS

5. Configuring Foreign Connectors for Compliance

Exchange Server 2010 Hub Transport servers use Foreign connectors to deliver messages to gateway servers that do not use SMTP to transmit messages. For example, third-party fax gateway servers are foreign gateway servers. A Foreign connector controls outbound connections from the Hub Transport server to the foreign gateway server. The outbound messages are put in a Drop directory on the Hub Transport server or in a network file share on a remote server. Each Foreign connector uses its own Drop directory. The foreign gateway server is configured to obtain messages from the Drop directory that is specified for the Foreign connector.

Foreign connectors that you create on Hub Transport servers are stored in Active Directory and are available to all Hub Transport servers in your Exchange organization. When a Hub Transport server in your organization routes messages to an address space configured on a Foreign connector, the message is delivered to a source Hub Transport server for that Foreign connector and is relayed to the destination domain.

You can specify several different Hub Transport servers as source servers for a Foreign connector to provide fault tolerance. In this case, you need to ensure that the Drop directory that is specified by the Foreign connector can be accessed by all Hub Transport servers designated as source servers for that Foreign connector.

Foreign gateway servers send messages into an Exchange Server 2010 organization by using the Replay directory on the Hub Transport server. Email message files in the Replay directory are submitted for delivery.

The address space for a Foreign connector specifies the recipient domains to which this connector routes email. You can specify either SMTP address spaces or non-SMTP address spaces. You can use the scope of a Foreign connector to control the visibility that connector within your Exchange organization. By default, all Foreign connectors you create can be used by all Hub Transport servers in your Exchange organization. You can, however, limit the scope of a Foreign connector so that it is usable only by other Hub Transport servers in the same Active Directory site.

5.2. Creating and Configuring a Foreign Connector

You can create a Foreign connector by entering an EMS command based on the New-ForeignConnector cmdlet on a Hub Transport server. You can configure an existing Foreign connector by using commands based on the Set-ForeignConnector cmdlet. In either case, the connector scope is specified by using the IsScopedConnector parameter. When the value of this parameter is set to $false, the connector can be used by all Hub Transport servers in the Exchange organization. When the value of the parameter is $true, the connector can be used only by Hub Transport servers in the same Active Directory site.

When you create or configure a Foreign connector, the AddressSpaces parameter specifies the domain names to which the Delivery Agent connector Foreign connector sends messages. In Exchange Server 2010, the syntax for specifying an address space is as follows:

<AddressSpaceType>:<AddressSpace>;<AddressSpaceCost>

The address space type can be SMTP, X400, or any other text string. If you omit the address space type, an SMTP address space type is assumed. For SMTP address space types, the address space that you enter must be RFC 1035 compliant, such as *.*.com, and *.adatum.com. For X.400 address space types, the address space that you enter must be RFC 1685 compliant, such as follows:

o=MySite;p=MyOrg;a=adatum;c=us

The valid input range for the address space cost is from 1 through 100. A lower cost indicates a better route. If you omit the address space cost, a cost of 1 is assumed. If you enter a non-SMTP address space that contains the semicolon character (;), you are required to specify the address space cost. If you specify the address space type or the address space cost, you must enclose the address space in quotation marks (“), for example, “SMTP:adatum.com;1”. You can specify multiple address spaces by separating the address spaces with commas, for example, adatum.com, fabrikam.com.

The following EMS command creates a Foreign connector named ForeignConnector01. The address space type is X.400, and the X.400 address space is c=US;a=Adatum;P=Contoso. The address space cost is 5, and the source Hub Transport server is VAN-EX1:

New-ForeignConnector -Name ForeignConnector01 -AddressSpaces "X400:c=US;a=Adatum;P=Conto
so;5" -SourceTransportServers VAN-EX1

					  

Figure 8 shows the output of this command.

You use EMS commands based on the Set-ForeignConnector cmdlet to configure an existing Foreign directory. For example, the maximum message size for a Foreign connector is unlimited. The following EMS command configures the maximum message size on this connector to be 50 MB:

Set-ForeignConnector -Identity ForeignConnector01 -MaxMessageSize 50MB


5.3. Delivery Agent Connectors

Exchange Server 2010 introduces the Delivery Agent connector. Like the Foreign connector, this can be used to route messages to foreign systems that do not use the SMTP protocol. When a message is routed to a Delivery Agent connector, the associated delivery agent performs the content conversion and message delivery. Delivery Agent connectors allow queue management of Foreign connectors and eliminate the need to store messages on the file system in a Drop directory. They provide greater control over the message delivery to the foreign systems.

These protocols and their associated certificates provide encrypted communications and end-point authentication over network connections. Server-to-server connections use MTLS for mutual authentication. On an MTLS connection, the server originating a message and the server receiving it exchange certificates from a mutually trusted certification authority (CA). The certificates prove the identity of each server to the other.

The TLS protocol enables clients to authenticate servers and (optionally) servers to authenticate clients. It provides a secure channel by encrypting communications. However, when TLS is deployed, it typically provides only encryption. Sometimes no authentication occurs between the sender and the receiver, and only the receiving server is authenticated. For example, SSL, which is an implementation of TLS, authenticates only the receiving server.

Exchange Server 2010 Setup creates a self-signed certificate, and TLS is enabled by default. You can clone this certificate to use it on additional servers or, if appropriate, replace it with certificates that are issued by a trusted third-party CA. Exchange Server 2010 attempts to use TLS for all remote connections, and all traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted using MTLS.

You can require TLS authentication on Send and Receive connectors. For example, the following EMS command creates a Receive connector for incoming messages on port 25 from the IP address range 10.10.0.1 through 10.10.0.24 and specifies that all messages coming from this range must use TLS:

New-ReceiveConnector -Name Secure -Bindings 0.0.0.0:25 -RemoteIPRanges 10.10.0.1-
10.10.0.24 -RequireTLS $true

					  

6.1. Generating and TLS Certificates

TLS and MTLS require a certificate for authentication of inbound connections to and outbound connections from a front-end server. Each Edge Transport server must have a certificate for MTLS communication with other servers on the network, in particular, Hub Transport servers.

You can use commands based on the New-ExchangeCertificate cmdlet to generate TLS keys, which consist of the TLS certificate and related private keys. You can specify certificate metadata that enables different services to use the same certificate and private key. This metadata is stored in fields in the resulting certificate. You can also generate a certificate request from a third-party or other public key infrastructure CA.

The subject name field is specified by using the SubjectName parameter. This information is used by DNS-aware services and binds a certificate to a particular server or domain name. A subject name is an X.500 distinguished name that consists of one or more relative distinguished names (RDNs). Table 4 lists frequently used RDNs for identifying organizations or server entities.

Subject names are represented as a single parameter that consists of a series of comma-separated RDNs. Each name is identified by the RDN abbreviation. For example, the following subject name represents Country/Region = US, Organization = Adatum, and Common Name = mail.adatum.com:

"c=US,o=adatum,cn=mail.adatum.com"

If the SubjectName parameter is not specified, the host name of the server where the cmdlet is run is used as the common name in the resulting certificate. For example, for the server VAN-EX1, the SubjectName parameter value cn=VAN-EX1 is used.

For example, if you run the New-ExchangeCertificate EMS cmdlet without parameters on the Hub Transport server VAN-EX1, this generates a self-signed certificate with the FQDN of the VAN-EX1 server as the subject name. You can use this certificate for direct trust authentication and encryption between Edge Transport servers and Hub Transport servers. The certificate is published to Active Directory so that Exchange direct trust can validate the authenticity of the server for MTLS. The following EMS command generates this certificate:

New-ExchangeCertificate

Note that this command generates a new default certificate that overwrites the current default certificate and that you need to confirm this action.

The following command run on a Hub Transport server lists all the Exchange certificates published in Active Directory (on an Edge Transport server, the same command would list the certificates stored on the server):

Get-ExchangeCertificate

Figure 9 shows a typical output for this command. You need to know a certificate’s thumbprint in order to renew it, and it is a good idea to redirect the output of this command into a text file so that you can paste thumbprints into commands as necessary.

The following EMS command renews a self-signed certificate that has the thumbprint listed in the code:

Get-ExchangeCertificate -Thumbprint C4248AB7065B62BC972A60F7293BDA7F533A4FCA | New-
ExchangeCertificate

					  

The following EMS command creates a certificate with an exportable private key and a subject name defined by Country/Region = US, Organization = Adatum, and Common Name = mail.adatum.com:

New-ExchangeCertificate -SubjectName "c=US,o=adatum,cn=mail.adatum.com"
-PrivateKeyExportable $true

Depending on the certificates that already exist in Active Directory, you may need to confirm this command. Figure 10 shows the command output.

6.2. Generating a Certificate Request

You can use the New-ExchangeCertificate EMS cmdlet to generate a certificate request and output it to the command-line console. You can send the certificate request to a CA within your organization, a trusted CA outside your organization, or a commercial CA by pasting the certificate request output into an email message or into the appropriate field on the CA’s certificate request web page. You can also save the certificate request to a text file.

The following EMS command generates a certificate request with a subject name c=UK, o=Blue Sky Airlines, cn=mail.blueskyairlines.co.uk, a subject alternate name blueskyairlines.co.uk, and an exportable private key:

New-ExchangeCertificate -GenerateRequest -SubjectName "c=UK,o=Blue Sky Airlines,cn=mail
.blueskyairlines.co.uk" -DomainName blueskyairlines.co.uk -PrivateKeyExportable $true

					  

Figure 11 shows this certificate request.

As Figure 11 demonstrates, the certificate request is lengthy and complex, and it is advisable to automate storing this request in a request file. You can store the output of the command to generate a certificate request in a variable and use the Set-Content PowerShell cmdlet to generate a request file. The following two commands create the same certificate request as before and then save it in the file CertRequest01.req in the C:\Requests folder:

$Request = New-ExchangeCertificate -GenerateRequest -SubjectName "c=UK,o=Blue
Sky Airlines,cn=mail.blueskyairlines.co.uk" -DomainName blueskyairlines.co.uk
-PrivateKeyExportable $true
Set-Content -Path "C:\Requests\CertRequest01.req" -Value $Request