Microsoft Office SharePoint Server 2007 and RMS
Configure rights to sensitive documents in MOSS
July 4, 2007
Executive Summary:
Microsoft Office SharePoint Server (MOSS) 2007 provides many new security settings, auditing capabilities, storage policies, and document expiration actions that can aid you with regulatory compliance. |
One of these new features in Microsoft Office SharePoint Server (MOSS) 2007 is Information Rights Management (IRM). |
Learn how to configure and use Information Rights Management (IRM) in Microsoft Office SharePoint Server (MOSS) 2007. |
Microsoft Office SharePoint Server (MOSS) 2007 is a major release and comes with many new features that will be of note to the enterprise. Of particular interest will likely be those features designed to help users meet statutory and regulatory requirements and maintain adequate information security. MOSS provides many new security settings, auditing capabilities, storage policies, and document expiration actions that can be used to follow enterprise information security policies designed with compliance in mind. Let's look at one of these new features in MOSS: Information Rights Management (IRM). Note that IRM is available only in MOSS and not in Windows SharePoint Services (WSS) 3.0.
Overview of IRM
IRM allows the author of a document or email message to define who can consume the document or email, what rights they have to the content, and how and when they can access it. For example, the author of a Word document such as a press release can specify who can open and read the document, and grant any of those people the right to print but not edit the document. A user who isn't explicitly granted rights to content can't read, edit, or print that document.
With IRM, authors can specify rights to users that are persistent, travel with the documents, and are enforced by applications, not the OS. Even a user, or rogue administrator, with Full Control access to a document at the file-system level can't read, edit, print, forward, or copy the document unless the document owner explicitly grants that user access.
IRM first debuted in the Microsoft Office 2003 applications Word, Excel, PowerPoint, and Outlook. Microsoft Office 2007 adds InfoPath to the list of applications that support IRM, and MOSS is the first Microsoft server product that supports IRM.
IRM requires an Active Directory (AD) Windows Rights Management Services (RMS) infrastructure. RMS is a Web-based service that's typically deployed throughout an entire enterprise. IRM uses an API exposed by the presence of RMS to offer content protection. RMS is responsible for issuing the certificates and licenses required by users to author and consume rights-protected content. Content is encrypted to help enforce rights protection. For more details about RMS, see "Windows Rights Management Services" (January 2004, InstantDoc ID 40951); Windows IT Pro Perspectives: "Deploying Windows Rights Management Services" (December 16, 2003, InstantDoc ID 41191); the Windows IT Pro article "Behind the Scenes with RMS" (February 2006, InstantDoc ID 48912); and http://www.microsoft.com/rms.
IRM in MOSS
IRM in MOSS is slightly different from IRM in Office applications. In applications, users manually decide who can have access to the content they author on a document-by-document or email message–by-message basis. Administrators can make life easier for users by creating and distributing rights templates that contain users and the rights afforded to each. A user can then select a template from within an application instead of manually specifying rights.
In MOSS, documents are organized into document libraries. Permissions can be set on each document library that defines what users can do with the documents stored within it. For example, a document library containing information about potential mergers and acquisitions (M&A) can be created with read-only permissions for employees who need to know about them and with rights to edit and publish new documents for members of the M&A team.
IRM can be used to secure a document library further. When IRM is applied to document libraries, users can still upload, download, or edit documents according to the permissions granted to them. However, documents downloaded or checked out of the document library for editing will be rights-protected. The rights applied to the document will reflect the permissions of the library itself.
Consider the M&A document library without IRM. Although employees have only read-only permissions, they can still download documents to a USB thumb drive, print and distribute copies of the documents, or send email messages that have documents as attachments. With IRM applied to the document library, you can prevent users from printing downloaded documents, and any documents they distribute on a USB thumb drive or by email are encrypted and therefore useless to a recipient who doesn't have access to the library they came from. Documents within the library aren't rights-protected themselves; rather IRM is used and rights are applied when a document is downloaded or checked out.
Configuring IRM in MOSS
Before you can start using IRM in MOSS, you might need to make changes to your MOSS server or farm. I recommend that you specify identities for Web application pools to avoid potential problems with IRM in MOSS.
When you use MOSS to build Web-server farms to make sites available to users, you should configure the Web application pool for each Web service to run under a named user account, not as a Network Service. The user account should be a domain user account, not a local account. Even if you install MOSS as a single server, you should avoid the use of Network Service as the identity for Web application pools. The Network Service account was designed to address security problems with LocalSystem, and Network Service impersonates the computer. Using Network Service might grant more rights to the Web application pool than is necessary. User accounts are a better idea for Web application pools.
You should also consider separating Web services so that each runs in its own Web application pool. If you run them in the same pool and the pool crashes, data from all the applications running in the pool might be disclosed to users.
You can configure the identity used for Web application pools by clicking the Operations tab in the SharePoint 3.0 Central Administration console and selecting Service Accounts in the Security Configuration section. Select the Web application pool option, and select the Web service and the application pool from the drop-down lists (as Figure 1 shows). Select the Configurable option, then enter the credentials for the user account that the Web application pool should run under.
Configuring MOSS to use IRM is a four-step process. The first step is to install Windows RMS Client SP2 on all MOSS servers in the Web farm. The second step is to prepare the RMS server for use by MOSS. Third, you configure the MOSS server or farm by pointing it to your RMS infrastructure. Fourth, you configure each document library to use IRM.
Installing RMS Client SP2 is simple. You can download the client from http://www.microsoft.com/rms, or you can install it from Windows Update. Make sure that the setup runs to completion on each server in the Web farm.
The second step is carried out on your RMS server. If you're not yet running RMS SP2, you should upgrade your server with this service pack. You also need to change the permissions on the _wmcs/Certification/ServerCertification.asmx file. You’ll find this file in the folders belonging to the Web site that RMS is running in. Make sure that the ServerCertification.asmx file inherits permissions from the parent folder (_wmcs/Certification), and add the machine accounts for every server in the Web farm. You also need to make sure that the service accounts used by MOSS to access the configuration database and the accounts used for each Web application pool are members of the Domain Users group. IRM can potentially use the machine accounts and the service accounts in calls to RMS.
To complete the third step, configuration of the MOSS server or farm to use RMS, click the Operations tab in the SharePoint 3.0 Central Administration console and select Information Rights Management in the Security Configuration section. If you haven't installed RMS Client SP2, or if there's a problem with the installation, you'll see an error message. You should correct the error before attempting to configure MOSS to use IRM.
If there's no error message and you've published the RMS serviceConnectionPoint object in AD from the RMS administration console, you can select the Use the default RMS Server specified in Active Directory option. If you have a subenrolled RMS Licensing Server that you wish to use instead, or if you haven't published the RMS serviceConnectionPoint object in AD, select the Use this RMS server option and enter the URL of your RMS server (as Figure 2 shows).
There's not much in the way of confirmation that configuration of MOSS to use RMS was successful, and nothing is logged to the event log. One way to check for success is to open the %ALLUSERSPROFILE%Application DataMicrosoftDRMServer folder. You'll see at least one folder name, in the form S-1-5-21-xxxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxx. The folder name is actually a SID that represents the accounts used by SharePoint to contact RMS.
As you start to use IRM in SharePoint, additional folders will be created, one for each of the identities that Web application pools run under. Within the folder that represents the account used by SharePoint, you'll see two files: the first named CERT-Machine.drm and the second named GIC-identity-{GUID}.drm. In the folders that represent the identities used by Web application pools, you'll find both the CERT-Machine.drm file and the file beginning with GIC. You'll also find a file with the name CLC-identity-{GUID}.drm.
To configure document libraries to use IRM, the fourth and last step, you need to open in a browser the SharePoint-extended Web sites that will contain IRM-enabled libraries. Click the Site Actions drop-down menu, and select Site Settings. Under Site Administration, click Site libraries and lists. Select Create new content to create a document library if you don't yet have a document library. Select Customize “” for the library you want to apply IRM to. Then set and test the permissions that users have to the documents library.
Once permissions have been set up, in the browser, click Information Rights Management under Permissions and Management. Select the Restrict permission to documents in this library on download check box and enter Permission policy title and Permission policy description information (as Figure 3 shows). Use the remaining check boxes in Figure 3 to specify whether users are allowed to print documents and/or access them programmatically (e.g., by using Visual Basic for Applications—VBA).
The check boxes also let you configure whether users need to periodically connect to the RMS infrastructure and renew their Use License to access or consume the content. You can also set a date after which there are no restrictions on documents downloaded from the library. Another important check box is Do not allow users to upload documents that do not support IRM. Only the Office applications Word, Excel, PowerPoint, and Outlook—and InfoPath in Office 2007—natively support IRM.
Accessing Documents in an IRM-Protected Document Library
Users with permissions to document libraries can access documents three ways: They can use a browser to navigate to the library and select the document from there, they can open the document from an application, or they can enter the file's URL in a browser. Users don't need to have used RMS previously to author or consume rights-protected content. However, users will need to have an SMTP email address configured in their user or inetOrgPerson object, RMS Client SP2 installed on their workstations, and IRM-enabled applications, such as those in Office 2003 or Office 2007.
When users open a document from a document library that's rights-protected with IRM, they see a notice similar to the one in Figure 4. When users open a rights-protected document in the native application, they're also reminded that the document is rights-protected. In Office 2007 applications, the document library IRM template name and description appears in a bar at the top of the document window (as Figure 5 shows). A user can click Change Permission to see exactly what permissions they've been granted and request additional permissions (as Figure 6 shows).
When a user creates a new document, or uploads a document, to a rights-protected library, it's stored in the library without rights protection. Rights are added to the document only when the document is downloaded.
Troubleshooting MOSS and IRM Problems
Although configuring MOSS and IRM is relatively simple, you might think you have it set up correctly and then encounter some difficulties. The most common problem is a user who can't view a document in an IRM-protected document library. Most often when this happens, the user doesn't have permission to the document library. Check that the user has rights to the document library and can view the library contents in a browser.
If the user can see the documents but can't open or download them, there might be a couple reasons why. One is that the user doesn't have an email address recorded in the mail attribute of his or her AD user or inetOrgPerson object. Populate the mail attribute for all users who have permissions to the document library.
If the user has permissions to the document library and a populated mail attribute, make sure RMS Client is installed on his or her machine. If an earlier version is installed, I recommend that you upgrade it to RMS Client SP2.
If RMS Client SP2 is installed and the user can use IRM in Office applications such as Word to create and consume rights-protected documents, the problem might be with MOSS. If you configured MOSS with the Use the default RMS Server specified in Active Directory option, try manually specifying the URL of your RMS server and, on each of your MOSS Web farm servers, use the HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSDRMServiceLocationEnterprisePublishing registry subkey with the http(s)://RMS server URL/_wmcs/Licensing value and REG_STRING type. You'll need to reboot each server after you make the change.
If you still have difficulty getting IRM to work as expected in MOSS, you can enable event and trace logging in MOSS to get more detail about any problems. You can configure the amount of logging by clicking the Operations tab in the SharePoint 3.0 Central Administration console and clicking Diagnostic logging under Logging and Reporting. Select IRM from the Select a category drop-down list in the Event Throttling section, then select the least critical events you want recorded to the event log and trace log. Every event at and above the event criticality selected will be recorded. You can also set the location of the trace log in this section. By reviewing the event and trace logs, you should be able to determine where the problem lies.
IRM and MOSS integration allows companies to store their sensitive documents in central repositories; apply document workflow, storage, and retention policies; restrict document access to select employees; and add an extra layer of protection that ensures that once documents are downloaded from or checked out of the repository they can't be distributed to unauthorized employees, competitors, or corporate spies. You can find out more about MOSS at http://www.microsoft.com/sharepoint.
Read more about:
MicrosoftAbout the Author
You May Also Like