In the previous part of this article, we mainly talked about the basics of Rights Management Services (RMS). We went through the setup process and reviewed how AD RMS actually worked.
In this second part of the article, we will focus on the following topics:
- Client-Side Configuration
- Rights Policy Templates
- IRM, Configuration
We will continue using the RMS server we set up earlier and will also make use of a Windows 7 client, installed with Microsoft Office 2010.
As we talked about before, RMS is not solely a server-side component. There is an important client-side part as well. In order to use AD RMS, the client who tries to either create/open rights protected content needs to be able to ‘talk’ to the RMS Server. By default, each Operating System as from Windows Vista has the RMS-client installed by default.
Check out the following link if you need to have more information about the client or if you need to install it on older OS versions:
The RMS client, will try to locate the RMS server using the SCP that was registered during RMS setup. If an SCP exists, the client queries the server in order to obtain the licensing URL. This URL is needed to create rights protected content. If no SCP is found (because it was not registered or is incorrectly configured or in certain specific cases (multi-forest environment, external users…)), there is always an option to “override” this procedure and to – manually – provide the information to the client through some registry keys:
The keys for x64-clients are located in:
- x64: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\MSDRM\ServiceLocation.
Creating Rights Policy Templates
Rights protected content consists of content to which certain usage-rights have been “glued”. So-called Rights Policy Templates are used to provide a client with the ability to protect content. These templates are ‘collections’ of one or more different usages rights (for one or more users) that you can apply to the content you’d like. For instance, you could create a template called “Do Not Print” in which you define that none is allowed to print content that is protected with this template.
Templates are created on the RMS server and made available through a file-share of your choice. This file share is needed because in order to use templates, they have to be downloaded to the client.
Let’s configure a file share on the RMS server and create a simple template.
Open up the RMS Console and navigate to “Rights Policy Templates”:
From the result-pane, click “Change distributed rights policy templates file location”:
Now, provide a network share and confirm:
From the actions pane, click “Create Distributed Rights Policy Template”:
Click “Add” and enter the information needed. In this example we will be creating a template that will prohibit content to be printed. The description that you enter is also the description that a user will see in his application when selecting the template. So make sure that your description is clear enough. Confirm and click Next.
In the following window, we will be configuring the different rights for different users. This can be as simple as a single rule for all users to multiple rules for multiple users/groups.
Click Add. Select a user or a group (or select Anyone) and click OK.
Select the user/group you’ve just added and enable the rights you’d like this group to have. Since we are going to create a template that prohibits printing, we need to select all options except: Full Control, Print and Edit Rights. Whether you allow macros, viewing of rights etc., is your choice:
Click Next. Specify an expiration date (if applicable) and click Next.
Select the appropriate options and click Next.
Note: The “Enable users to view protected content using a browser add-on” allows non-rms capable clients to view protected content using e.g. Internet Explorer (called RMH; Rights Managed HTML). However to use this option, the protected document should contain the RMH encoded version. For more information, please view: http://technet.microsoft.com/en-us/library/dd772746(WS.10).aspx
Provide the necessary details, if revocation for this template, and click Finish.
You will notice that a new template has been created:
Distributing Rights Policy Templates
As we explained before, Rights Policy Templates need to be locally available to the client before you can start using them. Prior to Windows Vista SP1, this was a “manual” process where the templates had to be copied locally manually (or using a self-created script).
As from Windows VIsta SP1, this process can be automated more easily through the use of a pre-defined Scheduled Task:
By default, the task is disabled. You can enable this task either using a GPO or directly through the Task Scheduler. The task will run up to one hour after logon of the user or every day at 03:00. Remember that this task will only work on computers that are joined to the domain. The second task can be used for non domain-joined computers. For more information about these tasks and Template propagation, please visit: http://technet.microsoft.com/en-us/library/dd996658(WS.10).aspx
Now that we’ve enabled the task, we need to configure the client computer with the template download path (path where the templates can be found; we configured it earlier when creating a template). You can deploy these settings directly through the registry editor or using GPO/GPP. Here we’ll focus on the manual configuration through the registry editor:
Open the Registry Editor (regedit.exe) and navigate to the following key:
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\DRM (you can replace 14.0 with 12.0 if you are using Office 2007 and not Office 2010):
Create a new key: right-click and select New > Expandable String value and provide the following information:
The path “%LocalAppData%\Microsoft\DRM\Templates corresponds to C:\Users\<username>\Microsoft\DRM\Templates.
In order to ‘force’ the download of the templates, log off and the re-log on. Verify that the templates have been copied over successfully:
If you would like to know more about Template Distribution (e.g. with older clients or through alternative ways like e.g. GPO or logon scripts), check the following TechNet Article: http://technet.microsoft.com/en-us/library/dd996658(WS.10).aspx
Configuring Exchange 2010 with IRM
Exchange 2010 IRM leverages AD RMS and allows to protect messages and attachments. IRM can be used by both Outlook- and OWA-users or it IRM can be applied automatically using either Outlook Protection rules or directly on the Hub Transport Servers using transport protection rules.
Today, we’ll discuss the basic setup for IRM in Exchange 2010. In the next part of this article, we’ll be talking about the different scenario’s of protecting content.
Up till this point we’ve setup AD RMS on a Windows Server 2008 R2 server and have configured some templates. In order for Exchange 2010 to be able to use RMS, we need to provide our Exchange Servers (and the RMS Service Group) with “Read & Execute” rights on the ServerCertification.asmx-file, located in the AD RMS root (web)directory. By default only the Local System Accounts has access to this file. The file is usually located in the \Inetpub\wwroot\_wmcs\Certification-folder:
Note: You should repeat this step for all RMS servers in the cluster, if you have more then one.
Next, we should make sure that the Federation Mailbox is added to the AD RMS Super Users. This is necessary in order for functions such as transport decryption, IRM in Outlook Web App, IRM in Exchange Search… to work.
First, create a new Distribution Group. You can do this either through the EMC or EMS using the New-DistributionGroup cmdlet:
New-DistributionGroup –Name “AD RMS Super Users”
Once the group has been created you should add the federation mailbox to this group. Again, this can be done either through EMC or EMS:
Add-DistributionGroupMember “AD RMS Super Users” –member FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042
We now need to define the “AD RMS Super Users” distribution group as the Super Users Group in AD RMS.
Open the AD RMS console and navigate to “Security Policies” > “Super Users”.
From the Actions Pane, click “Enable Super Users”. Click “Change Super Users Group” from the result pane:
Provide the “AD RMS Super Users” group and confirm:
That’s it. You should be able to start using IRM (internally) now. By default the Internal Licensing –feature is enabled by default. If not, you can enable it using the following cmdlet:
Set-IRMConfiguration –InternalLicensingEnabled $true
In order to test/validate our configuration, you can run the following cmdlet from the EMS:
The cmdlet will test different aspects of the IRM configuration:
We’ve successfully created a template that has been distributed to our clients so that they can start creating rights protected content. Our Exchange Server(s) has also been configured so that it’s able to use our AD RMS farm for IRM.
In the next part of this article, we’ll focus around using RMS (creating rights-protected content) and some advanced features like Outlook Protection Rules and Transport Protection Rules.
Michael Van Horenbeeck