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 many sensitive 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 the actions that must be performed when a rule fires (such as encrypting an email and attachments). The potential performance effect depends on the type of rules, 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 about customers, before transmitting it from a desktop or laptop. In addition, you might not have Exchange 2010 fully deployed yet, meaning you can't take advantage of IRM features in Exchange 2010 Transport Rules. For all these reasons, you should consider using the new IRM feature in Outlook 2010 called Outlook 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 or more 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 the email message (whether the recipients are inside or outside the organization). The protection rules are created on your Exchange 2010 servers using PowerShell 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 Management Services (RMS) servers. If you already have existing templates that will apply the policies you need, then you can reuse them. You can enumerate the list of templates available from the Exchange Management Shell (EMS) using the command Get-RMSTemplate. The list returned will always contain the default template named Do Not Forward. You need to be careful, though, when creating or using existing templates because it's possible to create an Outlook protection rule that specifies a particular template be used with a set of users and rights that will render rights-protected email messages unreadable by recipients or might allow recipients to forward the email messages or even print them. Always check the rights specified in a template before 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, and ensure that the right to forward an email message isn't selected in those templates. This configuration will ensure that all users can read an email message 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. You can't create Outlook protection rules using the Exchange Management Console (EMC) or Exchange Control Panel (ECP). There are only two required parameters 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 is specified by the argument -ApplyRightsProtectionTemplate <rights policy template>. In addition to specifying the rule name and rights policy 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> is checked against the department attribute on the user object corresponding to the user sending the email message to see if a match exists and whether or not the rule should apply. You can set users' departments by editing the Department field on the Organization tab of one or more users' Properties dialog 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 be the 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 one or 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 on the 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 that the 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 of the 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 intended recipient(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 Outlook protection 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 the distribution 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 and disabled by using the cmdlets Enable-OutlookProtectionRule and Disable-OutlookProtectionRule and can be deleted with the cmdlet Remove-OutlookProtectionRule. All four cmdlets let you specify the rule with the argument -Identity <rule name>. Finally, a rule can be modified using Set-OutlookProtectionRule, specifying the rule to modify using the -Identity parameter. The other parameters accepted by this cmdlet are identical 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 to Outlook. The built-in template Do No Forward is always available, and any Outlook protection rules that use that template will work without any configuration 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 Office applications to point to the file share so that these templates are available to users. An alternative is to copy the templates to users' machines and configure 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 central share. 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 rights policy 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 second template is intended to be used on systems that aren't domain joined; it requires you to override the EnterprisePublishing registry entry used by non-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 RMS infrastructure 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, as well as to copy templates, if required. The templates are stored in the folder \%LocalAppData%\Microsoft\DRM\Templates. The folder \%LocalAppData% is mapped to the folder \AppData\Local in each user's profile folder, which is typically C:\Users\<username>. If you change templates frequently and need the tasks to fetch templates more often than every 30 days, you can create a DWORD registry entry called UpdateFrequency under the HKEY_CURRENT_USER\Software\Microsoft\MSDRM\TemplateManagement registry entry. The value of the registry entry is the number of days that should elapse before 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 have several end user systems. Instead, you can use an alternative method, such as a network share configured as an offline folder on the client. Another alternative 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 find the templates. This registry entry is HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\DRM for 32-bit editions of Office 2010 running on 32-bit editions 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-bit editions of Windows (which is the default when installing Office 2010 on a 64-bit edition of Windows), the registry entry is HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Office\14.0\Common\DRM. The registry entry is AdminTemplatePath, and the entry type is Expandable String 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 2010 Administrative 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, including where 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 Office 2010.
To configure the AdminTemplatePath setting for your end users by using a Group Policy setting, download and install the administrative templates (under the ADMX folder) to C:\Windows\PolicyDefinitions or to the Group Policy central store. Alternatively, you can manually add the file office14.adm template to the Group Policy Management Editor. Create a new GPO, open it for editing, and navigate to \User Configuration\Policies\Administrative Templates\Microsoft Office 2010 (there's a node for legacy administrative templates above the last node if you use the ADM file). Select the node Manage Restricted Permissions, then double-click Specify Permission Policy Path in the right-hand pane. In the Specify Permission Policy Path dialog box, 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 this folder. 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_SZ type, which means you can't use a variable such as %LocalAppData% when specifying the location of the rights policy templates—which pretty much precludes using a GPO to point to the Templates folder populated by the Task Scheduler. For this reason, I recommend setting AdminTemplatePath to the file share where RMS templates are stored and configuring administratively assigned offline files (under \User Configuration\Policies\Administrative Templates\Network\Offline Files) to add the location of the share where the templates are stored in the same GPO. This configuration ensures that the most recent templates are available to end users (without waiting for the Task Scheduler to pick them up) and available offline for laptop users when they 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 email message, and selecting the Permission drop-down on the Options tab, as Figure 3 shows. If templates are available, they're listed between Do Not Forward 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' specified conditions, the appropriate rights policy template is applied to the email message and a visual cue is presented, as Figure 4 shows. Unless the rule specifies 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 select No 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, or a mobile device. You should therefore consider using Outlook protection rules in conjunction with Exchange 2010 Transport Rules to create a complementary IRM strategy. You can also prevent users with desktops and laptops from using OWA to send email messages, to ensure that Outlook protection 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. They complement Exchange 2010's Transport Rules nicely, and they can even be used to do away with the need for some Transport Rules, which helps offload processing from your Exchange 2010 infrastructure.
