Deploying and Configuring Information Rights Management

Information Rights Management (IRM) is a new feature in Microsoft® Office 2003 that can help organizations have greater control of their sensitive information. IRM extends a Windows® platform technology called Windows Rights Management Services and is a persistent, file-level technology that allows the user to specify permission for who can access and use documents or e-mail messages. It helps to prevent sensitive information from being printed, forwarded, or copied by unauthorized individuals. If permission for a document or message is restricted by using IRM, the usage restrictions travel with the document or e-mail message as part of the contents of the file.


 Note    The ability to create documents or e-mail messages with restricted permission by using IRM is available only with the Microsoft Office Professional Edition 2003 version of the following applications — Microsoft Office Word 2003, Microsoft Office Excel® 2003, Microsoft Office PowerPoint® 2003, and Microsoft Office Outlook® 2003. IRM is also available in the stand-alone versions of those applications.


There are two ways to enable IRM functionality in Office 2003:

  • Microsoft Windows Rights Management Services for Windows Server® 2003
  • Microsoft IRM service

When enabled by an organization that uses Windows Rights Management Services (RMS) on Windows Server 2003, users of Office 2003 can easily take advantage of IRM functionality. A simple user interface based on customizable permission policies (available from the File menu) and integration with the Active Directory® directory service makes IRM convenient and approachable. In addition, the Rights Management Add-on for Microsoft Internet Explorer allows users of Windows — if they have the proper permission — to read e-mail messages and some documents with restricted permission whether or not they have Office 2003.

For home users and for organizations that do not host their own Windows RMS on Windows Server 2003, users can share protected documents and e-mail messages by using Windows Live ID as the authentication mechanism instead of Active Directory. Windows Live ID accounts can be used when assigning permissions to the various users who need access to the contents of the file. However, use of Windows Live ID accounts for RMS authentication does not allow for groups of users to gain access to a file. Each user must specifically be granted permission to the file. In addition, each client workstation must have access to the Internet to access Windows Live ID servers. Note that users of the Windows Live ID service cannot create custom rights templates.

This article describes the configuration requirements and options for enabling IRM functionality within an organization that hosts Windows RMS on Windows Server 2003. For information about the Microsoft IRM service, see the Windows Rights Management documentation on the Windows Server 2003 Web site.

Deployment

Because IRM functionality is an extension of RMS, IRM deployment is contingent upon RMS deployment. Once RMS is deployed, IRM deployment is simply a matter of installing the Windows Rights Management client on client computers. Each client computer and user then receive a certificate allowing IRM usage.

Deployment requirements

RMS is designed to make the most of existing infrastructure investments, by using Active Directory for service discovery and NTLM authentication. With the flexibility of Windows authentication, RMS can utilize smart card and biometric devices in addition to other alternate authentication methods supported by Windows. The following is needed to run RMS.

On the server:

  • Windows Server 2003 with Windows RMS server software. Windows RMS is a new premium service for Windows Server 2003 Standard, Enterprise, Web, and Datacenter editions.
  • Internet Information Services (IIS) 7.0.
  • Active Directory. Active Directory accounts are used to acquire and use licenses.
  • A database, such as a Microsoft SQL Server® database, to store configuration data.

On the client:

  • Windows RMS client software.
  • An RMS-enabled application for creating or viewing rights-protected content. The Office 2003 Editions include the first RMS-enabled applications available from Microsoft. Office Professional Edition 2003 is required for creating or viewing Office System documents, such as spreadsheets, presentations, and e-mail messages, that are rights-protected. Other Office 2003 Editions allow designated users to view and edit, not create, rights-protected documents if they have been given those rights by the author. The Rights Management Add-on for Internet Explorer allows designated users to view rights-protected documents.

For information about the hardware requirements for deploying and operating RMS, see the Windows Rights Management documentation on the Windows Server 2003 Web site.

Deployment tasks

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

  1. Meet the hardware, software, and infrastructure requirements.
  2. Obtain and install the RMS server software.
  3. Enroll the server by obtaining a Windows RMS Licensor Certificate from Microsoft. This certificate is unique to each organization.
  4. Register the server's URL in Active Directory.
  5. Deploy Rights Management client software on each user's computer. Microsoft Systems Management Server (SMS) 2003 or Group Policy scripts can be used to automate the delivery to each computer.

The computer activation process takes place during the RMS client software installation. During this process, a unique RMS lockbox and computer certification is issued to each computer.

  1. Certify RMS users. When a user attempts to use RMS — for example, by using IRM in Office 2003 applications — the following occurs:
    • The computer obtains a certificate that activates it as a computer capable of creating protected content.
    • The user obtains a certificate that associates him or her with that computer, and enables the creation of protected content.

For information about the RMS topology and installing RMS, see the Windows Rights Management documentation on the Windows Server 2003 Web site.

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 computers. After a client computer is set up, the infrastructure is in place to permit RMS-enabled applications to publish and consume rights-protected information.

Organizations can use standard software deployment tools, such as 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 user to access and use rights-protected information from that computer. The first time a user 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 by using Windows authentication and creates an account certificate, including a public/private key pair, based on the user's validated credentials. It encrypts the user'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.

Because the certificate of the client computer is required to request the account certificate, user certification follows the client computer activation process. Users must acquire an account certificate for each computer that they use. If a user 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 ensures 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 users 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:

  1. The client computer sends the user's account certificate and an enrollment request to the RMS server.
  2. The server validates that sub-enrollment is allowed, based on the network administrator settings, and that the account certificate is not on an exclusion list in the configuration database.
  3. The server creates a public/private key pair specifically to grant offline publishing rights for the user making the request. It creates a client licensor certificate and places the public key in that certificate. It then encrypts the private key with the account certificate public key, and places the result in the certificate.
  4. The root installation issues a client licensor certificate to the local computer.

Rights policy templates

From the RMS 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 later in the “Revocation lists” section). The template specifies the URL to the list file and the number of days that the list is valid. When a recipient requests a use license based on the template, the system checks the revocation list before the user 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 ensures that the terms of a use license always reflect the most current version of the template.

To add a rights policy template, use the Rights Policy Templates page, which is available from the RMS Administration site on the Windows RMS server.

Making templates available through group policy

When the permission policies are ready, they should be posted to a server share where all users can access 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. After the permission policies are available and the necessary Group Policy settings are implemented and propagated to users, the Permission menu displays the available custom permission policies in a submenu.

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 Active Directory, IRM automatically locates any available templates stored in the location specified. The RMS-enabled Office 2003 applications then display the custom permission policies.

Administrators can create a custom permission policy that configures various people and groups with customized IRM permissions. In some cases, this can greatly simplify the process of setting permissions, because a single custom permission policy can replace the user's need to select multiple permission settings.

For instructions on how to create, edit, and post custom rights policy templates, see the Windows Rights Management documentation on the Windows Server 2003 Web site.

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 following registry entry is under HKCU\Software\Microsoft\Office\11.0\Common\DRM\LicenseServers:

Value name: <server URL>

Value type: DWORD

Value data: [ 0 | 1 ]

If this key is set to 1, licenses are automatically acquired from the server specified by <server URL>, and the Permission to this message is currently restricted dialog box does not appear.


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 applications 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 Windows Live ID–authenticated account. This is identical to the Disable Microsoft Windows Live ID 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 can view the content in the Rights Management Add-on 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. 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 are forced to connect to the Internet or local area network to have their license confirmed by either Windows Live ID 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 Permission dialog box. When a group is selected, the dialog box automatically expands 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 or Expandable String Value

Value data: <UNC or aliased drive>

If this key is present, Office applications that use 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 users, 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:

  • An entity or list of entities that can revoke the certificate. The revoking entity could be a third party.
  • An empty public key as the revoking key so that certificate cannot be revoked.

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 an XML document that uses Extensible Rights Markup Language (XrML), and lists the trusted entities that should no longer have access to rights-protected content. Administrators must create revocation lists that are time-stamped and signed appropriately by using the Revocation List Signing tool that is provided with 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 users who require it, such as a URL that is accessible from both the corporate network and the Internet. This will ensure that both internal and external users 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:

  • A private key is known or suspected to be compromised.
  • An owner requests revocation of a key that is not believed to be compromised.
  • A trusted entity is no longer valid — for example, an employee has been terminated.
  • A security enforcement flaw exists — for example, a certificate issued to a client computer has been compromised.
  • Recertification is required due to authorization changes.

There are several options available when creating revocation lists. For information about these options, see RMS Help, which is installed with the RMS server software.

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:

  • RMS lockbox versions - An administrator can specify a lockbox version against which all licensing requests are checked. If a request is made from a client computer with an earlier lockbox version, the request is denied. Lockbox exclusion also stamps every use license with a condition that it can only bind if the lockbox is current. Enforcing this condition in the license extends the reach of exclusion policies to computers that might not be used to acquire use licenses, but are used to decrypt rights-protected information.

When an organization applies this exclusion policy, users cannot acquire new use licenses until they reactivate their computers. Their ability to access previously licensed files, however, is unaffected. To preserve the user experience, administrators should deploy new lockboxes throughout their organization before enabling exclusion policies. Exclusion policies can then be used as a means to force upgrades for any computers unaffected by the new lockbox deployment.

  • Account certificates - If a user is a trusted entity, but there is reason to believe that the user's account certificate keys have been compromised, an administrator can exclude the public key for that account certificate. No new use licenses are issued to an excluded public key, so the user must recertify and be given a new account certificate with a new key pair. This new account certificate is used for all future activities. However, the user retains the excluded account certificate to access previously licensed, rights-protected information.
  • Applications - Applications can be prevented from acquiring use licenses. Administrators can specify application version numbers.

Logging

During the initial RMS system setup, Windows RMS automatically installs and enables support for logging. The logging service enables an organization to record both the users who have successfully accessed rights-protected information and those who attempted unauthorized access of rights-protected information. 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 Message Queuing (also known as 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 sends 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.

Trust policies

By default, Windows RMS does not service requests from users whose rights management account certificates 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.

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

 
 
Applies to:
Deployment Center 2003