If you would like to read the other parts in this article series please go to:
- Exchange 2010 Domain Security (Part 1)
- Exchange 2010 Domain Security (Part 3)
- Exchange 2010 Domain Security (Part 4)
Introduction
This is the second part of an article looking at the Exchange 2010 feature known as domain security. In part one of this article, we covered the lab environment that we will be using and then proceeded to configure Edge synchronization between nghcloud.co.uk’s Edge Transport and Hub Transport servers.
Here in part two, we will continue with our configuration of nghcloud.co.uk’s Exchange infrastructure by performing operations such as configuring Send connectors, making the required DNS changes and testing both name resolution and connectivity with tools such as the Telnet client and NSLookup. We will then begin to configure nghcloud.co.uk’s internal Exchange 2010 infrastructure for domain security by running Exchange Management Shell cmdlets specifically targeted for domain security.
Send Connector for neilhobson.com
We now need to create a new Send connector on nghcloud.co.uk’s internal Exchange 2010 server. Specifically, this must be configured on the Hub Transport server role. This Send connector will be responsible for processing email sent to the neilhobson.com namespace and, ultimately, ensuring that it is configured for domain security. First, though, we will create the connector and simply check that we can successfully send email between nghcloud.co.uk and neilhobson.com users. By creating the new Send connector on the Hub Transport server, the connector will be synchronized onto nghcloud.co.uk’s Edge Transport server by the Edge synchronization process.
The Send connector should be created with an address space of neilhobson.com so that all emails for users within the neilhobson.com domain are processed by this Send connector and not the general purpose Internet email connector created during the Edge subscription process. There are two other very important configuration elements to note regarding the creation of a Send connector when considering Edge subscriptions and also the future use of domain security. The first is that the Send connector must use DNS MX records to route email; do not configure the connector to use a smart host. This is shown in Figure 2-1. You may also note from Figure 2-1 the option to Enable Domain Security (Mutual Auth TLS); we will be enabling this later as part of the overall configuration for domain security.
Figure 2-1: Configuring the Send Connector to Use DNS MX Records
The second important configuration element with regards to the Send connector is to ensure that the Source Server tab is configured with the Edge Transport server and not the local Hub Transport server. This is shown in Figure 2-2. This must be configured in order to ensure the Send connector is synchronized into the Edge Transport server.
Figure 2-2: Setting the Edge Transport Server as the Source Server
The Edge synchronization process will create the corresponding Send connector on the Edge Transport server. You can ensure this happens straight away by running the Start-EdgeSynchronization cmdlet on the Hub Transport server. Once you’ve done this, check that you see the new Send connector in the Exchange Management Console on the Edge Transport server.
DNS Requirements
Since we have configured the Send connectors to use DNS MX records, it follows that the nghcloud.co.uk DNS server (that the nghcloud.co.uk Edge Transport server is configured to use in this lab) must have the required MX records for the neilhobson.com Edge Transport server. To do this, we need to create a zone for neilhobson.com on the nghcloud.co.uk DNS server and add an MX record for neilhobson.com as well as an A record for the Edge Transport server. Figure 2-3 shows the MX record for the neilhobson.com domain as configured on nghcloud.co.uk’s DNS server. You can see that the host is configured as the fully qualified domain name of neilhobson.com’s Edge Transport server and that we’re using the default priority weighting of 10.
Figure 2-3: Creating the MX Record
Once the MX record has been created, we then need to create an A record for the neilhobson.com Edge Transport host ds-cedge.neilhobson.com. Once both records have been created, the zone will look like the example shown in Figure 2-4.
Figure 2-4: DNS Records for the neilhobson.com Zone
On nghcloud.co.uk’s Edge Transport server, we can run the nslookup utility to confirm that the DNS records are configured correctly. The command to run is:
nslookup –q=mx neilhobson.com
The –q=mx portion of the command tells nslookup to set the query type to MX records. After that, we simply specify the name of the domain that we want to query. The output returned from nslookup reads as follows:
neilhobson.com MX preference = 10, mail exchanger = ds-cedge.neilhobson.com
ds-cedge.neilhobson.com internet address = 192.168.50.62
We can see that, as far as the nghcloud.co.uk Edge Transport server is concerned, the mail server for the neilhobson.com domain is ds-cedge.neilhobson.com with an IP address of 192.168.50.52. It’s now a good idea to test connectivity via the SMTP port (port 25) between the nghcloud.co.uk and neilhobson.com Edge Transport servers. To do this, we can use the Telnet Client but note that, on Windows 2008 R2, this is not installed by default.
To install the Telnet Client on nghcloud.co.uk’s Edge Transport server, click Start / Administrative Tools / Server Manager to run the Server Manager program. In the left-hand pane, click Features and then select the Add Features link that appears in the right-hand pane. In the Select Features wizard, add the Telnet Client option as shown in Figure 2-5. Complete the wizard and the Telnet Client is installed; no reboot is necessary.
Figure 2-5: Installing the Telnet Client Feature
Once the Telnet Client has been installed, we can telnet to the neilhobson.com Edge Transport server from the nghcloud.co.uk Edge Transport server on port 25 and confirm that the banner is displayed. This is shown in Figure 2-6.
Figure 2-6: Testing Port 25 Connectivity With the Telnet Client
At this stage we have not configured domain security yet so it’s a good idea to ensure that mail flow is possible from nghcloud.co.uk to neilhobson.com via the Edge Transport servers. Therefore, at this point, make sure that you send test messages from nghcloud.co.uk to neilhobson.com to ensure that email connectivity is working before we enable domain security.
Configuring Domain Security
Now that we know both nghcloud.co.uk and neilhobson.com users can email each other through the Edge Transport servers, it’s now time to look at the configuration required to implement domain security. The first thing on the agenda would typically be the certificate configuration on the Edge Transport servers, but I’m going to leave that for a moment as we will use the default self-signed certificates and see what errors and/or issues we get; it will be useful for future troubleshooting if you can see how certificate issues manifest themselves when implementing domain security.
The nghcloud.co.uk Exchange organization needs to be configured such that the neilhobson.com domain is both an outbound and inbound domain for domain security. To do this, we use the Set-TransportConfig cmdlet since the requirement is to make an organizational change and the Set-TransportConfig cmdlet makes organization changes to the transport configuration. Note that the Set-TransportConfig cmdlet needs to be run on the internal Exchange 2010 server, not the Edge Transport server.
The parameters of interest are TLSSendDomainSecureList and TLSReceiveDomainSecureList. These parameters contain a list of domains for which we have enabled domain security from either an inbound (receive) or outbound (send) perspective. Let’s first run the Get-TransportConfig cmdlet to see what these parameters are set to by default. As you can see from Figure 2-7, these parameters are empty.
Figure 2-7: Results of Get-TransportConfig Using Default Configuration
It follows that we must set both of these parameters to have a value of neilhobson.com. This is achieved by running the following two commands:
Set-TransportConfig –TLSSendDomainSecureList neilhobson.com –TLSReceiveDomainSecureList neilhobson.com
Once set, we can check the parameters have taken effect as you can see from Figure 2-8.
Figure 2-8: Setting nghcloud.co.uk’s Inbound and Outbound Domain Secure List
Summary
Although we have made quite a few configuration changes to the nghcloud.co.uk environment in this article, there still remains quite a few configuration changes to make which we will be continuing to look at in part three of this article. Specifically, we’ll be covering areas such as configuring the Send and Receive connectors with Mutual Auth TLS, and then seeing what happens when we try to send a test message when we haven’t made any certificate changes.
If you would like to read the other parts in this article series please go to:
