Managing Compliance in Microsoft Exchange Server 2010

Protecting content

Message classifications are useful to a point. They don’t impose any restrictions on users and apart from providing some advice as to how important information contained in a message is, users can blissfully ignore their invocation to deal with the information in any particular way. Another approach is necessary if you want to impose restrictions on users as to what they can and cannot do with content. This isn’t a new requirement. For almost 20 years, companies have attempted to protect sensitive information that users transmit in email. The first attempts were based on message encryption and required the sender and recipient to share common (public) keys. The first versions of Exchange-based message encryption used the Windows Public Key Infrastructure (PKI). Some companies experienced success with message encryption but others found that PKI-based systems require a lot of administrative knowledge and intervention (at times) and users often didn’t use encryption when they should. In addition, software and hardware upgrades for server and clients had to be carefully managed to ensure that keys were preserved. The result was often disappointing in terms of the degree of protection achieved across the organization.

Software vendors began to explore different approaches to content protection toward the end of the 1990s. These solutions typically required users to explicitly protect a message by invoking a client add-in and relied on communication with specially designated servers. It was difficult to achieve true protection across a range of Web, mobile, and desktop and laptop clients working in offline and online modes. Costs were high because of the need to buy, deploy, and manage additional client and server software and achieving interoperability with partners was tricky. Needless to say, mergers and acquisitions posed even more challenges.

Apart from the ability to send S/MIME protected messages, Exchange 2010 supports two more sophisticated mechanisms to protect content:

• Information Rights Management (IRM) IRM relies on templates that describe different sensitivity levels for content and the actions that users can take when they receive protected contents. IRM depends on AD RMS and is now well-integrated throughout Exchange 2010 in terms of client support (Outlook Web App, Outlook, Windows Mobile, and BlackBerry), its support for federation, and the ability to apply IRM through transport rules. Exchange is able to decrypt IRM protected content to inspect it during transport rules processing and discovery searches and can journal protected content in a satisfactory manner. In short, IRM is the approach most suitable for enterprises that are willing to dedicate sufficient resources to achieving a sophisticated and comprehensive level of protection.

• Outlook protection rules An Exchange 2010 administrator can create rules that are pushed out to Outlook 2010 clients, which then use the rules to automatically apply AD RMS templates to protect content as users create and send messages. For example, a rule might say that any message sent to a specific distribution group must be protected. Outlook protection rules are in their first iteration and have a major dependency in that they cannot be used without first deploying Outlook 2010 clients.

Planning for the deployment of protected content within an enterprise is not just a matter of selecting and deploying technology. User education is often the biggest obstacle to overcome, especially in large, multinational, and highly distributed companies. It’s also not a matter that the Exchange administrators can decide on alone. The Active Directory management team has to be involved if you want to use AD RMS and the corporate security team and legal group need to be involved to ensure that content protection is aligned with other security initiatives and complies with any legal or regulatory regime to which the company is exposed. The topic is therefore complex at many levels and the best idea is to research the information available on TechNet and other sources before you progress too far along toward a decision to deploy.

Active Directory Rights Management Services

Active Directory Rights Management Service (AD RMS) is a new version of Windows Rights Managment Service (RMS) that allows companies to protect sensitive information by applying policies that dictate how that information can be accessed and shared by users. In an email context, AD RMS can be used with Exchange 2010 to stop users from sending or forwarding messages to unauthorized recipients or otherwise sharing contents by printing, cutting and pasting into other messages, and so on. RMS had a somewhat checkered history because it is very Windows-centric and didn’t meet the needs of companies that had heterogeneous environments. AD RMS runs on a Microsoft Windows 2008 server and leverages Active Directory extensively, so it still poses some issues for companies that don’t depend on Microsoft for large sections of their IT infrastructure. However, the latest implementation does offer some new features in conjunction with Exchange 2010 that make it more interesting to a messaging administrator. One major advance is the fact that Outlook Web App now supports protected messages for non-Microsoft browsers running on non-Windows platforms, so it is now possible to deploy rights management in a heterogeneous multiplatform infrastructure and expect that users will be able to read protected information. (In addition, Microsoft Outlook for Mac OS X supports AD RMS, as do Windows Mobile 6.1 and later.)

Every message that flows through Exchange passes through the transport service. It is therefore sensible to use this choke point as the place to impose restrictions on email content. Transport protection encryption is an integration that allows you to use AD RMS with Exchange transport rules to apply AD RMS templates to messages as they are processed by the transport service. For example, you could apply the standard Do Not Forward AD RMS template to outgoing messages sent by your senior management team to members of the board of directors to stamp the messages as highly confidential and to ensure that they cannot be forwarded. A key part of making this feature work is that the Exchange 2010 transport system can read protected messages so that journaling and transport rules can be applied. In response to user demands, Exchange 2010 Unified Messaging also supports protection for voice mail messages by marking private messages with the Do Not Forward AD RMS template before they are submitted to a hub transport service.

AD RMS is supported by Outlook 2010, Outlook Web App, Windows Mobile, and some non–Windows Mobile devices. Windows Mobile clients depend on the AD RMS prelicensing agent that was first shipped in Exchange 2007 SP1. The agent runs on hub transport servers and proactively requests licenses to allow Outlook 2007 (and later) and Windows Mobile 6.0 (and later) clients to read protected content without having to first submit credentials. The idea is to make protected content less onerous to deploy and use.

Installing Active Directory Rights Management

There’s plenty of information available in TechNet to help guide you through the detail of installing and configuring Active Directory Rights Management Service so we do not provide a detailed step-by-step guide here. Essentially, the following are the headline steps.

1. Decide on the server that will host the AD RMS cluster (the server that will control the licenses that underpin rights protection within the organization). The server can run Windows 2008 SP2 (a hotfix is required for this version of the operating system) or Windows 2008 R2. It is not best practice to install AD RMS on the same server as Exchange 2010.

2. Install the Active Directory Rights Management Services role on the server (Figure 15-40). The installation wizard leads you through many screens and you might want to perform an installation on a test server before you attempt to introduce AD RMS into the production environment.

3. Perform the postinstallation steps to configure Exchange 2010 to use IRM.

4. Validate that everything is running properly and that users can protect and access content using IRM.

Figure 15-40 Installing Active Directory Rights Management Services on a Windows 2008 R2 server.

After a successful installation of Active Directory Rights Management Service, there are still some steps that must be performed before AD RMS is ready to support Exchange:

• The certificate specified for use by the installation (or created by the installation) must be installed on Exchange mailbox and hub transport servers. You can export the certificate from the server that supports the AD RMS cluster that will be used by Exchange and import it into the Exchange mailbox and hub transport servers. The certificate is required to provide Secure Sockets Layer (SSL) communications between Exchange and the AD RMS server.

• The Exchange Servers security group must be granted read and write permission to the AD RMS cluster certification pipeline. This is a file called \inetpub\wwwroot\_wmcs\certification\ServerCertification.asmx located on the AD RMS cluster. Exchange hub transport servers need to be able to access this file to be able to use the AD RMS prelicensing agent to request licenses to access protected content proactively on behalf of clients.

• The account for the federated delivery mailbox must be added to the super users group for the AD RMS cluster. This step allows Exchange to decrypt protected messages as they pass through the transport system (to apply rules based on message content), to journal protected messages, to incorporate protected items into Exchange content indexes, and to allow Outlook Web App users to use IRM.

• IRM features must be enabled for messages sent to internal recipients (within the same Exchange organization) to allow them to access AD RMS templates. To perform this step, run the Set-IRMConfiguration cmdlet as follows:

  Set-IRMConfiguration -InternaLicensingEnabled $True

  You can check the IRM configuration with the Get-IRMConfiguration cmdlet.

After taking these steps, you can verify that the IRM configuration is valid by running the Test-IRMConfiguration cmdlet. In this example we use two email addresses to verify that prelicensing and journal encryption works:

Test-IRMConfiguration -Recipient TRedmond@contoso.com -Sender epr@contoso.com

Results : Checking Exchange Server ...
              - PASS: Exchange Server is running in Enterprise.
          Loading IRM configuration ...
              - PASS: IRM configuration loaded successfully.
          Retrieving RMS Certification Uri ...
              - PASS: RMS Certification Uri: https://adroot.contoso.com/_wmcs/certification.
          Verifying RMS version for https://adroot.contoso.com/_wmcs/certification ...
              - PASS: RMS Version verified successfully.
          Retrieving RMS Publishing Uri ...
              - PASS: RMS Publishing Uri: https://adroot.contoso.com/_wmcs/licensing.
          Acquiring Rights Account Certificate (RAC) and Client Licensor Certificate (CLC) ...
              - PASS: RAC and CLC acquired.
          Acquiring RMS Templates ...
              - PASS: RMS Templates acquired.
          Retrieving RMS Licensing Uri ...
              - PASS: RMS Licensing Uri: https://adroot.contoso.com/_wmcs/licensing.
          Verifying RMS version for https://adroot.contoso.com/_wmcs/licensing ...
              - PASS: RMS Version verified successfully.
          Creating Publishing License ...
              - PASS: Publishing License created.
          Acquiring Prelicense for 'tredmond@contoso.com' from RMS Licensing Uri
(https://adroot.contoso.com/_wmcs/licensing)
          ...
              - PASS: Prelicense acquired.
          Acquiring Use License from RMS Licensing Uri
(https://adroot.contoso.com/_wmcs/licensing)
              - PASS: Use License acquired.

          OVERALL RESULT: PASS

After you are sure that the basic AD RMS configuration is working, you can consider the finer details of your deployment. By default, AD RMS installs a template called Do Not Forward that users can apply to messages to mark them as confidential. A template defines the rights that users have over items to which the template is applied and you might want to create some additional templates to meet business needs within the company. For example, Figure 15-41 shows the properties of a template called Top Secret – Do Not Share as viewed through the AD RMS console. This template is purposely restrictive because we don’t want to allow users to do much except view its contents and reply to the messages that are marked with the template. Behind the scenes the AD RMS server distributes new and updated templates to clients so that they are available for use.

Figure 15-41 Viewing the properties of the “Top Secret” AD RMS template.

You can discover the set of templates that are currently defined with the Get-RMSTemplate cmdlet. For example:

Get-RMSTemplate

Name                           Description
--------                       ---------------
Top Secret - Do Not Share      The Top Secret template is applied to our most secret documents
Do Not Forward                 Recipients can read this message, but they can't forward, print, or

Using AD RMS to protect content

Figure 15-42 shows the Top Secret template being applied to a new message with Outlook Web App. The same drop-down menu is used for message classifications, which we discussed earlier in this chapter, so if you define some message classifications, you’ll see them listed here along with AD RMS templates. Once again, this reinforces the necessity for a good naming convention to help users do the right thing.

Figure 15-42 Marking a message with the Top Secret AD RMS template.

Once a template is applied, it remains with the message no matter where it passes through the messaging system. The transport system is able to decrypt protected content. Decryption occurs first in the transport pipeline to ensure that subsequent agents can process the content to apply transport and journal rules. Protected messages can be discovered by mailbox searches so that any relevant protected items are included in the content captured in a discovery mailbox.

The first time that a client accesses protected content during a session, it contacts Exchange and the AD RMS server to fetch the credentials that are necessary to access protected items. The understandable need to retrieve credentials can slow down access to protected content, especially when the client is separated from the AD RMS server by an extended network connection. Outlook Web App is a lot less obvious than Outlook is when it comes to configuring itself for rights management, as the user will probably be unaware of the work going on behind the scenes. As you can see from Figure 15-43, Outlook 2010 provides the user with a lot more insight about the configuration process.

The user interface of clients also adjusts to take account of the rights defined in the template. As you can see in Figure 15-44, Outlook Web App has disabled the Forward and Print options because these rights are not allowed for items marked with the Top Secret template. In addition, if you reply to a message the client will not be able to include the text of the original message, as it is protected, so the original message will be added as an attachment to the reply.

You can also see evidence that the transport system has processed the message because the corporate disclaimer has been appended. We will develop the topic further when we discuss transport rules in Chapter 16 and see how the transport system can automatically apply AD RMS templates to protect confidential information in messages as they pass from user to user.

Figure 15-43 Outlook 2010 is configured for rights management.

Figure 15-44 Viewing a message marked with the Top Secret AD RMS template.

Figure 15-45 shows how Outlook 2010 displays a protected message (all versions from Outlook 2003 SP2 are able to access protected content). The View Permissions option is accessed by clicking the highlighted bar that shows details of the template that protects the item. When selected, Outlook displays the permissions defined in the template. As you can see from the list, the template applied to this item does not allow users to do much except view or reply to the item. They cannot print, save, export, or even copy the item (and the restriction on copying goes so far as to prohibit any attempt to save a view of the content with a screen capture tool).

Figure 15-45 Viewing permissions on a protected message with Outlook 2010.

Unless they can access the necessary credentials, external recipients won’t be able to access protected content if a user forwards a protected message outside the organization. This is the biggest value of applying protection to messages because it stops users from being able to share confidential or other sensitive information either by accident (forwarding the wrong message or sending it to the wrong recipient) or deliberately. Information leakage is deemed by some companies to be a form of corporate sabotage and carries severe consequences for the responsible employee.

Rights management enhancements in Exchange 2010 SP1

A number of changes are made in Exchange 2010 SP1 to improve the effectiveness of rights protection. Protected attachments can now be read using the Outlook Web App WebReady document viewer. Also, Microsoft now supports IRM between on-premise servers and Exchange running in its Office 365 hosted service. This is accomplished through the Trusted Publishing Domain (TPD) feature that allows the RMS cluster running in the on-premise deployment to trust and use the licenses issued by the Office 365 servers and vice versa. Much the same approach can be taken to deploy federated IRM between two organizations.

After a rough start, Microsoft has improved the implementation and capabilities of its rights management solution to a point where it is very usable, providing that you deploy the latest clients. However, the success or failure of any solution that aims to protect confidential material is not dependent on technology alone; it is much more important to achieve strong user buy-in and appreciation of the need to protect the material. Unless this aspect of the project is achieved, it will eventually fail because users will find other ways to share information with each other, maybe by pasting it into Facebook!