Enabling Information Protection in Microsoft Office 2003 with Rights Management Services and Information Rights Management

On This Page

	Key Concepts
	Executive Summary
	Overview of IRM and RMS
	IRM and RMS Deployment Requirements
	Deploying IRM and RMS
	Managing the IRM/RMS Environment
	Conclusion
	Find Additional Information

Key Concepts

Microsoft® Windows® Rights Management Services (RMS) for Windows Server™ 2003 – Microsoft Windows Rights Management Services (RMS) for Windows Server 2003 is information protection technology that works with RMS-enabled applications such as the Microsoft Office 2003 Editions to help safeguard digital information from unauthorized use – both online and offline, inside and outside of the firewall. Combining Windows Server 2003 features, developer tools, and industry security technologies – including encryption, eXtensible rights Markup Language (XrML)-based certificates, and authentication – RMS augments an organization's security strategy by providing protection of information through persistent usage policies which remain with the information, no matter where it goes.

Information Rights Management (IRM) – Information Rights Management (IRM) extends RMS into the Microsoft Office 2003 Editions programs and into Microsoft Internet Explorer. Information workers can now stipulate who can open a document and specify how recipients may use that document; for example, they may grant rights to open, modify, print, forward or take other actions. Organizations can create custom usage policy templates such as “Confidential - Read Only” that can be applied directly to financial reports, product specifications, customer data, e-mail messages, and other sensitive documents.

Top of page

Executive Summary

One of the touchstones of Trustworthy Computing is the availability of technology that can reliably protect content and keep digital information private. Information Rights Management (IRM) in the Microsoft Office System gives organizations and information workers another mechanism to help safeguard sensitive information.

This paper covers RMS operation within an organization's infrastructure and how it supports IRM and extends information protection capabilities into the Microsoft Office 2003 Editions. The main purpose of this paper is to provide a single resource for understanding the decisions and tasks associated with enabling information protection through IRM and RMS. Though the paper is by no means comprehensive on every topic, enough detail is provided here to deploy and manage a typical configuration, and the paper points to relevant topics in the RMS Help file and the RMS web site for more details. Those resources provide much greater detail on subjects such as the business benefits of RMS and IRM, the architecture, the topology possibilities, and so on, and they should be a part of any deployment plans.

Top of page

Overview of IRM and RMS

RMS is an information protection feature of Windows that works with RMS-enabled applications to help safeguard confidential and sensitive information from unauthorized use—no matter where it goes. Responding to customer demand for improved content protection, Microsoft designed RMS to combine Windows Server 2003 features, developer tools, and industry security technologies—including encryption, XrML-based certificates, and authentication—to help organizations create reliable information protection solutions. For more information on the value and benefits of IRM and RMS, see the main RMS site at http://www.microsoft.com/windowsserver2003/technologies/rightsmgmt/default.mspx.

IRM extends the information protection capabilities of RMS to the desktop. IRM is a persistent file-level protection technology that allows information workers to specify who can access and use documents or e-mails, and helps protect that digital intellectual property from unauthorized printing, forwarding, or copying. Note that IRM is not the same as the new Protect Document functionality in Microsoft Office Word 2003, which allows information workers to set formatting restrictions and to selectively grant editing permissions for specified sections of a document to users and groups.

Because IRM protections travel with a file, once a document or e-mail is protected with this technology, the usage rights are enforced no matter where the information goes—even if the file is sent outside the firewall. For an overview on how IRM and RMS work together, see the paper titled Information Rights Management in Microsoft Office 2003 at http://www.microsoft.com/technet/prodtechnol/office/office2003/operate/of03irm.mspx.

Once an information worker has been granted usage rights to a file, the application user interface (UI) and object model enforce the restrictions or rights granted to that user (do not copy, for instance). However, IRM is not a security feature - like other policy tools, these restrictions cannot prevent every form of misuse.

Typical Roles for IRM and RMS

IRM can help protect information in various scenarios. There are two basic user experiences using IRM in Office 2003 Editions:

E-Mail - E-mail is one of the primary methods of communication within and across organizations. Information workers use e-mail to communicate with team members, other groups, customers, and vendors. Field sales teams utilize e-mail to communicate and collaborate with the corporate office on new pricing plans and product updates. Executive management uses e-mail for communication within an organization. E-mail can be viewed offline on airplanes or in hotels, making it easy for a mobile worker to read and compose documents even while out of the office.

It is this ease of communication, however, that increases the risk of information leaks. E-mails that contain confidential information (e.g. a new product plan or a pending merger) can be easily forwarded, even accidentally, to a competitor, vendor, or the media. The negative impact of such information leaks can include loss of competitive advantage, loss of revenue, and loss of customer confidence. Rights-protected e-mail helps protect against leaks, accidental forwards and, at the least, making it difficult for an offender to claim ignorance. The figure below shows an email protected with the Do Not Forward template. The recipients of this e-email cannot forward the message and cannot copy or print its contents.

Figure 1: E-mail protected with Do Not Forward IRM template

Documents - The vast majority of information created and consumed by information workers is contained in documents from everyday desktop applications. Management, sales, finance, human resources, product teams and research teams use Office 2003 Editions programs to create financial forecasts, sales plans, revenue projections, employee evaluations, product lifecycle plans and research analysis—information that could compromise an organization if it were to get into the wrong hands. IRM gives information workers an easy tool within the Office 2003 Editions program to establish rights protection to sensitive information, thereby helping to control who may open or modify the document within a specific timeframe.

The entry point to IRM is a button on the main toolbar, as shown in the figure below:

Figure 2: The Permission button in Office 2003 Editions programs

Clicking the button, once RMS has been deployed in the enterprise, brings up the Permission dialog shown below:

Figure 3: Permission dialog with users with assigned rights

The main permission box gives a quick and easy way to grant Read and Change permissions to different users. The users must be specified by email address stored in Windows Server Active Directory, and this may include group distribution lists. It can also include external addresses, if the organization has enabled a trust policy that includes the external addresses. Clicking More Options brings up the dialog shown in figure 4.

Figure 4: More options

The first additional option is the set expiration for the document. After the date specified, those who had permissions prior to expiration will no longer be able to open the document. In addition to expiry, the More Options dialog allows authors to selectively grant others the rights to print content, to copy content, and to access content programmatically. By default, the Additional settings field is filled in with the author's email address to allow recipients to request additional rights to the document (the Request additional permissions link is shown in figure 5). Authors can also choose to allow or disallow read permissions for those with earlier versions of Office. Finally, authors can require a connection each time the file is opened. By default, a recipient only needs to connect to the RMS server once (on a given machine) to verify permission.

When Victoria, who was given Read permissions, receives this document and opens it, Word 2003 will connect to her corporate RMS server and check whether she has rights. It opens the document (it would not open if she did not have the rights). She can not copy, print, or modify the document. She can view her permissions by clicking in the task pane:

Figure 5: Viewing permissions on a Rights-protected file

Under IRM, usage rights will always remain with the information, even after it leaves the network. That means the usage rights will apply to the protected information, even if the information worker opens the e-mail or document offline or has saved it to a disk.

Technical Overview of IRM and RMS

On the server side, Windows RMS handles the core licensing, machine activation, enrollment and administrative functions. RMS relies on Windows Server Active Directory® directory service (Windows Server 2000 or later) and uses a SQL database such as Microsoft SQL Server™ to store configuration data.

On the desktop side, creating or viewing rights-protected content requires an RMS-enabled program. Microsoft Office 2003 Editions include the first RMS-enabled programs available from Microsoft. For creating or viewing rights-protected Microsoft Office documents, spreadsheets, presentations, and e-mail messages—Microsoft Office Professional Edition 2003 is required. Other Office 2003 Editions allow designated recipients to work with rights-protected documents (but not create content) if they have been given those rights by the author. Rights Management Add-on (RMA) for Internet Explorer allows designated information workers to view rights-protected information if they do not have a Microsoft Office 2003 Edition.

IRM and RMS Architecture

RMS is a managed Web Service that leverages ASP.NET implementation, HTTP SOAP request/response protocol, and XrML to enable organizations to create and deploy customized information protection solutions. With high scalability, flexible topologies, straightforward administration, and ease of use, RMS was developed to meet the needs of any organization interested in information protection.

The key to Windows RMS technology is persistent usage policies (also known as usage rights and conditions). Information authors can establish persistent usage policies at the file level. After the author or owner applies those policies to a file, they remain with that file even when the file travels outside the corporate network.

An RMS system achieves persistent policy enforcement by establishing the following essential elements:

The Basics: How RMS Works

Windows RMS technology, which includes both server and client components, provides the following capabilities:

RMS Component Pieces

RMS technology includes the following client and server software along with SDKs:

RMS Server Software

At the core of Windows RMS is the server component that handles certification of trusted entities, licensing of rights-protected information, enrollment and sub-enrollment of servers and users, and administration functions. The server software facilitates the setup steps that enable trusted entities to use rights-protected information. The following RMS features are provided by the server software:

•	Setup for trusted entities. Windows RMS provides the tools to establish and configure the servers, client computers, and user accounts for trusted entities in an RMS system. This setup process includes the following: • Server enrollment. Server enrollment is part of the provisioning process. During server enrollment, a public key from an organization's root RMS server is sent to the RMS Server Enrollment Service hosted by Microsoft. The enrollment service creates and returns an XrML licensor certificate for that organization's public key. The RMS Server Enrollment Service does not issue the public/private key pair to an organization's root server; it merely signs the public key. The RMS Server Enrollment Service cannot be used to unlock an organization's content. There is no attestation of identity during this process. • Sub-server enrollment. After an organization configures the root installation server for its RMS system, it can then sub-enroll and configure additional servers that will be part of the system. The server sub-enrollment process establishes the XrML-based certificates that enable the additional servers to issue licenses that are trusted by the RMS system. • Client-computer activation. An organization must activate all client computers that will be used to create or access rights-protected information. During this one-time process, the client computer is issued a unique RMS lockbox. The RMS lockbox is the client-side security enforcer. It is unique for the machine and cannot be run on another machine. • User certification. Organizations must identify the information workers who are trusted entities within their RMS system. To do so, Windows RMS issues rights management account XrML-based certificates (RACs) that associate user accounts with specific computers. Figure 6: The one-time process of getting an RAC These certificates enable workers to access and use protected files and information. Each unique certificate contains a public key used to license information intended for that information worker's consumption. • Client enrollment. Client computers may sometimes be used to publish rights-protected information when they are not connected to the corporate network. In that case, a local enrollment process is required. Client computers enroll with the root installation server or a Windows RMS licensing server and receive rights management client licensor certificates. This enables certified information workers to publish rights-protected information from those computers without being connected to the corporate network.
•	Publishing licenses that define usage rights and conditions. Trusted entities can use simple tools in RMS-enabled applications to assign specific usage rights and conditions to their information, consistent with their organization's business policies. These usage rights and conditions are defined within publishing licenses specifying the authorized workers who may view the information, and how that information may be used and shared. RMS uses an XML vocabulary to express usage rights and conditions, the eXtensible rights Markup Language (XrML), version 1.2.1.
•	Use licenses that enforce usage rights and conditions. Each trusted entity that is a recipient of rights-protected information transparently requests and receives a use license from the RMS server by attempting to open the information. A use license is granted to authorized recipients, specifying the usage rights and conditions for that individual. An RMS-enabled application uses Windows RMS technology features to read, interpret, and enforce the usage rights and conditions defined in the use license.
•	Encryption and keys. Protected information is always encrypted. An RMS-enabled application uses a symmetric key to encrypt the information. All RMS servers, client computers, and user accounts have a public/private pair of 1024-bit RSA keys. Windows RMS uses these public/private keys to encrypt the symmetric key in publishing and use licenses, and to sign rights management XrML-based certificates and licenses—helping ensure access to only properly trusted entities.
•	Rights policy templates. Administrators can create and distribute official rights policy templates defining usage rights and conditions for a pre-defined set of workers. See the “Usage Rights Policy Templates” section for more information. These templates provide a manageable way for organizations to establish document classification hierarchies for their information. For example, an organization might create rights policy templates for their employees that assign separate usage rights and conditions for company confidential, classified, and private data. RMS-enabled applications can use these templates, providing a simple, consistent way for workers to apply predefined policies to information.
•	Revocation lists. Administrators can create and distribute revocation lists identifying the compromised trusted entities that are invalidated and removed from the RMS system. (Trusted entities are individuals, groups of information workers, computers, or programs that are trusted participants in an RMS system.) An organization's revocation list can invalidate the certificates for specific computers or user accounts. For example, when an employee is terminated, the trusted entities involved can be added to the revocation list and can no longer be used for any RMS-related operations.
•	Exclusion policies. Administrators can implement server-side exclusion policies to deny license requests based on the requestor's user ID (Windows logon credential or .NET Passport ID), rights management account certificates, or rights management lockbox versions. Exclusion policies deny new license requests made by compromised trusted entities, but unlike revocation, exclusion policies do not invalidate the trusted entities. Administrators can also exclude potentially harmful or compromised applications so they cannot decrypt rights-protected content.
•	Logging. Administrators can track and audit the use of rights-protected information within an organization. RMS installs support for logging so that organizations have a record of RMS related activities, including issued or denied publishing and use licenses.

RMS Software Development Kit (SDK)

Windows RMS technology includes the Windows RMS SDK, a set of tools, documentation, and sample code that enables organizations to customize Windows RMS. The SDK includes simple object access protocol (SOAP) interfaces that allow developers to create components for various purposes, including the following:

RMS Client SDK

Windows RMS technology includes the RMS client SDK, a set of tools, documentation, and sample code that enables software developers to create RMS-enabled applications. Using the SDK and the accompanying client application programming interfaces (APIs), developers can build trusted client applications able to license, publish, and consume rights-protected information.

The RMS client SDK consists of the following components:

RMS Client Software

Each client computer in an RMS system must have the Windows Rights Management client software installed. This client component, required to use RMS-enabled applications, is a group of Windows Rights Management APIs that can be pre-installed or downloaded from the Windows Update Web site. The Rights Management client is also used during the computer activation process.

IRM Component Pieces

Office 2003 Editions provide the first RMS-enabled applications. As such, Office 2003 Editions programs simply extend the capabilities of RMS.

Using RMS/IRM: What Happens

To protect data with Windows RMS, information workers simply follow the same logical and fundamentally interlinked workflow they already use for their information.

The following diagram summarizes how Windows RMS works when information workers publish and consume rights-protected information.

Figure 7: Publishing and consuming protected data

The publishing and consuming process includes the following steps, as numbered in the figure above:

1.	Before authors can rights-protect a document, they must first be enrolled in the RMS system, receiving a lockbox, an RAC, and a client publishing certificate on their machine.
2.	Using an RMS-enabled application such as Office Professional Edition 2003, an author creates a file and defines a set of usage rights and conditions for that file.
3.	The application then encrypts the file with a symmetric key which is then encrypted using the public key of the author's Windows RMS server. The key is then inserted into the publishing license and the publishing license is bound to the file. Only the author's Windows RMS server can issue use licenses to decrypt this file. The figure below shows what is contained in a protected Office 2003 Editions program file once rights have been assigned to it. Figure 8: The contents of a protected file
4.	The author distributes the file.
5.	A recipient receives a protected file through a regular distribution channel and opens it using an RMS-enabled application or browser. If the recipient does not have an account certificate on the current computer or device, this is the point at which one will be issued (presuming the recipient has access to the root RMS server and has an enterprise account).
6.	The application sends a request for a use license to the server that issued the publishing license for the protected data. The request includes the recipient's account certificate (which contains the recipient's public key) and the publishing license (which contains the symmetric key that encrypted the file). A publishing license issued by a client licensor certificate includes the URL of the server that issued the certificate. In this case, the request for a use license goes to the Windows RMS server that issued the client licensor certificate, and not to the actual computer that issued the publishing license.
7.	The Windows RMS licensing server validates that the recipient is authorized, checks that the recipient is a named user, and creates a use license. During this process, the server decrypts the symmetric key using the private key of the server, re-encrypts it using the public key of the recipient, and adds it to the use license. The server also adds any relevant conditions to the use license, such as the expiration or an application or operating system exclusion. By doing this step, only the intended recipient can decrypt the symmetric key and thus decrypt the protected file.
8.	When the validation is complete, the licensing server returns the use license to the recipient's client computer.
9.	After receiving the use license, the application examines both the license and the recipient's account certificate to determine whether any certificate in either chain of trust requires a revocation list. If so, the application checks for a local copy of the revocation list that has not expired. If necessary, it retrieves a current copy of the revocation list. The application then applies any revocation conditions that are relevant in the current context. If no revocation condition blocks access to the file, the application renders the data, and the user may exercise the rights they have been granted.

Top of page

IRM and RMS Deployment Requirements

RMS is designed to make the most of existing infrastructure investments, by using Active Directory for service discovery and Windows NT® LAN Manager (NTLM) authentication. With the flexibility of Windows authentication, RMS can utilize smart card and biometric devices as well as other alternate authentication methods supported by Windows. The following is needed to run RMS:

At the server level:

At the desktop level:

Table 1 shows the minimum hardware configurations needed to deploy RMS:

Table 1 Hardware requirements

Table 2 shows the software platform needed to operate RMS.

Table 2 Software requirements

Table 3 shows additional elements that must exist in the infrastructure to run RMS.

Table 3 Infrastructure requirements

Top of page

Deploying IRM and RMS

Because IRM functionality is an extension of RMS, IRM deployment is contingent upon RMS deployment. Once RMS is deployed, IRM deployment is a simple matter of installing the Windows Rights Management client at the desktop. The client machine and each information worker then receive a certificate allowing IRM usage.

The process of deploying both RMS and IRM consists of the following basic steps:

The final section in this discussion on deployment concerns how to enable client machines to do offline publishing.

The Standard RMS System Topology

The standard RMS system topology consists of one or more physical servers that make up the Windows RMS root installation or cluster. The root installation provides both certification and licensing services. For larger deployments, there can be multiple physical servers configured as a cluster behind a single, shared URL (see example below).

Figure 9: Example of RMS topology

All requests for certificates and licenses are passed to the root cluster through the shared URL defined for that collection of servers. There are numerous implementations of virtual addressing, such as round-robin DNS, Windows Load Balancing Service, hardware solutions, and so on. Virtual addressing provides load balancing across the servers and removes the dependency on any one server for licensing and publishing for fault tolerance.

Windows RMS uses a database, such as Microsoft SQL Server 2000 with Service Pack 3 (SP3) or the Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) with SP3 for its configuration and policy information. MSDE is recommended only for a single-server configuration. The configuration database stores, shares, and retrieves configuration and other data. There is one configuration database for each Windows RMS server cluster. The configuration database and logging database can be located on one of the physical servers in the cluster or on a separate server providing a remote SQL Server instance.

Functionally, the core process of deploying RMS in this sample topography is the same as it is for a single server implementation. For the sake of clarity, we will discuss deploying to a single server. For more information on choosing a topology, see the Topology designs topic in the Help file.

Installing the RMS Server Software

There are two very simple steps to installing the RMS server software, once the hardware, software, and infrastructure requirements have been met.

Enrolling Servers in an RMS System

The Windows RMS installation process creates a Windows RMS Global Administration site that enables administrators to configure the servers and services in an RMS system. This site is accessible in the Windows RMS program group (Start, All Programs).

It is recommended that only one web site exist on the server you will provision, or enroll, with RMS. The Global Administration page will show all sites on the server. Presuming only the RMS default site exists, clicking Provision RMS on this site launches the Provision page, as shown below.

Figure 10: Part of the Provision page

After filling in the information and clicking Submit, RMS is provisioned. During this process, RMS determines whether it is the first RMS server in the system in order to set up the Windows RMS root cluster. The server sends a request for an RMS Server Licensor Certificate to the RMS Enrollment Service, a Web service hosted by Microsoft. This request is made using Secure Socket Layer (SSL) security. The RMS Enrollment Service uses the information solely to issue the Windows RMS Licensor Certificate to the organization making the request.

Server enrollment using the RMS Enrollment Service is required for at least one server within every RMS system. Subsequent servers added to the Windows RMS root cluster use the same RMS Licensor Certificate. When you add a new server to an existing root installation or licensing-only server cluster, the new server is not explicitly enrolled because it assumes the existing configuration of the cluster.

For step-by-step instructions on how to enroll a server, see the To provision the first root certification server topic in the RMS Help file.

Register the Server URL

Clients need to know the location of the RMS server. The primary way to accomplish this is to register the server URL as a connection point in Active Directory. To do this, the administrator first opens the Global Administration page. After the server is provisioned (enrolled), this page will display the link Administer RMS on this site. Clicking this opens the main administration page shown below.

Figure 11: The main RMS administration page

From the main administration page, the administrator simply clicks the RMS Service connection point link from the Global Administration page and clicks Register URL. This creates an entry in Active Directory that contains the URL of the RMS server. No other Active Directory changes are made (such as schema changes). By default, clients will use the value published in the Active Directory. There may be times (such as when there are multiple sites or domains) when an organization will want clients to use a specific server as the primary RMS server. Some clients may need to have a registry key configured to override the normal process of connecting to the server URL registered in Active Directory. The registry key is:

Value name: CorpCertificationServer

Value type: REG_SZ

Value data: <URL>

Setting up Client Computers

Every client computer participating in the RMS system must be configured as a trusted entity within the RMS system. Client computer setup consists of verifying the presence of the Windows Rights Management client component and activating the client computer(s). After a client computer is set up, the infrastructure is in place to permit RMS-enabled applications to publish and consume rights-protected information.

The Rights Management client software is available at http://www.microsoft.com/downloads/search.aspx?displaylang=en (search for “Rights Management Client”).

Organizations can use standard software deployment tools, such as Microsoft SMS, to ensure their client computers have the client component, or can rely on the installation of an RMS-enabled application to initiate the request to the Windows Update Web site for the component.

Certifying RMS Users

The certification process creates a rights management account certificate which associates a user account with a specific computer and enables the information worker to access and use rights-protected information from that computer. The first time an information worker publishes rights-protected information or attempts to access such information on a client computer, the RMS-enabled application sends a request for an account certificate to the Windows RMS root installation.

The Windows RMS root installation validates the person's identity using Windows authentication and creates an account certificate, including a public/private key pair, based on the information worker's validated credentials. It encrypts the worker's private key with the public key of the client computer's certificate and includes the encrypted key in the user's account certificate. It then issues the account certificate to the requesting application. The application stores the account certificate on the computer or device so that it is available for subsequent publishing or use license requests.

Since the certificate of the client computer is required to request the account certificate, user certification follows the client computer activation process. Information workers must acquire an account certificate for each computer they use. If a worker uses more than one computer, each computer is issued a unique account certificate, but they all contain the same private/public key pair unique for that individual.

When an application requests a use license, it includes the account certificate in the request. The Windows RMS licensing server uses the public key of the account certificate to encrypt the symmetric key in the publishing license, which was initially encrypted with the public key of the Windows RMS server. This process assures that only the trusted entity can access and use the use license.

Enrolling Client Computers for Offline Publishing

Client computers can enroll with the root installation or a licensing server to receive a rights management client licensor certificate. This certificate enables information workers to publish protected information when their computer is not connected to the corporate network. In this case, the client computer, rather than the licensing server, signs and issues the publishing licenses containing the usage rights and conditions for rights-protected information published from that computer.

Local enrollment includes the following steps:

Top of page

Managing the IRM/RMS Environment

The discussion of deployment provided in earlier sections focused on what is needed to get up and running with the core services of RMS and IRM. Beyond deployment, however, is effective usage and management. As with any infrastructure component, there are multiple ways in which customers will use RMS and IRM, and there are a number of capabilities and settings that are relevant to different usage scenarios. For example, some scenarios require the use of Trusts or Exclusion Policies, while others do not.

As a quick overview, the key management activities available from the RMS Administration page (shown in figure 11 above) are:

Administrators can perform other tasks, including monitoring events and managing Active Directory, Internet Information Services (IIS), and SQL Server, by using the Microsoft Management Console (MMC).

The next sections describe these pieces in more detail and offers guidance on when they need to be used, depending on the needs of the organization. First, however, we'll describe some common scenarios to get a better sense of how those needs translate into configuration requirements.

IRM/RMS Usage Scenarios

The scenarios presented here are meant as frameworks for understanding when configuration above and beyond the base deployment is needed or recommended. The scenarios are presented in a cumulative fashion.

Core Usage Scenario

Using IRM in Microsoft Office Outlook® 2003 as an example, an information worker clicks the red “Permission” button in the toolbar and selects the option to add rights to his e-mail message. He specifies that employees within the corporate domain can open the attachment as well as the e-mail. In addition, he adds an expiration date to the message. As employees open the e-mail, Outlook transparently applies their usage rights and secures a license for the attachment. After the expiration date, employees will no longer be able to open the message or the attachment. The same basic pattern of adding rights applies to other Office 2003 Editions programs.

The key elements in this scenario are that:

For this scenario, the basic deployment of RMS and the client components are sufficient. For this scenario, and for all scenarios, administrators may elect to use rights policy templates, revocation lists, or exclusion policies, but usage scenarios do not explicitly require the use of these features.

Note: The scenarios described here can also be achieved in a Terminal Services environment. The key difference is technical rather than functional: information workers will experience IRM in the same way, even though their usage certificates reside on the same physical server(s).

Cross-Domain Scenario

With the same basic usage pattern as above – an information worker specifies rights for a document or email and sends it out – we will add the scenario that some recipients do not have accounts within the domain.

For this scenario, the administrator will need to set up a trust policy, as described in “Trust Policies” below.

Previous Office Versions Scenario

Continuing with the cross-domain scenario, if information workers in the trusted partner domain are using previous versions of Office, they may still consume rights-protected content with the Rights Management Add-On for Internet Explorer (this happens by prompt). Administrators do not need to configure anything.

In terms of what the administrator needs to do, these are the basic scenarios. The following sections describe each of the management features in greater detail, and include guidance on how to use them.

Rights Policy Templates

From the Administration site on the Windows RMS server, administrators can create official rights policy templates, delete or modify existing templates, and specify the location of rights policy templates in the RMS system. Templates can include various conditions, such as specific recipients or Active Directory groups, how long a use license for the information remains valid, how long after publication the information can be accessed, and even custom values that are meaningful to a particular RMS-enabled application.

A template can also specify a revocation list (described in the “Revocation Lists” section below). The template specifies the URL to the list file and the number of days the list is valid. When a recipient requests a use license based on the template, the system will check the revocation list before the worker can access the protected data.

Rights policy templates are stored both in the configuration database and on a network share. When an author requests a publishing license, the RMS-enabled application copies the rights policy template from the network share. When a recipient requests a use license, the Windows RMS licensing server applies the rights policy template from the database; this process assures that the terms of a use license always reflect the most current version of the template.

Creating Templates

To add a rights policy template:

1.	In the Administration links area of the main administration page, click Rights policy templates. Figure 12: The main rights policy templates page
2.	Click Add a rights policy template.
3.	On the Rights policy template settings page, you can specify all the settings for the template, including its name, which users or groups (via distribution lists) get which permissions, expiration policies, and so on. Figure 13: Creating a rights policy template
4.	Click Submit.

For more details on creating a rights policy template, see the RMS Help file.

Making Templates Available through Group Policy

When the permission policies are ready, they should be posted to a server share where all users can have access to them or they should be copied to a local folder on the user's computer. The IRM policy settings available in the Office11.adm template can then be used to point to the location where these permission policies are stored (either locally or on an available server share). Once the permission policies are available and the necessary Group Policy settings are implemented and propagated to users, the IRM Permissions menu option will display the available custom permission policies in a submenu.

For more information about how to use Group Policy with Office 2003 Editions programs, see the How Policies Work topic in the Office Resource Kit.

It is possible to enable and distribute the configured policies provided in the Manage Restricted Permissions section of the Office11.adm policy template. When the IRM policy Specify Permission Policy Path is implemented and propagated through Microsoft Active Directory directory service, IRM will automatically locate any available templates stored in the location specified. The RMS-enabled Office 2003 Editions programs will then display the custom permission policies.

IRM Registry Entries

These are the core registry entries associated with IRM. Most of these have parallel policy entries.

The following two registry entries are under HKLM\Software\Microsoft\Office\11.0\Common\DRM:

Value name: CorpLicenseServer

Value type: REG_SZ

Value data: <URL>

This setting allows the administrator to override the location of the Windows Rights Management server specified in Active Directory.

Value name: CorpCertificationServer

Value type: REG_SZ

Value data: <URL>

This setting allows the administrator to override the location of the Windows Rights Management server specified in Active Directory for certification.

The remaining registry entries are under HKCU\Software\Microsoft\Office\11.0\Common\DRM:

Value name: Disable

Value type: DWORD

Value data: [ 0 | 1 ]

If this key is set to 1, the Rights Management–related options within the user interface of all Office 2003 Editions programs are disabled. This is identical to the Disable Information Rights Management User Interface policy.

Value name: DisablePassportCertification

Value type: DWORD

Value data: [ 0 | 1 ]

If this key is set to 1, users cannot open content created by a Passport–authenticated account. This is identical to the Disable Microsoft Passport service for content with restricted permissions policy.

Value name:IncludeHTML

Value type: DWORD

Value data: [ 0 | 1 ]

If this key is set to 1, users without Office 2003 Editions programs can view the content in the Rights Management Add-in for Internet Explorer. This is identical to the Allow users with earlier versions of Office to read with browsers policy.

Value name: RequestPermissionURL

Value type: REG_SZ

Value data: <URL or e-mail address>

This setting allows the administrator to specify a location where a user can obtain more information about getting access to IRM content. It can be either a URL or e-mail address. This is identical to the Additional permissions request URL policy.

Value name: RequireConnection

Value type: DWORD

Value data: [ 0 | 1 ]

If this key is set to 1, any users attempting to open an Office document having IRM permissions enabled will be forced to connect to the Internet or local area network to have their license confirmed by either Passport or RMS. This is identical to the Always require users to connect to verify permission policy.

Value name: AutoExpandDLsEnable

Value type: DWORD

Value data: [ 0 | 1 ]

If this key is set to 1, any user who attempts to apply permissions to a file will encounter different behavior when they select a group name in the Permissions dialog box. When a group is selected, the dialog box will automatically expand to display all the members of the group. This is identical to the Always expand groups in Office when restricting permission for documents policy.

Value name: AdminTemplatePath

Value type: REG_SZ

Value data: <UNC or aliased drive>

If this key is present, Office 2003 Editions programs using IRM will scan the path provided in this registry entry to see if any permission policy templates exist. If they are there, the title for each is displayed in the Permission dialog box (File menu). This is identical to the Specify Permission Policy Path policy.

Revocation Lists

Administrators can create revocation lists to specify the information workers, applications, or other trusted entities that should no longer have access to rights-protected information. One or more certificates involved in the process of issuing publishing or use licenses can specify a revocation list condition. RMS-enabled client applications check the revocation list whenever that condition is specified, and if any of the requesting trusted entities are on the revocation list, the license request is denied.

Any certificate can be revoked. By default, only the entity that issued the certificate can revoke it, so only a revocation list signed by that entity can revoke the certificate. Optionally, a certificate can also specify:

Rights policy templates can also specify a revocation list condition. For example, an organization might want to check the revocation list for a template applied to company-sensitive information, and skip the revocation list check for a template applied to less sensitive data. To further protect the information, the template can specify a valid time period for the revocation list. For example, the template might specify that the revocation list must have been created within the last 10 days or it will not be accepted.

A revocation list is created as a plain text file in XML format conforming to the XrML vocabulary and signed by a private key using a utility provided by Windows RMS. The list can then revoke any trusted entities named by the owner of the public key that corresponds to the private signing key. The file is placed in a location available to all workers who require it, such as a URL that is accessible from both the corporate network and the Internet. This will assure that both internal and external workers can access the file. If a revocation list condition is present and a valid revocation list cannot be located, access to the rights-protected information is denied.

An organization might specify trusted entities in a revocation list for the following conditions:

Creating and Managing Revocation Lists

Implementing revocation requires that you deploy a revocation list, which is an XML document that uses the XrML language, and lists the trusted entities that should no longer have access to rights-protected content. You must create revocation lists that are time-stamped and signed appropriately by using the Revocation List Signing tool that is provided with Windows RMS.

Since there are a number of options when creating Revocation Lists, the best plan is to refer to the Creating revocation lists topic in the RMS Help file.

Exclusion Policies

From the Administrator Console in Windows RMS, administrators can set exclusion policies separately on each server or server cluster in the RMS system to prevent specific trusted entities from acquiring new licenses from that server. Exclusion policies stop compromised trusted entities from acquiring use licenses from RMS servers. However, unlike revocation, exclusion does not invalidate the trusted entities. Any existing licenses associated with excluded trusted entities are still valid, but new licensing requests are denied.

Administrators can exclude the following trusted entities:

Creating Exclusion Policies

The Exclusion policies page under the Global Administration page on the RMS server allows administrators to set policies for any of the four trusted entities described in the previous section.

Figure 14: The exclusion policies page

Logging

Windows RMS installs support for logging during the initial RMS system setup. This logging service is enabled and started automatically. An RMS logging database is created in the SQL Server instance that is also used for the configuration database, and a private message queue in MSMQ is created to transmit the messages from the logging service to the database.

Administrators can enable or disable the logging service at any time. When enabled, the logging service will send all data about RMS requests to the logging database. Administrators can write SQL scripts to reduce the information so only the specific information required by the organization is stored. RMS logs both successful and failed use license requests. This log enables an organization to record both the information workers who have successfully accessed rights-protected information and those who attempted unauthorized access of rights-protected information.

Trust Policies

By default, Windows RMS does not service requests from users whose rights management account certificates (RACs) were issued by a different Windows RMS installation. However, you can add user domains to the list of trusted user domains, which allows Windows RMS to process such requests.

For each trusted domain, you can also add and remove specific users or groups of users. In addition, you can remove a trusted user domain, however, you cannot remove the root certification cluster for this Active Directory forest from the trusted user domains. Every Windows RMS server in a deployment, including the root certification server, trusts the root certification cluster in its own forest.

Configuring and Managing Trust Policies

To add a trusted user domain:

1.	From the main administration page, click Trust policies. Figure 15: The trust policies page
2.	In the Trusted user domains area, click Browse, locate and double-click the server licensor certificate of the user domain that you want to import to establish the trust relationship, and then click Add.
3.	The name of the domain appears in the Trusted user domains list.
4.	To specify which e-mail domains within the trusted user domain are trusted, click Trusted domains next to the certificate name in the list to open the Trusted e-mail domains window.
5.	Choose one of the following trust options: Select the Trust all e-mail domains option to trust all of the user accounts that are members of that domain. –or- Select the Trust only specified e-mail domains option and then type the domain name to trust, such as example.com, and then click Add. This adds the domain to the Trusted e-mail domains list. To remove a name from the list, select the name, and then click Remove. Listing a domain includes all of its sub-domains.

For more step-by-step information on Trust Policies, see the RMS Help file which is installed with the RMS server software.

Top of page

Conclusion

The actual deployment of RMS, including installation and provisioning, is surprisingly easy and straightforward. As this paper describes, there are maintenance and management options after installation, some or all of which may be relevant to a given environment.

Other maintenance issues not covered in the paper are more generic and concern the RMS databases – for example, administrators will want to set up database maintenance plans to perform database and log backups, database consistency checks, and log-shipping, as appropriate. Microsoft, in its implementation, chose a simple recovery model for the Directory Services and Logging databases, with a full recovery model and transaction log shipping on the Configuration database.

As a whole, getting Office 2003 Editions clients up and running with IRM is one of the easier enterprise deployment tasks administrators can face. The benefits are available immediately, as information workers can begin incorporating IRM functionality into their existing collaborative processes with very little effort.

Top of page

Find Additional Information

For more information, see the following web sites:

Microsoft Office System

http://office.microsoft.com/home/default.aspx

Windows Rights Management Services

http://www.microsoft.com/windowsserver2003/technologies/rightsmgmt/default.mspx

Rights Management Add-on for Internet Explorer

http://www.microsoft.com/windows/ie/downloads/addon/

Public Key Infrastructure

http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx

Product Support

Comprehensive and convenient telephone and online support for Windows RMS will be available in the U.S. from 6 a.m. to 6 p.m. daily, with 24/7 support available for customers with urgent situations. Support is offered to retail, MSDN and select customers in a variety of formats, including pay-per-incidence support, fixed price and pre-packaged phone- and Web-based support offerings, and consultative support services delivered remotely through accredited specialists.

To reach Microsoft Support, connect to http://support.microsoft.com. For larger organizations requiring managed support direct from Microsoft, contracts are available from Microsoft Premier Support.

For information on international support, click on the International Support hyperlink at http://support.microsoft.com.

In addition, a comprehensive deployment guide, with an extensive troubleshooting section, is included with RMS.

Microsoft text telephone (TTY/TDD) services are also available.

Note: Microsoft's support services are subject to then-current prices, terms, and conditions, which are subject to change without notice.

Top of page