Exchange 2010 Domain Security (Part 1)

If you would like to read the other parts in this article series please go to:

Introduction

In this article we’ll be taking a look at the feature known as domain security. This feature was first made available in Exchange 2007 but is still available in Exchange 2010; we’ll be focusing on Exchange 2010 in this article. Why might you consider implementing domain security? Well, if you have identified a need to exchange emails with another organization across the Internet and wish to add a level of security to those emails, domain security could be for you.

Essentially what domain security means to the end-users is that emails exchanged with users from organizations configured for domain security are shown, in Outlook, as domain secured emails. In other words, the end users know that the message has been sent from an authenticated user in the other organization and, additionally, that the message has travelled over a secure connection.

The way domain security works is reasonably straightforward. The key concept to understand is that domain security uses mutual Transport Layer Security for both authentication and encryption purposes. I’ve seen the phrase “mutual TLS” and the acronym MTLS to describe mutual Transport Layer Security. As you will see in this article the final servers in the transport chain, the Edge Transport servers, prove to each other who they are by validating each other’s certificate.

Configuring domain security involves many different technologies in Exchange 2010, such as Edge Transport servers, configuring Exchange Management Shell parameters, certificates and general transport configuration. Let’s start by describing the lab environment used within this article.

Lab Environment

For this article, I constructed the lab environment shown in Figure 1-1. Two organizations, nghcloud.co.uk and neilhobson.com, wish to exchange domain secured emails between each other, across the Internet.

Figure 1-1: Lab Environment

The lab environment consists of the following servers:

DS-FDC, nghcloud.co.uk’s domain controller and DNS server. Note that in this lab, both nghcloud.co.uk and neilhobson.com’s domain controllers are running the Windows 2003 operating system for reasons of keeping system resources down. There is no specific requirement to be running Windows 2003 or Windows 2008 domain controllers; either operating system is fine.
DS-FEXCH, nghcloud.co.uk’s internal Exchange 2010 server running the mailbox, Hub Transport and Client Access Server roles.
DS-FEDGE, which is nghcloud.co.uk’s Exchange 2010 Edge Transport server.
DS-CDC, neilhobson.com’s domain controller and also running DNS.
DS-CEXCH, which is neilhobson.com’s internal Exchange 2010 server running the mailbox, Hub Transport and Client Access Server roles.
DS-CEDGE, neilhobson.com’s Exchange 2010 Edge Transport server.

I will use the name ‘internal Exchange 2010 server’ in this article to reference the Exchange 2010 servers that have been installed with the mailbox, Hub Transport and Client Access Server roles. This is to distinguish them from the Edge Transport servers.

Within this article I will be concentrating on the configuration required for nghcloud.co.uk to send and receive domain secured email to and from neilhobson.com. The neilhobson.com Exchange organization will also need to be configured appropriately in order to send and receive domain secured email with nghcloud.co.uk but since that’s effectively duplicate configuration information, I won’t be repeating it within this article.

Note that in this article we will be using the self-signed certificates that are generated by the installation of Exchange 2010. You would probably not want to use self-signed certificates in your production environment of course and you would likely use 3rd party certificates from a trusted root certification authority. Whatever certificates you choose, be sure to plan accordingly.

Edge Synchronization

This article starts with all four Exchange 2010 servers deployed to the point where Exchange 2010 has been installed. However, the Edge synchronization configuration has not yet been performed so that’s where we’ll start. I am not going to go into huge amounts of background detail on the Edge synchronization process as that is well documented in plenty of other articles. However, before we dive into the process of creating the Edge subscription, it is important to ensure that you have name resolution working between the Hub Transport and Edge Transport servers, in both directions. You can use local hosts files or configure DNS – the choice is yours. For this lab environment, I have made sure that the DNS server running on DS-FDC has an A record for the host DS-FEDGE that points to the IP address 192.168.50.52, thereby allowing the internal Exchange 2010 server to be able to resolve the Edge Transport server’s name. To allow the Edge Transport server to be able to resolve the Hub Transport server’s name, I made things simple for myself by configuring the Edge Transport server’s DNS server to be DS-FDC which will contain an A record for the Hub Transport server. You may choose to use a hosts file of course. Make sure that the corresponding name resolution works between neilhobson.com’s internal Exchange 2010 server and Edge Transport server.

For the Edge subscription process, the first step is to create the subscription XML file on the Edge Transport server. To do this, we will run the following command on nghcloud.co.uk’s Edge Transport server:

New-EdgeSubscription –FileName c:\ds-fedge.xml

Of course, it doesn’t matter what you call the actual file name; I just happened to use the server name for easy reference. The results of running this command are shown in Figure 1-2. Note the warning that the Edge subscription process should be completed within 1440 minutes.

Figure 1-2: Creating the Edge Subscription XML File

Once the XML file has been created, switch over to the Exchange Management Console on nghcloud.co.uk’s internal Exchange 2010 server and navigate to the Organization Configuration container. From here, select the Hub Transport node and then click the Edge Subscriptions tab. We now need to import this XML file into the internal Exchange 2010 Hub Transport server role in order to complete the Edge subscription process. To import the XML file, perform these steps:

Select the New Edge Subscription option from the action pane.
In the resulting wizard screen, first select the Active Directory site that contains the Hub Transport server role. In this lab environment, we only have the Default-First-Site-Name Active Directory site so choose that.
Next select the name of the subscription file that can be found on the C:\ drive of the Edge Transport server in our example configuration. In locked-down environments, you wouldn’t likely be able to navigate directly to the Edge Transport server from the Hub Transport server so you’d have to use an alternative method to obtain the XML file. Here in the lab environment, it is relatively straightforward. Once you’ve selected the XML file, your wizard screen should look something like the one shown in Figure 1-3. Note the option to automatically create a Send connector for this Edge subscription. This will create a general purpose Send connector for Internet email which is fine, even though we will be creating a custom Send connector later in the article.

Figure 1-3: Completing the Edge Subscription Process

Click the New button and the Edge subscription should be created. Check the Completion screen of the wizard for successful configuration.

Note that the final screen of the wizard may warn you that you need to ensure that there is name resolution between the Hub Transport servers and also that communications is possible via port 50636. Ensure that this is the case.

To further prove that the Edge subscription process has been successful, we can navigate to the Exchange Management Console on nghcloud.co.uk’s Edge Transport server and check that the EdgeSync Send connectors have been created as you can see from Figure 1-4.

Figure 1-4: Send Connectors on the Edge Transport Server

Summary

That completes part one of this article looking at domain security and in this article we have discussed domain security, the lab environment and gone onto configuring the Edge subscription process. In part two we’ll complete the lab environment configuration and start to look at the configuration required to implement domain security.

If you would like to read the other parts in this article series please go to: