Active Directory Rights Management Services Role
Updated: January 21, 2008
Applies To: Windows Server 2008
For Windows Server® 2008, Active Directory Rights Management Services (AD RMS) includes several new features that were not available in Microsoft® Windows® Rights Management Services (RMS). These new features were designed to ease administrative overhead of AD RMS and to extend its use outside of your organization. These new features include:
Inclusion of AD RMS in Windows Server 2008 as a server role
Administration through a Microsoft Management Console (MMC)
Integration with Active Directory Federation Services (AD FS)
Self-enrollment of AD RMS servers
Ability to delegate responsibility by means of new AD RMS administrative roles
|This topic concentrates on the features specific to AD RMS that are being released with Windows Server 2008. Earlier versions of RMS were available as a separate download. For more information about the features that were available in RMS, see Windows Server 2003 Rights Management Services (RMS) (http://go.microsoft.com/fwlink/?LinkId=68637).|
AD RMS, a format and application-agnostic technology, provides services to enable the creation of information-protection solutions. It will work with any AD RMS-enabled application to provide persistent usage policies for sensitive information. Content that can be protected by using AD RMS includes intranet Web sites, e-mail messages, and documents. AD RMS includes a set of core functions that allow developers to add information protection to the functionality of existing applications.
An AD RMS system, which includes both server and client components, performs the following processes:
Licensing rights-protected information. An AD RMS system issues rights account certificates, which identify trusted entities (such as users, groups, and services) that can publish rights-protected content. Once trust has been established, users can assign usage rights and conditions to content they want to protect. These usage rights specify who can access rights-protected content and what they can do with it. When the content is protected, a publishing license is created for the content. This license binds the specific usage rights to a given piece of content so that the content can be distributed. For example, users can send rights-protected documents to other users inside or outside of their organization without the content losing its rights protection.
Acquiring licenses to decrypt rights-protected content and applying usage policies. Users who have been granted a rights account certificate can access rights-protected content by using an AD RMS-enabled client application that allows users to view and work with rights-protected content. When users attempt to access rights-protected content, requests are sent to AD RMS to access, or “consume,” that content. When a user attempts to consume the protected content, the AD RMS licensing service on the AD RMS cluster issues a unique use license that reads, interprets, and applies the usage rights and conditions specified in the publishing licenses. The usage rights and conditions are persistent and automatically applied everywhere the content goes.
Creating rights-protected files and templates. Users who are trusted entities in an AD RMS system can create and manage protection-enhanced files by using familiar authoring tools in an AD RMS-enabled application that incorporates AD RMS technology features. In addition, AD RMS-enabled applications can use centrally defined and officially authorized usage rights templates to help users efficiently apply a predefined set of usage policies.
AD RMS is designed to help make content more secure, regardless of wherever the rights-protected content might be moved to.
You should review this section, and additional documentation about AD RMS, if you are in any of the following groups:
IT planners and analysts who are evaluating enterprise rights management products
IT professionals responsible for supporting an existing RMS infrastructure
IT security architects who are interested in deploying information protection technology that provides protection for both data at rest and in motion
AD RMS relies on Active Directory Domain Services (AD DS) to verify that the user attempting to consume rights-protected content is authorized to do so. When registering the AD RMS service connection point (SCP) during installation, the installing user account must have Write access to the Services container in AD DS.
Finally, all configuration and logging information is stored in the AD RMS Logging Database. In a test environment, you can use the Windows Internal Database, but in a production environment, we recommend using a separate database server.
AD RMS includes a number of enhancements over earlier versions of RMS. These enhancements include the following:
Improved installation and administration experience. AD RMS is included with Windows Server 2008 and is installed as a server role. Additionally, AD RMS administration is done through an MMC, as opposed to the Web site administration presented in the earlier versions.
Self-enrollment of the AD RMS cluster. AD RMS cluster can be enrolled without having to connect to the Microsoft Enrollment Service. Through the use of a server self-enrollment certificate, the enrollment process is done entirely on the local computer.
Integration with AD FS. AD RMS and AD FS have been integrated such that enterprises are able to leverage existing federated relationships to collaborate with external partners.
New AD RMS administrative roles. The ability to delegate AD RMS tasks to different administrators is needed in any enterprise environment and is included with this version of AD RMS. Three administrative roles have been created: AD RMS Enterprise Administrators, AD RMS Template Administrators, and AD RMS Auditors.
AD RMS in Windows Server 2008 brings many improvements to both the installation and administration experience. In earlier versions of RMS, a separate installation package had to be downloaded and installed, but in this version, AD RMS has been integrated into the operating system and is installed as a server role through Server Manager. Configuration and provisioning is achieved through the server role installation. Additionally, Server Manager automatically lists and installs all services that AD RMS is dependent on, such as Message Queuing and Web Server (IIS), during the AD RMS server role installation. During installation, if you do not specify a remote database as the AD RMS Configuration and Logging database, the AD RMS server role installation automatically installs and configures the Windows Internal Database for use with AD RMS.
In the earlier versions of RMS, administration was done through a Web interface. In AD RMS, the administrative interface has been migrated to an MMC snap-in console. AD RMS console gives you all the functionality available with the earlier version of RMS but in an interface that is much easier to use.
Offering AD RMS as a server role that is included with Windows Server 2008 makes the installation process less burdensome by not requiring you to download AD RMS separately before installing it.
Using an AD RMS console for administration instead of a browser interface makes more options available to improve the user interface. The AD RMS console employs user interface elements that are consistent throughout Windows Server 2008, which is designed to be much easier to follow and navigate. Additionally, with the inclusion of AD RMS administration roles, the AD RMS console displays only the parts of the console that the user can access. For example, a user who is using the AD RMS Template Administrators administration role is restricted to tasks that are specific to AD RMS templates. All other administrative tasks are not available in the AD RMS console.
Server enrollment in AD RMS is the process of creating and signing a server licensor certificate (SLC) that grants the AD RMS server the right to issue certificates and licenses. In earlier versions of RMS, the SLC had to be signed by the Microsoft Enrollment Service through an Internet connection. This required that either the RMS server had to have Internet connectivity to do online enrollment with the Microsoft Enrollment Service or be able to connect to another computer with Internet access that could do offline enrollment of the server.
In AD RMS with Windows Server 2008, the requirement for AD RMS server to directly contact the Microsoft Enrollment Service has been removed. Instead, a server self-enrollment certificate is included with Windows Server 2008 that signs the AD RMS server's SLC.
Requiring the SLC to be signed by the Microsoft Enrollment Service introduced an operational dependency that many customers did not want to introduce into their environment. The Microsoft Enrollment Service is no longer required to sign the SLC.
Instead of requiring the Microsoft Enrollment Service to sign the AD RMS server's SLC, the server self-enrollment certificate, included with Windows Server 2008, can sign the SLC locally. The server self-enrollment certificate allows AD RMS to operate in a network that is entirely isolated from the Internet.
When upgrading from RMS with Service Pack 1 (SP1) or later, the root cluster must be upgraded before the licensing-only cluster. This is required so that the licensing-only cluster receives the root cluster's new self-enrolled SLC.
Enterprises are increasingly feeling the need to collaborate outside their enterprise boundaries and are looking at federation as a solution. Federation support with AD RMS will allow enterprises to leverage their established federated relationships to enable collaboration with external entities. For example, an organization that has deployed AD RMS can set up federation with an external entity by using AD FS and can leverage this relationship to share rights-protected content across the two organizations without requiring a deployment of AD RMS in both places.
In earlier versions of RMS, the options for external collaboration of rights-protected content were limited to Windows Live™ ID. Integrating AD FS with AD RMS provides the ability to establish federated identities between organizations and share rights-protected content.
If you are interested in using AD FS with AD RMS, you must have federated trust between your organization and the external partners you would like to collaborate with before AD RMS is installed. Additionally, you must use the AD RMS client included with Windows Vista® or RMS Client with Service Pack 2 (SP2) to take advantage of the AD FS integration with AD RMS. RMS clients earlier than RMS Client with SP2 will not support AD FS collaboration.
To better delegate control of your AD RMS environment, new administrative roles have been created. These administrative roles are local security groups that are created when the AD RMS role is installed. Each of these administrative roles has different levels of access to AD RMS associated with them. The new roles are AD RMS Service Group, AD RMS Enterprise Administrators, AD RMS Template Administrators, and AD RMS Auditors.
The AD RMS Service Group holds the AD RMS service account. When the AD RMS role is added, the service account configured during setup is added to this administrative role automatically.
The AD RMS Enterprise Administrators role allows members of this group to manage all AD RMS policies and settings. During AD RMS provisioning, the user account installing the AD RMS server role and the local administrators group are added to the AD RMS Enterprise Administrators role. As a best practice, membership of this group should be restricted to only user accounts that need full AD RMS administrative control.
The AD RMS Templates Administrators role allows members of this group to manage rights policy templates. Specifically, AD RMS Template Administrators can read cluster information, list rights policy templates, create new rights policy templates, modify existing rights policy template, and export rights policy templates.
The AD RMS Auditors role allows members of this group to manage logs and reports. This is a read-only role that is restricted to read cluster information, read logging settings, and run reports available on the AD RMS cluster.
The new AD RMS administrative roles give you the opportunity to delegate AD RMS tasks without giving full administrative control over the entire AD RMS cluster.
Customers who would like to deploy AD RMS in their organization will not have to do anything to prepare for this change. Optionally, it is recommended to create Active Directory security groups for each of these administrative roles and add them to their respective local security groups. This will give you the ability to scale your AD RMS deployment across several servers without having to add specific user accounts to each AD RMS server.