Information Rights Management in Exchange 2010

Organizations of all sizes struggle to protect confidential data—customer names and addresses, future product plans—from accidental disclosure. Information leakage or data loss can lead to financial penalties and loss of partner and customer confidence. Now, with the release of Exchange 2010, businesses have a new weapon in this struggle. Exchange 2010 can leverage an organization’s Active Directory Rights Management Services (AD RMS) infrastructure—powered by Information Rights Management (IRM)—so that Exchange administrators can configure rules to automatically rights-protect email messages and attachments based on specific criteria.

Exchange 2010 also introduces another exciting feature that lets users send, receive, and reply to rights-protected email messages through Outlook Web Access (OWA). In earlier versions of OWA, users could read rights-protected email messages and attachments if they installed the Rights-Management Add-On (RMA), but this solution didn't work for browsers other than IE and users couldn't reply or create new rights-protected messages. Let’s examine how to set up and configure Exchange 2010 to leverage these two capabilities.

What It Does

For the purposes of this article, I'll assume that you already have an Exchange 2010 infrastructure installed but not yet configured for Exchange 2010 IRM. Recall that AD RMS is the underlying infrastructure consisting of servers and databases, and that IRM is the collection of features offered by Microsoft Office products such as Word, Excel, PowerPoint, and Outlook—and server systems such as SharePoint—that enables AD RMS to protect sensitive data contained in corporate documents and email messages.

With AD RMS and IRM, rights-protected documents and email messages are encrypted so that only users and groups specified by the author can read them and—depending on the rights granted—modify, print, or distribute them. Also thanks to AD RMS, Exchange administrators can set up conditions (e.g., sender, recipients, subject, content, attachments) for automatic rights protection. This feature removes the need for the email sender to make a decision to rights-protect the email, or even be aware of policy surrounding the dissemination of sensitive or confidential information.

Preparing AD RMS for Exchange 2010 Integration

There are some steps you need to take to prepare AD RMS for Exchange 2010. First, you must be using AD RMS on Windows Server 2008. If you're running the older Windows RMS on Windows Server 2003 or Windows 2003 R2, you'll need to upgrade. I recommend that you upgrade to Server 2008 R2 so that you can skip the following two steps to prepare AD RMS on Windows Server 2008 RTM.

If you're running AD RMS on Server 2008 RTM, you first need to install Server 2008 SP2 on all your RMS servers that Exchange 2010 will use—at a minimum, that means all the servers in your AD RMS certification cluster. Once SP2 is installed, you'll need to follow the instructions in the Microsoft article, "A hotfix is available for the Active Directory Rights Management Services role in Windows Server 2008: August 26, 2009" (support.microsoft.com/kb/973247). Simply click View and request hotfix downloads at the top of the page. Make sure that you download the correct hotfix; versions are available for both 32-bit and 64-bit systems.

Regardless of whether you're running AD RMS on Server 2008 RTM or R2, you need to configure discretionary ACLs (DACLs) on an AD RMS web service file on every server in your certification cluster. On each server, open the IIS Manager from the Administrative Tools folder and expand the Web Server node, then the Sites nodes, then the Default Web Site node, then the _wmcs node. Right-click the Certification node, and select Explore. In the Explorer window, right-click the ServerCertification.asmx file, select Properties, and go to the Security tab. You need to grant the Exchange Servers group permissions to read and execute the file. You also need to grant the AD RMS Service Group the same rights. (This group is a local group on the AD RMS Server itself.) When you've given these two groups the permissions on the file, ServerCertification.asmx's security settings—which you can access by clicking the Advanced button in the ACL Editor—will look like those in Figure 1.

Figure 1: ServerCertification.asmx

Next, you need to add the Federated Delivery mailbox (a system mailbox created during the installation and setup of your Exchange 2010 organization) to the RMS Super Users group. The Super Users group is extremely powerful: A member of this group can access any rights-protected content protected by the organization’s AD RMS system. For this reason, it's disabled by default, and when it is enabled, membership to the Super Users group should be strictly controlled. If Super User access is turned off, enable it, create a new email-enabled distribution group in AD, and make that group the RMS Super Users group. Figure 2 shows configuration of the RMS Super Users group on AD RMS 2008.

Figure 2: Configuring the Super Users group

The user logon name belonging to the Federated Delivery mailbox is FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042. To add the mailbox to the Super Users group, run the following command in the Exchange PowerShell:

Add-DistributionGroupMember  -Member FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042

where RMSSuperUsers is the name of the distribution group representing the Super Users group.

Once you have the name of the Super Users group, add the Federated Delivery mailbox user account to the group. Note that once you add the Federated Mailbox user to the Super Users group, the RMS group membership cache will need to expire before changes to the Super User group appear; that can take up to 24 hours.

Configuring OWA for IRM

Exchange 2010 includes the concept of a Client Access role, which contains the OWA feature. This feature permits users to access their mailboxes from their web browser, and send and receive email. The Client Access role doesn't support IRM, which means that users can't send and receive rights-protected messages without a configured Client Access role. If a user attempts to read a rights-protected message in OWA before the Client Access role has been configured, he or she will see a message similar to the one in Figure 3. 

Figure 3: Using OWA to read a rights-protected email before Exchange 2010 configuration

To configure the Client Access role, the Exchange administrator needs to use the Exchange Management Shell to run a cmdlet called Set-IRMConfiguration. The syntax of this command is

Set-IRMConfiguration -InternalLicensingEnabled $true –OWAEnabled $true

You can run this command once for your entire Exchange organization, and every Exchange Server 2010 server with the Client Access role will start serving users rights-protected messages through OWA. With such a configuration, users will see something similar to what Figure 4 shows. If you have sub-enrolled licensing servers, and you want Exchange 2010 to use one, you'll need to use the -LicensingLocation switch to specify the URL of the AD RMS licensing server.

Figure 4: Using OWA to read a rights-protected email after Exchange 2010 configuration

Recipients of rights-protected messages can reply to them using OWA, depending on the rights granted to them by the author of the message, and the replies will be rights-protected. This is a new feature of Exchange 2010. OWA users can also create rights-protected messages.

There are two key differences between the use of Exchange 2010 OWA to consume rights-protected messages and the use of the RMA for Internet Explorer (IE) combined with Exchange 2007 OWA. The first is that when using Exchange 2010 OWA, users aren't required to connect to the AD RMS infrastructure to obtain rights account certificates (RACs) or End User License Agreements (EULAs). Instead, Exchange 2010 acts on behalf of the user and accesses the rights-protected content as a Super User before serving the content in a web page. This makes it easier for users to consume rights-protected messages and doesn't require AD RMS administrators to configure Extranet Cluster URLs and external access for users outside the corporate firewall.

The second difference is that the end users are able to cut and paste rights-protected messages and take screenshots. This functionality wasn't possible with the RMA for IE. For this reason, it's possible to configure which users can use IRM via OWA using the -IRMEnabled Boolean flag on the Exchange Set-OwaMailboxPolicy Power Shell cmdlet, so that enterprises can prevent users who might have access to high-risk information from accessing rights-protected email via OWA. If you have many users and you need to enable or disable access to IRM through OWA, the Set-OwaMailboxPolicy cmdlet becomes unwieldy. An alternative approach is to create one or more additional OWA virtual directories for each category of users, configure access to each, and use the -IRMEnabled Boolean flag to the Set-OwaVirtualDirectory Power Shell cmdlet.

Using Transport Rules

IRM features are available in Office applications, including Outlook, and can be utilized by end users to protect sensitive data. One problem with IRM prior to Exchange 2010 is that if users forget to manually apply rights protection to sensitive data, that data might get leaked or distributed inappropriately. Exchange 2010 lets Exchange administrators create Transport Rules that can apply an AD RMS rights policy template to both email messages and any supported attachments based on matching conditions, such as the email address of the sender or recipient, words in the subject of the message, words in the body of the message, or any other condition that Transport Rules support. Exchange 2010 ships with a built-in rights policy template—called Do Not Forward—that, as the name suggests, prevents recipients from forwarding the email message. Exchange 2010 will pull additional rights policy templates from AD RMS, if they're configured.

To create a Transport Rule to automatically rights-protect email messages that match the rule’s conditions, launch the Exchange Management Console (EMC) on an Exchange 2010 Hub Transport server, expand the Microsoft Exchange On-Premises node, expand the Organization Configuration node, click the Hub Transport node, then click the Transport Rules tab in the console's right pane. Right-click in the pane, and select New Transport Rule from the menu to launch the New Transport Rule wizard. In the Introduction step, enter a name for the Transport Rule and an optional comment before clicking Next. In the Conditions step, select the conditions from the top that will cause the rule to fire. A common condition for applying rights protection is when the Subject field or message body contains specific words, as Figure 5 shows When you select a Condition that requires further details, such as a keyword or keywords, you'll need to specify them by clicking on underlined values to edit the rule description in the bottom of the wizard step. In you specify multiple conditions, all must be satisfied for the rule to fire.

Figure 5: Transport Rule with RMS Template

When you're finished selecting conditions and editing the rule description, click Next to get to the Actions step. In the Actions step, select the Rights protect the RMS template option from the top of the wizard step and click the underlined value RMS template to launch a dialog box that shows available RMS templates (rights policy templates). Select the RMS you want to apply, click OK to return to the wizard, then click Next to get to the Exceptions step. If you have no exceptions, click Next to get to the Create Rule step. Click New to create your Transport Rule. Once the rule has been created, click Finish to exit the wizard.

Using Transport Rules to automatically apply rights policy templates based on conditions can be resource intensive, and in certain situations—such as when there are many Transport Rules or when many messages match Transport Rules—performance of your Exchange infrastructure might be compromised, and users might experience significant delays in sending and receiving emails. For this reason, Transport Rules should be used sparingly.

If a rights policy template is deleted from your AD RMS installation you need to edit any Transport Rules that reference the template. If you don't, Exchange 2010 will return nondelivery reports (NDRs) to the senders of messages that match the Transport Rule conditions whose actions specify that the now-deleted rights policy template be applied to the message, and the intended recipients will never receive the email. Rather than delete a rights policy template, you should archive it. Exchange 2010 can still use an archived template, but it's otherwise inaccessible to users. Exchange 2010 will also return an NDR to the sender of an email message if a rights policy template can't be applied because the AD RMS infrastructure is unavailable. For this reason, you should ensure that your AD RMS infrastructure is fault-tolerant by building out clusters of certification and licensing servers.

Two Great Features

Exchange 2010 offers enterprises additional tools to combat information leakage, whether accidental or intentional, by incorporating IRM into the product. You're now familiar with two great IRM-enabled features: the ability to send, read, and reply to rights-protected email messages through OWA, and the ability to apply rights policy templates to messages based on matching conditions. Exchange 2010 offers other exciting IRM features that I haven't covered, including the ability to integrate with Office 2010’s Outlook to enforce policy on clients rather than on servers—a capability that can significantly offload processing—and to decrypt rights-protected content to meet compliance requirements. I'll cover these features in upcoming articles.