The following is tip #19 from "20 Tips on securing Outlook in 20 minutes," excerpted from a chapter in Paul Robichaux's...
book, Secure Messaging with Microsoft Exchange Server 2003 © 2004, published by Microsoft Press. Return to the main page for more tips on this topic.
When you create a message (either by composing a new one or replying to or forwarding an existing message), you can use the File | Permissions command or the toolbar icon (which is the standard little yellow message envelope with the universal "do not enter" icon superimposed on it) to apply the Do Not Forward restriction. When you do so, the message InfoBar changes to show what restrictions are in place. Once the message is sent, recipients who open it in Outlook or Outlook Web Access will see that it's protected, and recipients using other clients won't be able to read the message contents. Instead, they'll see a text blurb telling them to use an RMS-aware client, along with a message attachment that uses the .rpmsg extension.
You can also use the File | Restrict Permission As command to change which set of credentials you use. This is handy if you have associated a Passport account with an RAC and simultaneously want to use one, or more, sets of corporate credentials. The credentials are associated with the user account, not with the Outlook profile.
One of the most tantalizing prospects for the combination of the Office System and the Windows RMS server is the ability to customize which rights are specified. There are a broad list of rights that apply to various pieces of the Office System, including controls that allow selective viewing, editing, saving, extracting (using copy and paste), exporting, printing, running macros, forwarding, replying, and seeing the rights associated with an object. These rights can be combined in interesting and useful ways. For example, Microsoft uses several templates internally to allow messages to be tagged with classifications like "Microsoft confidential" or "Full-time employees, read-only access." Adding more granularity to the RMS server is fairly straightforward; you have to create new templates that define the rights you want to provide and who can have them. This is easy, provided you follow the guidelines described in the online help for the RMS servers: you have to choose from the set of rights that RMS and Office both support, and the easiest way to specify who gets them is to use a universal security group defined in a domain that the RMS server has access to.
Setting up RMS client components on an individual workstation is interesting but not all that useful; the value of RMS really comes about when you can deploy it throughout an organization. There are several pieces involved in accomplishing this deployment, most of which are outside the scope of this book:
Installing the RMS client software
- The Office System supports IRM, but there's still a separate client that has to be pushed to each participating desktop. The best way to accomplish this is to package the client with your Office deployment so that it's available on all desktops.
Creating rights policy templates using the Windows RMS Administration Web pages
- These pages allow you to create custom sets of rights for various sets of users, then make those templates available from the RMS server.
Making the rights policy templates available to clients
- By using the Office11.adm Group Policy template, you can specify the name of a central server from which policies should be copied and made available to all the Office System applications (not just Outlook).
Configuring what users can do with the RMS client
- The Office policy template includes a section called Manage Restricted Permissions; by tweaking the policy settings here, you can disable the RMS user interface altogether (as you might need to if you're piloting RMS but don't want people to start randomly creating protected documents), disable the use of Passport credentials, enable or disable the use of Internet Explorer to open protected content, and control whether users must have their credentials verified every time they try to open a protected document.
The bigger issue, of course, is user training and education. It's critical that if you deploy RMS, you teach your users what can and cannot be protected. You should emphasize that RMS is primarily a technical means of more firmly enforcing the policies (like marking confidential data as such) that your company probably already has, not a way for the company to snoop on their work product.
Get more "20 Tips on securing Outlook in 20 minutes!" Return to the main page.
About the author: Paul Robichaux is a partner at 3sharp LLC, author of several books on Exchange, Windows, and security, a Microsoft MVP for Exchange Server and a frequent speaker and presenter at IT industry conferences. He's written software for everyone from the U.S. National Security Agency to scientists flying their experiments aboard the Space Shuttle, fixed helicopters in the desert and spent way too much time playing video games.