Exchange Server 2010 : Managing Transport Rules (part 3) - Configuring Disclaimers, Rights Protection & IRM

3. Configuring Disclaimers

A disclaimer is a statement that is added to email messages when they enter or leave an Exchange Server 2010 organization. You can apply multiple disclaimers to a single email message when that message matches more than one transport rule on which a disclaimer action is configured. The messages in disclaimers are typically of a legal nature, although you can use the same technique to add signatures or other organizational information.

You create a new disclaimer by creating a new transport rule (or modifying an existing one), and you have the option of specifying conditions or exceptions. If, however, you want the disclaimer to be added to all messages, you should not configure any conditions or exceptions.

You can use either the EMC or the EMS to configure a disclaimer. The high-level procedure to configure a disclaimer using the EMC is as follows:

You can use the EMS to create a transport rule that applies a disclaimer. The following command applies the disclaimer “The Adatum Corporation supports all Government initiatives to control global warming.” to all messages sent outside the Adatum organization and sets the fallback action to wrap:

New-TransportRule -Name ExternalDisclaimer -Enabled $true -SentToScope
'NotInOrganization' -ApplyHtmlDisclaimerLocation 'Append' -ApplyHtmlDisclaimerText
"<h3>Adatum Corporation Policy</h3><p> The Adatum Corporation supports all Government
initiatives to control global warming.</p>" -ApplyHtmlDisclaimerFallbackAction Wrap

					  

4. Configuring Rights Protection

Organizations typically transmit sensitive and confidential information through email on a daily basis. Such organizations need to protect the privacy of individuals and the confidentiality of communications. You can implement privacy and confidentiality requirements by configuring IRM. This permits your organization and your users to apply persistent protection to messages so that access is restricted to authorized users and permitted actions (such as forwarding, copying, and printing messages).

RMS includes all the server and client technologies that are required to support IRM in an organization. Exchange Server 2010 ships with the Do Not Forward RMS template. When this template is applied to a message, only the recipients addressed in the message can decrypt the message. Recipients cannot forward the message to anyone else, copy content from the message, or print the message.

4.1. Installing an AD RMS Server

If the Do Not Forward RMS template is not adequate for your needs, you can apply for other templates from an AD RMS server installed on your organization. This server role is typically installed on a member server and preferably not on a domain controller, although it can be installed on the domain controller in a small network. An AD RMS server is a good candidate for virtualization. The AD RMS role should not be installed on an Exchange Server 2010 server because Microsoft does not support this configuration in a production environment.

A full AD RMS installation is beyond the scope of this book and the 70-662 examination. However, if you want to study AD RMS and the facilities it provides out of professional interest, the steps to install an AD RMS server are as follows:

• Create a CNAME Domain Name System (DNS) record to use in the AD RMS cluster URL.

• Create a service account and four global security groups that are required for AD RMS administration delegation.

• Create and install a Web server certificate. This is required because AD RMS requires Secure Sockets Layer (SSL)–encrypted web connections.

• Install the AD RMS server role.

Note:

AD RMS CLUSTERS

An AD RMS cluster is the term used for an AD RMS deployment in an organization. It can include a single server deployment. AD RMS is a Web service and does not require you to set up a Windows Server 2008 (or Windows Server 2008 R2) failover cluster.

Configuring and using IRM features requires that the RMS prelicensing agent is enabled on a Hub Transport server. This agent is installed by default and enabled when you enable the IRM feature.

To access IRM-protected content, RMS-enabled applications must procure a use license for the authorized user, and this can be obtained from the prelicensing agent without the need to apply to an AD RMS server. This permits you to apply RMS templates to messages sent to a specified Simple Mail Transport Protocol (SMTP) address and configure rights protection by using transport rules.

The following EMS command enables licensing and hence enables IRM features for messages sent to internal recipients. Internal licensing is disabled by default for internal recipients:

Set-IRMConfiguration -InternalLicensingEnabled $true

In on-premises deployments, licensing is disabled for external messages by default. Note that IRM-protected messages sent to external recipients require that a federated trust exist between your Active Directory forest and that of the recipient organization. The following command enables licensing and hence enables IRM features for messages sent to external recipients:

Set-IRMConfiguration -ExternalLicensingEnabled $true

Enabling IRM enables the RMS prelicensing agent by default. If, however, the prelicensing agent is disabled, you can enable it by entering the following EMS command:

Enable-TransportAgent "Prelicensing Agent"

You then need to restart the MSExchangeTransport service for the agent to become active.

If you want to disable the RMS prelicensing agent, you enter the following command:

Disable-TransportAgent "Prelicensing Agent"

To obtain details about the RMS prelicensing agent, you enter the following command:

Get-TransportAgent "Prelicensing Agent"

5. Configuring IRM

Typically, company mailboxes contain large amounts of potentially sensitive information, and information leakage poses a serious threat. In addition, company policy and industry regulations govern how certain types of information are stored, transmitted, and secured. To help address these issues, Exchange Server 2010 offers IRM features that provide persistent online and offline protection of email messages and attachments.

Exchange Server 2010 IRM uses the Windows Server 2008 and Windows Server 2008 R2 information protection technology AD RMS. AD RMS uses Extensible Rights Markup Language (XrML)–based certificates and licenses to certify computers and users and to protect content. When content is protected by using AD RMS, an XrML license containing the rights that authorized users have to the content is attached. To access IRM-protected content, AD RMS–enabled applications must procure a use license for the authorized user from the AD RMS cluster. In Exchange 2010, the prelicensing agent attaches a use license to protected messages without needing to access an AD RMS server.

IRM enables an organization and its users to control the rights that recipients are granted for email messages. It also helps control recipient actions, such as forwarding a message to other recipients, printing a message or attachment, or extracting message or attachment content by copying and pasting. Users can apply IRM protection in Microsoft Outlook or Outlook Web App (OWA). As an administrator, you can configure your organization’s messaging policies and apply them by using transport protection rules or Outlook protection rules. IRM also enables your organization to decrypt protected content and enforce policy compliance.

IRM protection is configured by applying an AD RMS rights policy template. You can use policy templates to control permissions that recipients have on a message.

Note:

RMS-ENABLED APPLICATIONS

Microsoft Office applications, such as Microsoft Word, Microsoft Excel, and Microsoft PowerPoint, are RMS enabled and can be used to create protected content.

5.1. AD RMS Rights Policy Templates

AD RMS uses XrML-based rights policy templates to allow compatible IRM-enabled applications to apply consistent protection policies. Exchange 2010 ships with the Do Not Forward template. When this template is applied to a message, only the recipients addressed in the message can decrypt the message, and these recipients cannot forward the message to anyone else, copy content from the message, or print the message. If an AD RMS server is present in your organization, you can create additional RMS templates to meet your IRM protection requirements.

The following EMS command retrieves the list of active rights management services policy templates that are currently available to the Exchange Server 2010 Hub Transport server on which the command is run:

Get-RMSTemplate

Note, however, that because the Do Not Forward template ships with Exchange Server 2010, it is not listed by this command. The Get-RMSTemplate command lists any additional templates that you obtain from an AD RMS server and returns a blank list by default.

DO NOT INSTALL AD RMS AND EXCHANGE SERVER 2010 ON THE SAME COMPUTER

Installing AD RMS and Exchange Server 2010 on the same computer is not supported in a production environment.

5.2. Applying IRM Protection

IRM protection can be applied to messages manually by Outlook users. This process uses the IRM functionality in Outlook, but you can use Exchange to take actions (such as applying transport rules) that enforce your organization’s messaging policy. OWA users can protect messages they send and view IRM-protected messages they receive.

In Outlook 2010, you can create Outlook protection rules that automatically IRM-protect messages. Outlook 2010 applies IRM protection when a user is composing a message. You can also create transport rules on Hub Transport servers that automatically IRM-protected messages. Note that you cannot IRM-protect a message that is already IRM protected. If a user IRM-protects a message in Outlook, you cannot then apply IRM protection using a transport rule.

You can IRM-protect messages sent to mailbox users or distribution groups within your Exchange organization, but you cannot directly IRM-protect messages sent to recipients outside your organization unless you create a federated trust between your Active Directory forest and the forest that contains the external users by using Active Directory Federation Services. Because external distribution list or distribution group expansion does not occur within the sending Exchange organization, IRM-protected messages sent to external distribution groups contain a license for the group but not for group members, who are therefore unable to access the message.

5.3. Decrypting IRM-Protected Messages

Administrators need to be able to access encrypted message content so that they can enforce messaging policies and ensure regulatory compliance. They must also be able to search encrypted messages to meet the requirements of litigation, regulatory audits, or internal investigations. To help with these tasks, Exchange 2010 includes the following IRM features:

• Transport decryption This allows transport agents (such as the transport rules agent) installed on Exchange 2010 servers to access message content.

• Journal report decryption You can use journaling to preserve messaging content and meet compliance or business requirements. The Exchange Server 2010 journaling agent creates a journal report for messages subject to journaling and includes metadata about the message in the report. If the message in a journal report is IRM protected, journal report decryption attaches a clear text copy.

• IRM decryption for Exchange Search This enables Exchange Search to index content in protected messages. When a discovery manager uses a Multi-Mailbox Search to perform a discovery operation, indexed protected messages are returned in the search results.
  

To enable these decryption features, Exchange servers must be able to access the message. This is accomplished by adding the Federated Delivery mailbox, a system mailbox created by Exchange Setup, to the super users group on the AD RMS server. If a distribution group has been created and configured as a superusers group in the AD RMS cluster, you can add the Exchange 2010 Federated Delivery mailbox as a member of that group. If a superusers group is not configured, you need to create a distribution group and add the Federated Delivery mailbox as a member.

The following command adds the Federated Delivery mailbox FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 to the ADRMSSuperUsers distribution group:

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

Transport agents, known as IRM agents, enable IRM functionality on Hub Transport servers. IRM agents are installed by Exchange Setup. Table 1 lists the IRM agents implemented on Hub Transport servers.

You can use the EMS but not the EMC to configure IRM features. The Set-IRMConfiguration EMS cmdlet is used to enable or disable IRM for internal messages and to enable or disable transport decryption, journal report decryption, IRM for Exchange Search, and IRM in OWA.

As discussed previously in the prelicensing section of this lesson, the following command enables licensing and hence enables IRM features for messages sent to internal recipients:

Set-IRMConfiguration -InternalLicensingEnabled $true

IRM features can be applied to messages to external recipients only if an appropriate federated trust has been configured. The following command enables licensing and hence enables IRM features for messages sent to external recipients if external licensing is currently disabled and a federated trust is configured:

Set-IRMConfiguration -ExternalLicensingEnabled $true

IRM features are enabled in OWA by default. The following command disables IRM features in OWA:

Set-IRMConfiguration -OWAEnabled $false

The following command enables IRM features in OWA if they have previously been disabled:

Set-IRMConfiguration -OWAEnabled $true

If transport decryption is mandatory, any message that cannot be decrypted is rejected and a non-delivery report (NDR) is returned to the sender. The following command sets transport decryption to mandatory:

Set-IRMConfiguration -TransportDecryptionSetting mandatory

If transport decryption is disabled, no attempt is made to decrypt internal or external messages before delivery. The following command sets transport decryption to disabled:

Set-IRMConfiguration -TransportDecryptionSetting disabled

Setting transport decryption to optional provides a best-effort approach to decryption. Messages are decrypted if possible but are delivered even if decryption fails. The following command sets transport decryption to optional:

Set-IRMConfiguration -TransportDecryptionSetting optional

Notice that parameters such as OWAEnabled that take Boolean values are set to $true or $false. However, non-Boolean parameters, such as TransportDecryptionSetting, are not set to values that have an initial $ symbol.

If you want to view the current IRM configuration—either the default values before you configure it or the values after configuration—you enter the following command:

Get-IRMConfiguration | FL

Figure 8 shows a typical output of this command.

After you configure IRM, you can use a command based on the Test-IRMConfiguration EMS cmdlet to perform end-to-end tests of your IRM deployment. These tests verify IRM functionality immediately after initial IRM configuration and on an ongoing basis. Commands based on this cmdlet perform the following tests:

• Inspect IRM configuration in your Exchange Server 2010 organization.

• Check the AD RMS server for version and hotfix information.

• Verify whether an Exchange server can be activated for RMS by retrieving a Rights Account Certificate and Client Licensor Certificate.

• Acquire AD RMS rights policy templates from the AD RMS server.

• Verify that the specified sender can send IRM-protected messages.

• Retrieve a superuser use license for the specified recipient.

• Acquire a prelicense for the specified recipient.

For example, the following command tests the IRM configuration for messages that Kim Akers sends to Don Hall:

Test-IRMConfiguration -Sender KimAkers@adatum.com -Recipient DonHall@adatum.com