Outlook 2010 Protection Rules and Exchange 2010

In "Information Rights Management in Exchange 2010,"  I describe some of the powerful newInformation Rights Management (IRM) features in Microsoft Exchange Server 2010, including the use of Transport Rules to automatically apply rightsprotection to email messages and the ability to consume rights-protected email messages in Outlook Web Access (OWA), making it easier to protect yourcompany's most sensitive information as it flows through email. In this article, I describe the new features in Microsoft Outlook 2010 that you can useto further expand data protection, and I explain how to configure your servers and end user systems to take advantage of these features.

Creating Outlook Protection Rules

Although Exchange 2010 has powerful IRM features, there's always the concern that a user might send a sensitive email message that's unprotected (e.g.,over a public network) until it reaches your Exchange 2010 server and is detected and processed by a Transport Rule. In large organizations, where manysensitive email messages are sent, you might not want to rely on the use of Transport Rules because heavy use can affect performance.

Transport Rules have numerous potential performance problems, ranging from rules that require in-depth analysis of email and attachments, to theactions that must be performed when a rule fires (such as encrypting an email and attachments). The potential performance effect depends on the type ofrules, the actions that must be performed, and how often they fire (typically tied to mail volume).

Depending on compliance obligations, your company might need to encrypt certain types of data, including email messages with information aboutcustomers, before transmitting it from a desktop or laptop. In addition, you might not have Exchange 2010 fully deployed yet, meaning you can't takeadvantage of IRM features in Exchange 2010 Transport Rules. For all these reasons, you should consider using the new IRM feature in Outlook 2010 calledOutlook protection rules.

Outlook protection rules aren't as sophisticated as Transport Rules and are limited to applying rights protection to email messages based on one ormore of the following three criteria: the department or group the sender of the email message is in; the recipient email address; and the scope of theemail message (whether the recipients are inside or outside the organization). The protection rules are created on your Exchange 2010 servers usingPowerShell scripts. You need Exchange 2010 deployed sufficiently so that rules can be distributed to Outlook 2010 by using Exchange web services.

Outlook protection rules are based on rights policy templates. You need to create these templates on your Active Directory (AD) Rights ManagementServices (RMS) servers. If you already have existing templates that will apply the policies you need, then you can reuse them. You can enumerate thelist of templates available from the Exchange Management Shell (EMS) using the command Get-RMSTemplate. The list returned will always contain thedefault template named Do Not Forward. You need to be careful, though, when creating or using existing templates because it's possible to create anOutlook protection rule that specifies a particular template be used with a set of users and rights that will render rights-protected email messagesunreadable by recipients or might allow recipients to forward the email messages or even print them. Always check the rights specified in a templatebefore using it.

You might find it simpler to create new templates that specify Anyone as a consumer of rights-protected content, rather than specific named users, andensure that the right to forward an email message isn't selected in those templates. This configuration will ensure that all users can read an emailmessage they receive that was rights protected by an Outlook protection rule but can't forward the email message to anyone else.

After you have your rights policy templates set up, you create your Outlook protection rules using the New-OutlookProtectionRule cmdlet in the EMS. Youcan't create Outlook protection rules using the Exchange Management Console (EMC) or Exchange Control Panel (ECP). There are only two requiredparameters to the cmdlet. The first is the name of the Outlook protection rule and is specified by the argument -Name <rule name>.You'll use the rule name to manage the Outlook protection rule. The second required parameter is the name of the rights policy template and isspecified by the argument -ApplyRightsProtectionTemplate <rights policy template>. In addition to specifying the rule name and rightspolicy template to be applied, you need to specify the conditions under which the rule will be applied.

To specify that a rule is applied when the sender is from a particular department, use the -FromDepartment <department name> argument,where <department name> is one or more departments that the rule should apply to. The argument <department name> ischecked against the department attribute on the user object corresponding to the user sending the email message to see if a match exists and whether ornot the rule should apply. You can set users' departments by editing the Department field on the Organization tab of one or more users' Propertiesdialog box, which can be viewed in the EMC or in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in.

To apply a rule based on the recipient, use the -SentTo <recipient name> argument. The <recipient name> parameter can bethe names of one or more recipients in Outlook's address book and can be one or more SMTP addresses (which are typically used for external recipients).Note that if you create a rule that specifies a distribution or mail-enabled security group, the rule won't apply when an email message is sent to oneor more members of the group without using the group name. The rule will apply only when the group name specified in the rule matches a recipient onthe To:, Cc:, or Bcc: lines in Outlook.

The condition you can specify is the scope of recipients, using -SentToScope <scope>. The two possible values for <scope>include InOrganization and All. InOrganization specifies that the rule applies when the recipients are internal to the organization; All specifies thatthe rule applies regardless of who the recipient is. Although this rule can be used on its own, it's typically used as a modifier to either or both ofthe previous two rules.

If you create many Outlook protection rules, you might end up with two or more rules that apply based on the department the sender is in, the intendedrecipient(s) of the email message, and the scope of the recipient(s). You can control the order in which rules apply by using the argument -Priority<n>, where n is a number. The default priority is 0. Rules with lower priorities are checked first. When a rule match is found,the specified template is applied, and processing stops. When a rule is matched and a template is applied, the user can choose to override the Outlookprotection rule. To prevent a user from overriding a rule, and to force a template to be applied, you can supply the argument -UserCanOverride $false.

The following command creates an Outlook protection rule that applies the rights policy template FTE Only to all email messages sent to thedistribution group InfoSec Research FTE and that can be overridden by the sender:

New-OutlookProtectionRule -Name "InfoSec Research FTE - FTE Only" -ApplyRightsProtectionTemplate "FTE Only" -SentTo "InfoSec Research FTE" 

You can enumerate the Outlook protection rules on your systems from the EMS with the cmdlet Get-OutlookProtectionRule. Rules can be enabled anddisabled by using the cmdlets Enable-OutlookProtectionRule and Disable-OutlookProtectionRule and can be deleted with the cmdletRemove-OutlookProtectionRule. All four cmdlets let you specify the rule with the argument -Identity <rule name>. Finally, a rule can bemodified using Set-OutlookProtectionRule, specifying the rule to modify using the -Identity parameter. The other parameters accepted by this cmdlet areidentical to those used in New-OutlookProtectionRule.

Configuring End Users' Systems for Outlook Protection Rules

Before templates specified in Outlook protection rules can be applied to email messages, the rights policy templates specified must be available toOutlook. The built-in template Do No Forward is always available, and any Outlook protection rules that use that template will work without anyconfiguration of end users' systems.

Rights policy templates are XML files; it's common to configure AD RMS to store them on a central file share and to configure Microsoft Officeapplications to point to the file share so that these templates are available to users. An alternative is to copy the templates to users' machines andconfigure Office applications to access them on a local drive.

Prior to Windows Vista, distributing rights policy templates meant periodically running a custom script or application to copy templates from a centralshare. However, in Vista and later, as well as in Windows Server 2008 and later, built-in Task Scheduler templates work with AD RMS to download rightspolicy templates, as Figure 1 shows.

Figure 1: Automatically updating AD RMS rights policy templates

The first template is intended to be used by domain-joined end user systems; it runs at a preset time (3:00 a.m.) and when a user logs on. The secondtemplate is intended to be used on systems that aren't domain joined; it requires you to override the EnterprisePublishing registry entry used bynon-domain-joined AD RMS clients.

Each task, when run, checks to see whether the user has obtained templates in the past 30 days or more. If so, the task contacts the AD RMSinfrastructure to obtain rights policy templates. It can take as long as an hour after a user logs on to a system for the scheduled task to run, aswell as to copy templates, if required. The templates are stored in the folder %LocalAppData%MicrosoftDRMTemplates. The folder %LocalAppData% ismapped to the folder AppDataLocal in each user's profile folder, which is typically C:Users<username>. If you change templatesfrequently and need the tasks to fetch templates more often than every 30 days, you can create a DWORD registry entry called UpdateFrequency under theHKEY_CURRENT_USERSoftwareMicrosoftMSDRMTemplateManagement registry entry. The value of the registry entry is the number of days that should elapsebefore checking for new, changed, or deleted templates.

Configuring the Task Scheduler on each end user's machine to download rights policy templates probably isn't feasible for your organization if you haveseveral end user systems. Instead, you can use an alternative method, such as a network share configured as an offline folder on the client. Anotheralternative is to run a logon script to copy templates, as you probably did pre-Vista.

Regardless of how you distribute templates to end users' systems, you need to set a per-user registry entry to configure Microsoft Office 2010 to findthe templates. This registry entry is HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0CommonDRM for 32-bit editions of Office 2010 running on 32-biteditions of Windows and 64-bit editions of Office 2010 running on 64-bit editions of Windows. For 32-bit editions of Office 2010 running on 64-biteditions of Windows (which is the default when installing Office 2010 on a 64-bit edition of Windows), the registry entry isHKEY_CURRENT_USERSoftwareWow6432NodeMicrosoftOffice14.0CommonDRM. The registry entry is AdminTemplatePath, and the entry type is ExpandableString Value.

You don't need to visit each of your end users' systems to configure the correct registry entry if you download and install the Office 2010Administrative Template files and Office Customization Tool.The download includes various templates that can be used to create Group Policy Objects (GPOs) that can control many aspects of Office 2010, includingwhere it searches for rights policy templates. Make sure you download the correct pack—there are packs for the 32-bit and 64-bit editions of Office2010.

To configure the AdminTemplatePath setting for your end users by using a Group Policy setting, download and install the administrative templates (underthe ADMX folder) to C:WindowsPolicyDefinitions or to the Group Policy central store. Alternatively, you can manually add the file office14.admtemplate to the Group Policy Management Editor. Create a new GPO, open it for editing, and navigate to User ConfigurationPoliciesAdministrativeTemplatesMicrosoft Office 2010 (there's a node for legacy administrative templates above the last node if you use the ADM file). Select the nodeManage Restricted Permissions, then double-click Specify Permission Policy Path in the right-hand pane. In the Specify Permission Policy Path dialogbox, select Enabled and enter the path to the rights policy templates, as Figure 2 shows.

Figure 2: Specifying a path for policy permissions

If you're using Offline Folders, this folder will be shared. If you're copying files to end users' machines, the templates will be stored in thisfolder. After the GPO is created, link it to an organizational unit (OU) that your users are in.

A large gotcha when using GPOs to set the AdminTemplatePath setting for use by Office applications is that the registry entry is fixed as a REG_SZtype, which means you can't use a variable such as %LocalAppData% when specifying the location of the rights policy templates—which pretty muchprecludes using a GPO to point to the Templates folder populated by the Task Scheduler. For this reason, I recommend setting AdminTemplatePath to thefile share where RMS templates are stored and configuring administratively assigned offline files (under User ConfigurationPoliciesAdministrativeTemplatesNetworkOffline Files) to add the location of the share where the templates are stored in the same GPO. This configuration ensures that themost recent templates are available to end users (without waiting for the Task Scheduler to pick them up) and available offline for laptop users whenthey disconnect from the network.

You can test the availability of templates to Outlook 2010 by logging on as a user who has AdminTemplatePath GPO settings, creating a new emailmessage, and selecting the Permission drop-down on the Options tab, as Figure 3 shows. If templates are available, they're listed between Do NotForward and Manage Credentials.

Figure 3: Checking template availability

End User Experience with Outlook Protection Rules

The end user experience with Outlook protection rules is seamless. When an email message matches one of the Outlook protection rules' specifiedconditions, the appropriate rights policy template is applied to the email message and a visual cue is presented, as Figure 4 shows. Unless the rulespecifies that the user can't override the rights policy template, the user can select the Permission drop-down on the message's Options tab and selectNo Restrictions. (The rights policy template that was applied to the message will have a checkmark next to it, as Figure 5 shows.)

Figure 4: Notification of Outlook protection rule application

Figure 5: Checkmark indicating applied rights policy template

One thing Outlook protection rules can't do is prevent end users from sending sensitive email messages without protection when using a browser, OWA, ora mobile device. You should therefore consider using Outlook protection rules in conjunction with Exchange 2010 Transport Rules to create acomplementary IRM strategy. You can also prevent users with desktops and laptops from using OWA to send email messages, to ensure that Outlookprotection rules aren't bypassed.

Extend Your Protection

Outlook protection rules let you extend protection of sensitive information to the desktop and can help you meet specific compliance obligations. Theycomplement Exchange 2010's Transport Rules nicely, and they can even be used to do away with the need for some Transport Rules, which helps offloadprocessing from your Exchange 2010 infrastructure.