RMS Features

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

RMS provides a unified solution that you can use to protect content. RMS also provides tools that you can use to set up and configure the servers, clients, and user accounts for trusted entities that are in an RMS system. This setup involves the following features:

  • Server enrollment. An organization sets up a root cluster in each forest that will participate in its RMS system by enrolling each RMS server in the Microsoft Enrollment Service. The enrollment process can occur automatically if the server is connected to the Internet, or if the server is not connected to the Internet, you can use the offline enrollment process to enroll the server manually by submitting an enrollment request to Microsoft from another computer that has Internet connectivity. Once the server is enrolled, it is assigned a server licensor certificate that identifies it in the organization’s RMS trust hierarchy. The organization then sets up the remaining servers that will be part of the system by either joining them to the root cluster in that forest or by enrolling one or more servers in a licensing-only cluster. The server enrollment process establishes the certificates that allow servers to issue licenses that are trusted by RMS. For more information, see RMS Enrollment in RMS: Technical Reference in this documentation collection.

  • Client-software installation. If you are running a version of Microsoft Windows earlier than Windows Vista®, you must install the RMS client software on all client computers in the organization that will be used to create or consume rights-protected information. After the software is installed, the computer must be activated. The computer is activated when a machine certificate is created for the logged-on user. The machine certificate contains the computer's public key. The activation process is internal to the computer and transparent to the user.

    Note

    The RMS client, now named the Active Directory Rights Management Client, is integrated into Windows Vista; therefore a separate installation is no longer required.

  • User certification. Organizations must identify the users who are trusted entities within their RMS installation. To allow this, RMS issues rights account certificates that associate user accounts with a key pair that is protected specifically to the user's computer. These certificates allow users to publish and consume rights-protected content. Each certificate contains a public key that is used to license information that is intended for that user's consumption. For more information, see RMS Account Certification in RMS: Technical Reference in this documentation collection.

  • Client enrollment. If client computers will be used to publish rights-protected content when they are not connected to the corporate network, client enrollment is required. Client computers that enroll with RMS receive client licensor certificates, which allow users to publish rights-protected content when the computers are not connected to the corporate network. For more information, see RMS Client Enrollment in RMS: Technical Reference in this documentation collection.

  • Standard usage rights and conditions definitions. RMS uses an XML vocabulary to express usage rights and conditions, the eXtensible rights Markup Language (XrML), version 1.2.1. For more information, see XrML in RMS: Technical Reference in this documentation collection.

  • Publishing licenses that define usage rights and conditions. Authors can use simple tools in RMS-enabled applications to assign to their content-specific usage rights and conditions that are consistent with their organization's business policies. These usage rights and conditions are defined within publishing licenses that specify the authorized users who can consume the content and how that content can be used and distributed. For more information, see Publishing Licenses in RMS: Technical Reference in this documentation collection.

  • Use licenses that enforce usage rights and conditions. A user who receives rights-protected content must request and receive a use license from RMS to be able to view the content. A use license is granted to an individual and lists the usage rights and conditions when that person consumes that content. An RMS-enabled application can use RMS technology features to read, interpret, and enforce the usage rights and conditions. For more information, see Use Licenses in RMS: Technical Reference in this documentation collection.

  • Encryption and keys. Rights-protected content is always encrypted. RMS-enabled applications use symmetric keys to encrypt content. All RMS with SP1 servers and later, client computers, and user accounts have an associated key pair of 1024-bit RSA keys. RMS uses these key pairs to encrypt the content key in both publishing and use licenses, and to sign RMS certificates and licenses to ensure that access is granted only to properly authorized users and computers. Specifically, the content key is encrypted using the server's public key in the publishing license, when the user attempts to consume the protected content the content key is encrypted using the users rights account certificate public key in the use license to enable it to specify and enforce the rights granted to the specific user account. For more information, see RMS Encryption and Keys in RMS: Technical Reference in this documentation collection.

  • Rights policy templates. Administrators can create and distribute official rights policy templates that define the usage rights and conditions for a predefined set of users. These templates provide a manageable way for organizations to establish document classification hierarchies for their content. For example, an organization might create rights policy templates for its employees that assign separate usage rights and conditions for company-confidential, classified, and private content. RMS-enabled applications can use these templates, which provide a simple, consistent way for users to apply usage policies to content. For more information, see Rights Policy Templates in RMS: Technical Reference in this documentation collection.

  • Revocation lists. Administrators can create and distribute revocation lists that identify the compromised principals that are invalidated and essentially removed from the RMS system. An organization's revocation list can invalidate the certificates for specific computers or user accounts. For example, the rights account certificate of a terminated employee can be added to the revocation list, so that it can no longer be used for any operations, such as acquiring new publishing and use licenses. For more information, see RMS Revocation in RMS: Technical Reference in this documentation collection.

  • Exclusion policies. Administrators can implement server-side exclusion policies to deny license requests that are based on the requestor's user ID (Windows logon credential or Windows Live ID), rights account certificate, or lockbox version. Exclusion policies deny new license requests that are made by compromised principals but, unlike revocation, exclusion policies do not invalidate the principals. Administrators can also exclude potentially harmful or compromised applications so that they cannot decrypt rights-protected content. For more information, see RMS Exclusion in RMS: Technical Reference in this documentation collection.

  • Logging. Administrators can track and audit the use of rights-protected content within an organization. RMS logs all activities into a logging database, so that organizations have a record of RMS activities, including the publishing and use licenses that have been issued or denied. For more information, see Managing Logging in RMS: Operations in this documentation collection.

  • Extensible and customizable solution. You can extend RMS to support additional features by using the Windows Rights Management Services SDK.