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)

Introduction

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.

Certificates

In our lab environment, we can easily solve the certificate validation issues that we saw in part three by exporting Contoso’s certificate and importing it into Fabrikam’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:

1. On Contoso’s Edge Transport server, run the Microsoft Management Console (MMC) by running mmc.exe
2. Within the MMC, click File and then click Add/Remove Snap-In
3. In the Add or Remove Snap-Ins window, select the Certificates snap-in and then click the Add> button.
4. In the Certificates snap-in window, select Computer account and click Finish.
5. In the Select Computer window, just accept the default of Local computer and click Finish.
6. Back at the Add or Remove Snap-Ins window, click OK.
7. 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: Contoso Edge Transport Self-Signed Certificate

8. Right-click the self-signed certificate and choose All Tasks / Export.
9. At the opening Certificate Export Wizard screen, click Next.
10. On the Export Private Key screen, make sure the No, do not export the private key option is selected.
11. On the Export File Format screen, accept the default option of DER encoded binary X.509 (.CER)
12. Finally, on the File to Export screen, choose a suitable filename and complete the wizard.
13. 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 Fabrikam’s Edge Transport server. To do this, run the Certificates snap-in on Fabrikam’s Edge Transport server in the same way that you just did for Contoso’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: Fabrikam’s Edge Transport Trusted Root Certification Authorities Store

To import the certificate that was exported from Contoso, follow these steps:

1. Right-click the Certificates node and choose All Tasks / Import.
2. At the opening Certificate Import Wizard screen, click Next.
3. On the File to Import screen, locate the exported .cer file and then click Next.
4. 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.
5. Complete the wizard and assuming all has gone well, you should see a prompt stating that the import was successful.
6. The result is the self-signed certificate for Contoso’s Edge Transport server is now listed in Fabrikam’s Trusted Root Certification Authorities store as shown in Figure 4-3.

Figure 4-3: Contoso Certificate in Fabrikam’s Trusted Root Certification Authorities Store

It is important to state here that we also need to ensure that the self-signed certificate on Fabrikam’s Edge Transport server is exported and imported into the Trusted Root Certification Authorities store on Contoso’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 Fabrikam and importing into Contoso.

Testing Domain Security

At this point, the message destined for contoso.com is still queued on Fabrikam’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 Fabrikam’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 Fabrikam is received in the inbox of a Contoso 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 Fabrikam user. Notice the domain security icon of the Fabrikam message itself (highlighted) as compared to the other messages that are internal to the Contoso organization.

Figure 4-4: Domain Secured Email in Contoso’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 Contoso user with the window shown in Figure 4-6, confirming that the message was received securely from Fabrikam.

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 Contoso inbox via OWA 2010 confirms that the message sent by the Fabrikam 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

Message Headers

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 fabrikam.com, whereas the X-MS-Exchange-Organization-AuthAs header tells you that the fabrikam.com 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 Fabrikam Exchange organization with a transport rule to make a change to messages that are sent to Contoso. Here’s what to do:

1. Run the Exchange Management Console on the internal Exchange 2010 server in Fabrikam and navigate to Organization Configuration / Hub Transport / Transport Rules.
2. Select New Transport Rule from the action pane.
3. In the first screen of the New Transport Rule wizard, give the rule a name and ensure that it is enabled.
4. 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.
5. 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 Contoso users.

Figure 4-9: Selecting the Scope for the Transport Rule

6. 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 Contoso. In this article, I’m using a string of “DOMAIN SECURED EMAIL” to emphasize to Contoso users that the message has been secured using domain security.
7. 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 Fabrikam to Contoso, the Fabrikam 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 Contoso user, is shown in Figure 4-11.

Figure 4-11: Subject of Domain Secured Message With Prepended Text

Summary

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:

• Exchange 2010 Domain Security (Part 1)
• Exchange 2010 Domain Security (Part 2)
• Exchange 2010 Domain Security (Part 3)