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 2)
- Exchange 2010 Domain Security (Part 3)
We have arrived at the fourth and final part of an article series looking at domain security in Exchange 2010. We left part three having discovered a certificate trust issue, since we are using the default self-signed certificates in Exchange 2010 on the Edge Transport servers. Here in part four we’ll look at resolving this issue and finish the article looking at message headers added by domain security, followed by using transport rules with domain security in mind.
In our lab environment, we can easily solve the certificate validation issues that we saw in part three by exporting neilhobson.com’s certificate and importing it into nghcloud.co.uk’s Edge Transport server. Obviously you would not do this anywhere else but in a lab, but in this case it allows us to easily demonstrate the domain security feature. Here’s what to do:
- On neilhobson.com’s Edge Transport server, run the Microsoft Management Console (MMC) by running mmc.exe
- Within the MMC, click File and then click Add/Remove Snap-In
- In the Add or Remove Snap-Ins window, select the Certificates snap-in and then click the Add> button.
- In the Certificates snap-in window, select Computer account and click Finish.
- In the Select Computer window, just accept the default of Local computer and click Finish.
- Back at the Add or Remove Snap-Ins window, click OK.
- The Certificates snap-in will now be loaded into the MMC. Expand the Certificates node, then the Personal node and finally the other node named Certificates. You will now see the self-signed certificate listed as shown in Figure 4-1.
Figure 4-1: neilhobson.com Edge Transport Self-Signed Certificate
- Right-click the self-signed certificate and choose All Tasks / Export.
- At the opening Certificate Export Wizard screen, click Next.
- On the Export Private Key screen, make sure the No, do not export the private key option is selected.
- On the Export File Format screen, accept the default option of DER encoded binary X.509 (.CER)
- Finally, on the File to Export screen, choose a suitable filename and complete the wizard.
- Assuming all has gone well, you should see a prompt stating that the export was successful.
The resulting .cer file that has been exported must now be imported into nghcloud.co.uk’s Edge Transport server. To do this, run the Certificates snap-in on nghcloud.co.uk’s Edge Transport server in the same way that you just did for neilhobson.com’s Edge Transport server. This time, however, navigate to Trusted Root Certification Authorities, then to the Certificates node under that. This is shown in Figure 4-2.
Figure 4-2: nghcloud.co.uk’s Edge Transport Trusted Root Certification Authorities Store
To import the certificate that was exported from neilhobson.com, follow these steps:
- Right-click the Certificates node and choose All Tasks / Import.
- At the opening Certificate Import Wizard screen, click Next.
- On the File to Import screen, locate the exported .cer file and then click Next.
- On the Certificate Store screen, make sure the Place all certificates in the following store option is selected and that the selected store is already populated with Trusted Root Certification Authorities.
- Complete the wizard and assuming all has gone well, you should see a prompt stating that the import was successful.
- The result is the self-signed certificate for neilhobson.com’s Edge Transport server is now listed in nghcloud.co.uk’s Trusted Root Certification Authorities store as shown in Figure 4-3.
Figure 4-3: neilhobson.com Certificate in nghcloud.co.uk’s Trusted Root Certification Authorities Store
It is important to state here that we also need to ensure that the self-signed certificate on nghcloud.co.uk’s Edge Transport server is exported and imported into the Trusted Root Certification Authorities store on neilhobson.com’s Edge Transport server. This is a requirement since we are talking about mutual TLS in this article where both Edge Transport servers need to prove who they are. So before you go any further, do this now by simply following the above steps but this time reverse the process by exporting from nghcloud.co.uk and importing into neilhobson.com.
Testing Domain Security
At this point, the message destined for neilhobson.com is still queued on nghcloud.co.uk’s Edge Transport server as shown previously in Figure 3-5. In my lab, even forcing a retry of the queue wasn’t successful in delivering the message; I had to restart the Microsoft Exchange Transport service on nghcloud.co.uk’s Edge Transport server before the message was processed. This is understandable given the changes we have just made to the certificates.
With the queue issue sorted out, let’s now take a look at how the message from nghcloud.co.uk is received in the inbox of a neilhobson.com user. First, Figure 4-4 shows a view of the inbox in Outlook 2010 containing three messages, one of which has been sent by a nghcloud.co.uk user. Notice the domain security icon of the nghcloud.co.uk message itself (highlighted) as compared to the other messages that are internal to the neilhobson.com organization.
Figure 4-4: Domain Secured Email in neilhobson.com’s Inbox
Now see what happens when the actual domain secured email is opened; this is shown in Figure 4-5. Notice, in the red highlight box, that the message has the domain security button that informs the user that the message has been secured with domain security.
Figure 4-5: Domain Security Button in Outlook 2010 Message
Clicking the domain security button presents the neilhobson.com user with the window shown in Figure 4-6, confirming that the message was received securely from nghcloud.co.uk.
Figure 4-6: Domain Secured Email Information Window
We’ve seen how the message looks in Outlook 2010. What about OWA 2010? You may remember that in part one of this article I stated that domain security is only available in Outlook 2010. A view of the neilhobson.com inbox via OWA 2010 confirms that the message sent by the nghcloud.co.uk user does not have any domain security information shown with it; remember, this is the message with the subject of “Test of domain security”. This is shown in Figure 4-7.
Figure 4-7: Domain Security Not Displayed in OWA 2010
If you have been using Exchange and Outlook for any reasonable length of time then I’m sure that you’ve come across message headers in your day-to-day dealings. Specifically, you may be aware of X-headers that sometimes appear in messages. These are unofficial headers that are often added to messages by anti-virus and antispam applications, amongst others. Domain security adds several X-headers, starting with X-MS-Exchange-Organization as you can see from Figure 4-8. For example, the X-MS-Exchange-Organization-AuthDomain header tells you that the authenticating domain is nghcloud.co.uk, whereas the X-MS-Exchange-Organization-AuthAs header tells you that the nghcloud.co.uk domain is authenticated as a partner domain.
This information isn’t strictly of importance to the administrator or the end-user, but it could prove useful if you are making use of features such as the header firewall in Exchange 2010.
Figure 4-8: X-Headers Displayed in Domain Secured Messages
Domain Security and Transport Rules
It is also possible to use domain security within transport rules. For example, let’s now configure the nghcloud.co.uk Exchange organization with a transport rule to make a change to messages that are sent to neilhobson.com. Here’s what to do:
- Run the Exchange Management Console on the internal Exchange 2010 server in nghcloud.co.uk and navigate to Organization Configuration / Hub Transport / Transport Rules.
- Select New Transport Rule from the action pane.
- In the first screen of the New Transport Rule wizard, give the rule a name and ensure that it is enabled.
- On the Conditions screen, ensure that in Step 1 the option called “sent to users that are inside or outside the organization, or partners“ is selected.
- In Step 2 on the Conditions screen, click the Inside the organization link and in the resulting Select scope screen, choose a scope of External partner organizations. This is shown in Figure 4-9. A partner organization is one that has been configured for domain security, so this transport rule will apply to messages sent to neilhobson.com users.
Figure 4-9: Selecting the Scope for the Transport Rule
- On the Actions screen, choose the “prepend message with a subject string” option in Step 1 and in Step 2 click the String link. In the resulting Specify Subject Prefix window, enter a suitable subject to prepend to the messages to neilhobson.com. In this article, I’m using a string of “DOMAIN SECURED EMAIL” to emphasize to neilhobson.com users that the message has been secured using domain security.
- Complete the transport rule wizard by skipping the Exceptions screen and creating the rule.
The result will be a rule that looks similar to the one shown in Figure 4-10.
Figure 4-10: The Completed Transport Rule
When a message is now sent from nghcloud.co.uk to neilhobson.com, the nghcloud.co.uk Hub Transport server intercepts the message and prepends the string to the subject of the message. The result, when viewed from the inbox of a neilhobson.com user, is shown in Figure 4-11.
Figure 4-11: Subject of Domain Secured Message With Prepended Text
That completes our look at domain security in Exchange 2010. If you’re looking for a way to increase security between your organization and another, domain security may well be the right solution for you. I hope that you’ve found this article useful.
If you would like to read the other parts in this article series please go to: