Active Directory Rights Management Services

Active Directory Rights Management Services (AD RMS) for the Windows Server 2008 R2 operating system is information protection technology that works with AD RMS-enabled applications to help safeguard digital information from unauthorized use, both online and offline, and inside and outside of a firewall. AD RMS is designed for organizations that need to protect sensitive and proprietary information such as financial reports, product specifications, customer data, and confidential e-mail messages. AD RMS augments an organization's security strategy by providing protection of information through persistent usage policies (also known as usage rights and conditions), which remain with the information no matter where it is moved. AD RMS persistently protects any binary format of data, so the usage rights remain with the information rather than in an organization's network. This also enables usage rights to be enforced after the information is accessed by an authorized recipient, both online and offline, and inside and outside of the organization. AD RMS helps protect information through persistent usage policies by establishing the following essential elements:

  • Trusted entities. Organizations can specify the entities, such as individuals, groups of users, computers, and applications that are trusted participants in an AD RMS system. By establishing trusted entities, AD RMS can help protect information by enabling access only to properly trusted participants.

  • Usage rights and conditions. Organizations and individuals can assign usage rights and conditions that define how a specific trusted entity can use rights-protected content. Examples of usage rights are permission to read, copy, print, save, forward, and edit. Usage rights can be accompanied by conditions, such as when those rights expire. Organizations can exclude applications and entities from accessing the rights-protected content.

  • Encryption. Encryption is the process by which data is locked by using electronic keys. AD RMS encrypts information. This makes access conditional on the successful validation of the trusted entities. Once information is locked, only trusted entities that were granted usage rights under the specified conditions (if any) can unlock or decrypt the information in an AD RMS-enabled application or browser. The defined usage rights and conditions will then be enforced by the application.

The following topics provide information to assist you in accomplishing administrative tasks by using the Active Directory Rights Management Services console. Review the following topics to learn more about how to work with your AD RMS cluster.

  • Active Directory Rights Management Services Overview

  • Pre-installation Information for Active Directory Rights Management Services

  • Checklist: Deploying a Single-Server Installation

  • Checklist: Deploying AD RMS in an Extranet

  • Checklist: Deploying AD RMS in an Organization with Users in Multiple Forests

  • Checklist: Deploying an AD RMS Licensing-only Cluster

  • Checklist: Deploying AD RMS with AD FS

  • Checklist: Deploying AD RMS with Microsoft Federation Gateway Support

  • Installing an AD RMS Cluster

  • Installing Microsoft Federation Gateway Support

  • Configuring an AD RMS Cluster

  • Removing an AD RMS Cluster

  • Working with the AD RMS Client

  • Resources for AD RMS

  • User Interface: AD RMS

You can configure and manage AD RMS by using either the Windows interface or Windows PowerShell. The topics listed here describe methods for using the Windows interface. For more information about how to use Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

For more information about how to plan, deploy, and troubleshoot AD RMS, see the Active Directory Rights Management Services TechCenter (http://go.microsoft.com/fwlink/?LinkId=80907).


Active Directory Rights Management Services Overview

By using Active Directory Rights Management Services (AD RMS) and the AD RMS client, you can augment an organization's security strategy by protecting information through persistent usage policies, which remain with the information, no matter where it is moved. You can use AD RMS to help prevent sensitive information—such as financial reports, product specifications, customer data, and confidential e-mail messages—from intentionally or accidentally getting into the wrong hands.

For information about AD RMS, see the Active Directory Rights Management Services TechCenter page at http://go.microsoft.com/fwlink/?LinkId=80907.

In the following sections, learn more about AD RMS, the required and optional features in AD RMS, and hardware and software used for running AD RMS. At the end of this topic, learn how to open the AD RMS console and how to find more information about AD RMS.

What is Active Directory Rights Management Services?

An AD RMS system includes a Windows Server® 2008 R2-based server running the Active Directory Rights Management Services (AD RMS) server role that handles certificates and licensing, a database server, and the AD RMS client. The latest version of the AD RMS client is included as part of the Windows® 7 and Windows Vista® operating systems. The deployment of an AD RMS system provides the following benefits to an organization:

  • Safeguard sensitive information. Applications such as word processors, e-mail clients, and line-of-business applications can be AD RMS-enabled to help safeguard sensitive information Users can define who can open, modify, print, forward, or take other actions with the information. Organizations can create custom usage policy templates such as "confidential - read only" that can be applied directly to the information.

  • Persistent protection. AD RMS augments existing perimeter-based security solutions, such as firewalls and access control lists (ACLs), for better information protection by locking the usage rights within the document itself, controlling how information is used even after it has been opened by intended recipients.

  • Flexible and customizable technology. Independent software vendors (ISVs) and developers can AD RMS-enable any application or enable other servers, such as content management systems or portal servers running on Windows or other operating systems, to work with AD RMS to help safeguard sensitive information. ISVs are enabled to integrate information protection into server-based solutions such as document and records management, e-mail gateways and archival systems, automated workflows, and content inspection.

AD RMS provides developer tools and industry security technologies—including encryption, certificates, and authentication—to help organizations create reliable information protection solutions. For creating customized AD RMS solutions, an AD RMS software development kit (SDK) is available.

Features in AD RMS

By using Server Manager, you can set up the following components of AD RMS:

  • Active Directory Rights Management Services. The Active Directory Rights Management Services (AD RMS) role service is a required role service that installs the AD RMS components used to publish and consume rights-protected content.

  • Identity Federation Support. The identity federation support role service is an optional role service that allows federated identities to consume rights-protected content by using Active Directory Federation Services.

  • Microsoft Federation Gateway Support . The Microsoft Federation Gateway is an identity service that runs over the Internet and mediates between an organization or business and the external services that the organization wants to use. The gateway connects users and other identities to the services that it works with, so that an organization only has to manage a single identity-federation relationship to enable its identities to access all Microsoft and Microsoft-based services they want to use.

Hardware and software considerations

AD RMS runs on a computer running the Windows Server 2008 R2 operating system. When the AD RMS server role is installed, the required services are installed, one of which is Internet Information Services (IIS). AD RMS also requires a database, such as Microsoft SQL Server, which can be run either on the same server as AD RMS or on a remote server, and an Active Directory Domain Services forest.

The following table describes the minimum hardware requirements and recommendations for running Windows Server 2008 R2-based servers with the AD RMS server role.

Requirement | Recommendation
One Pentium 4 3 GHz processor or higher | Two Pentium 4 3 GHz processors or higher
512 MB of RAM | 1024 MB of RAM
40 GB of free hard disk space | 80 GB of free hard disk space
Note

A limited set of server roles is available for the Server Core installation option of Windows Server 2008 and for Windows Server 2008 for Itanium-Based Systems.

To assist with your hardware considerations, use testing in a lab environment, data from existing hardware in a production environment, and pilot roll-outs to determine the capacity needed for your server.

The following table describes the software requirements for running Windows Server 2008 R2-based servers with the AD RMS server role. For requirements that can be met by enabling features on the operating system, installing the AD RMS server role will configure those features as appropriate, if they are not already configured.

Software | Requirement
Operating system | Windows Server 2008 R2
File system | NTFS file system is recommended
Messaging | Message Queuing
Web services | Internet Information Services (IIS). ASP.NET must be enabled.
Active Directory or Active Directory Domain Services | AD RMS must be installed in an Active Directory domain in which the domain controllers are running Windows Server 2000 with Service Pack 3 (SP3), Windows Server 2003, Windows Server® 2008, or Windows Server 2008 R2. All users and groups who use AD RMS to acquire licenses and publish content must have an e-mail address configured in Active Directory.
Database server | AD RMS requires a database server, such as Microsoft SQL Server 2005 or Microsoft SQL Server 2008, and stored procedures to perform operations. The AD RMS server role on Windows Server 2008 R2 does not support Microsoft SQL Server 2000.

The AD RMS-enabled client must have an AD RMS-enabled browser or application, such as Microsoft Word, Outlook, or PowerPoint in Microsoft Office 2007. The AD RMS-enabled client must have an AD RMS-enabled browser or application, such as Microsoft Word, Outlook, or PowerPoint in Microsoft Office 2007. These applications require the Enterprise, Professional Plus, or Ultimate versions of Microsoft Office 2007 to create rights-protected content. For additional security, AD RMS can be integrated with other technologies such as smart cards.

Windows 7 and Windows Vista include the AD RMS client by default, but other client operating systems must have the RMS client installed. The RMS client with Service Pack 2 (SP2) can be downloaded from the Microsoft Download Center and works on versions of the client operating system earlier than Windows Vista and Windows Server 2008.

For more detailed information about hardware and software considerations with AD RMS, see the Pre-installation Information for Active Directory Rights Management Services topic on the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=84733).

Installing AD RMS

After you finish installing the operating system, you can use Initial Configuration Tasks or Server Manager to install server roles. To install AD RMS, in the list of tasks, click Add roles, and then click the Active Directory Rights Management Services check box.

For detailed instructions about installing and configuring AD RMS in a test environment, see the AD RMS installation Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=72134).

Managing AD RMS

Server roles are managed by using a Microsoft Management Console (MMC) snap-in. Use the Active Directory Rights Management Services console to manage AD RMS. To open the Active Directory Rights Management console, click Start, point to Administrative Tools, and then click Active Directory Rights Management Services.

For more information

To learn more about AD RMS, you can view the Help on your server. To do this, open the Active Directory Rights Management Services console, and then press F1, or visit the Active Directory Rights Management Services TechCenter (http://go.microsoft.com/fwlink/?LinkId=80907).


Pre-installation Information for Active Directory Rights Management Services

Before you install AD RMS

Before you install Active Directory Rights Management Services (AD RMS) on Windows Server® 2008 R2 for the first time, there are several requirements that must be met:

  • Install the AD RMS server as a member server in the same Active Directory Domain Services (AD DS) domain as the user accounts that will be using rights-protected content.

  • Create a domain user account that has no additional permissions that can be used as the AD RMS service account.

  • Select the user account for installing AD RMS with the following restrictions:

    • The user account installing AD RMS must differ from the AD RMS service account.

    • If you are registering the AD RMS service connection point (SCP) during installation, the user account installing AD RMS must be a member of the AD DS Enterprise Admins group, or equivalent.

    • If you are using an external database server for the AD RMS databases, the user account installing AD RMS must have the right to create new databases. If Microsoft SQL Server 2005 or Microsoft SQL Server 2008 is used, the user account must be a member of the System Administrators database role, or equivalent

    • The user account installing AD RMS must have access to query the AD DS domain.

  • Reserve a URL for the AD RMS cluster that will be available throughout the lifetime of the AD RMS installation. Ensure that the reserved URL differs from the computer name.

In addition to pre-installation requirements for AD RMS, we strongly recommend the following:

  • Install the database server that is used to host the AD RMS databases on a separate computer. See System requirements for information about database servers that Windows Server 2008 R2 supports.

  • Install the AD RMS cluster by using a secure sockets layer (SSL) certificate. This certificate should be issued from a trusted root certification authority.

  • Create a DNS alias (CNAME) record for the AD RMS cluster URL and a separate CNAME record for the computer that is hosting the AD RMS configuration database. In the event that the AD RMS servers are retired, lost due to a hardware failure, or the computer's name is changed, a CNAME record can be updated without having to publish all rights-protected files again.

  • If you are using a named instance for the AD RMS configuration database, the SQL Server Browser service must be started on the database server before you install AD RMS. Otherwise, the AD RMS installation will not be able to locate the configuration database and the installation will not succeed.

Before you upgrade from RMS to AD RMS

If you are upgrading from any version of Rights Management Services (RMS) to AD RMS, do the following:

  • Back up the RMS databases and store in a secure location.

  • If your RMS cluster was configured to use the local SYSTEM account as the service account for the cluster, you must change the service account from the local SYSTEM account to a domain user account before upgrading from RMS to AD RMS.

  • If you used the offline enrollment option to provision RMS, make sure that the enrollment is complete before upgrading to AD RMS.

  • If you have been using MSDE to host your RMS databases, you must upgrade the databases to Microsoft SQL Server 2005 or a later version before you upgrade the RMS cluster to AD RMS. An upgrade from versions of RMS by using the MSDE database is not supported.

  • If you have been using Microsoft SQL Server 2000 to host your RMS databases, you must upgrade the databases to Microsoft SQL Server 2005 or a later version before you upgrade the RMS cluster to AD RMS.

  • Flush the RMS Message Queuing queue to make sure that all messages are written to the RMS logging database.

Important considerations for installing AD RMS

The following is a list of things that should be considered before you install AD RMS:

  • Self-signed certificates should be used only in a test environment. For pilot and production environments, we recommend that you use an SSL certificate issued by a trusted certification authority.

  • The Windows Internal Database with AD RMS is intended for use only in test environments. Because the Windows Internal Database does not support remote connections, you cannot add another server to the AD RMS cluster in this scenario.

  • If an SCP already occurs in the Active Directory forest for which you are installing AD RMS, make sure that the cluster URL in the SCP is the same as the cluster URL for the new installation. If they are not the same, you should not register the SCP during AD RMS installation.

  • When installing AD RMS, localhost is not a supported cluster URL.

  • When specifying the AD RMS service account during installation, make sure that a smart card has not been inserted into the computer. If a smart card is attached to the computer, you will get an error message that the user account installing AD RMS does not have access to query AD DS.

  • When joining a new server to an existing AD RMS cluster, the SSL certificate should exist on the new server before the AD RMS installation starts.

  • By default, AD RMS does not support Kerberos authentication. For information about steps that you must take to configure the server to support Kerberos authentication, see Enable support for Kerberos authentication.

  • Windows Server 2008 R2 does not support Windows Rights Management Services (RMS) Client version 1. Support for this version of the client has ended with the release of the latest service pack for RMS Client version 1. To continue being able to create and access AD RMS-protected content, clients that are running RMS Client version 1 must install the latest service pack from the Windows Rights Management Services TechCenter on TechNet (http://go.microsoft.com/fwlink/?LinkId=140054).

Important considerations for installing AD RMS with identity federation support

The following is a list of things that should be considered before you install AD RMS with identity federation support:

  • A federated trusted relationship must be configured before you install Identity Federation Support. During the installation of the Identity Federation Support role service, you are asked to specify the URL of the federation service.

  • Active Directory Federation Services (AD FS) requires secure communication between AD RMS and the AD FS resource server. In order to use federation support with AD RMS, AD RMS must be installed using a secure cluster address.

  • The AD RMS service account must have the Generate Security Audits right. This right is granted by using the Local Security Policy console.

  • The AD RMS extranet cluster URLs must be available to the federated account partner.

Important considerations for installing AD RMS with Microsoft Federation Gateway Support

The following is a list of things that should be considered before you install AD RMS with Microsoft Federation Gateway:

  • The AD RMS cluster must be configured to use an SSL-encrypted connection that uses a certificate that the Microsoft Federation Gateway trusts. To prove your ownership of the domain that you want to federate with the Microsoft Federation Gateway, you must own the X.509 SSL certificate for that domain. It must be from one of the trusted root certification authorities (CAs) that are configured in the Microsoft Federation Gateway. The following table lists those CAs.

    CA certificate friendly name

    Issued to

    Intended purposes

    Entrust (http://go.microsoft.com/fwlink/?LinkId=162663)

    Entrust.net Secure Server Certification Authority

    Server authentication, client authentication, code signing, secure messaging, IP security tunnel termination, Internet Protocol security (IPsec) user, Internet Protocol security (IPsec) Internet Key Exchange (IKE) intermediate, time stamping, file-system encryption

    Go Daddy Class 2 Certification Authority (http://go.microsoft.com/fwlink/?LinkId=162664)

    Go Daddy Class 2 Certification Authority

    Server authentication, client authentication, secure messaging, code signing

    Network Solutions (http://go.microsoft.com/fwlink/?LinkId=162665)

    Network Solutions Certificate Authority

    Server authentication, client authentication, secure messaging, code signing, time stamping

    VeriSign Class 3 Public Primary CA (http://go.microsoft.com/fwlink/?LinkId=162667)

    Class 3 Public Primary Certification Authority

    Secure messaging, client authentication, code signing, server authentication

    VeriSign

    Class 3 Public Primary Certification Authority

    Secure messaging, client authentication, code signing, server authentication

    VeriSign

    VeriSign Trust Network

    Secure messaging, client authentication, code signing, server authentication

    VeriSign

    VeriSign Class 3 Public Primary Certification Authority - G5

    Server authentication, client authentication, secure messaging, code signing
    The SSL certificate that you use to enroll with the Microsoft Federation Gateway must be a certificate that shows ownership of the AD RMS cluster's extranet URL. If the AD RMS cluster is configured with an intranet URL that is different from the extranet URL and if the intranet URL is not a domain name that can be accessed from the Internet, you must install the SSL certificate associated with the extranet URL on this AD RMS server and then select that certificate when enrolling with the Microsoft Federation Gateway.

    If the SSL certificate contains a subject alternate name (SAN), the last entry in the SAN list must be the fully qualified domain name of the domain you want to enroll with the Microsoft Federation Gateway.

  • The virtual directories that are created for use by Microsoft Federation Gateway Support use http://. Because of this, your firewall must be configured to enable http:// data to pass through. Note, however, that the http:// transactions for Microsoft Federation Gateway Support use message-level security.

  • For more information, see Understanding the Microsoft Federation Gateway

Caution

Before uninstalling Service Pack 1 for Windows Server® 2008 R2, you must remove Microsoft Federation Gateway Support from the AD RMS cluster. Failure to do this may cause an inconsistent configuration of your AD RMS cluster. For more information, see Remove Microsoft Federation Gateway Support.

System requirements

The following table describes the minimum hardware requirements and recommendations for running Windows Server® 2008 R2 servers with the AD RMS server role.

Requirement | Recommendation
One Pentium 4 3 GHz processor or higher | Two Pentium 4 3 GHz processors or higher
512 MB of RAM | 1024 MB of RAM
40 GB of free hard disk space | 80 GB of free hard disk space

The following table describes the software requirements for running Windows Server 2008 R2 servers with the AD RMS server role. For requirements that can be met by enabling features on the operating system, installing the AD RMS server role will configure those features as appropriate, if they are not already configured.

Software | Requirement
Operating system | Windows Server 2008 R2
File system | NTFS file system is recommended
Messaging | Message Queuing
Web services | Internet Information Services (IIS) ASP.NET must be enabled.
Active Directory or AD DS | AD RMS must be installed in an Active Directory domain in which the domain controllers are running Windows Server 2000 with Service Pack 3 (SP3), Windows Server 2003, Windows Server® 2008 or Windows Server 2008 R2. All users and groups that use AD RMS to acquire licenses and publish content must have an e-mail address configured in Active Directory.
Database server | AD RMS requires a database server, such as Microsoft SQL Server 2005, and stored procedures to perform operations. The AD RMS server role on Windows Server 2008 R2 does not support Microsoft SQL Server 2000.

Additional references

  • Checklist: Deploying a Single-Server Installation

  • Checklist: Deploying AD RMS in an Extranet

  • Checklist: Deploying AD RMS in an Organization with Users in Multiple Forests

  • Checklist: Deploying an AD RMS Licensing-only Cluster

  • Checklist: Deploying AD RMS with AD FS

  • Checklist: Deploying AD RMS with Microsoft Federation Gateway Support


Checklist: Deploying a Single-Server Installation

The following checklist describes the tasks required to install and configure a Active Directory Rights Management Services (AD RMS) root cluster on a single server that uses the Windows Internal Database. This deployment is appropriate for installing AD RMS in a test environment. This deployment cannot be scaled to include multiple servers in this cluster.

Step | Reference
Install the AD RMS server role | Install AD RMS Server Role
Configure appropriate Windows Firewall exception on the AD RMS server. | Configure Windows Firewall
Add the AD RMS server to the MMC console | Administer AD RMS by Using the Active Directory Rights Management Services console

For more information about installing and configuring AD RMS, see Windows Server Active Directory Rights Management Services Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=72134).


Checklist: Deploying AD RMS in an Extranet

This checklist helps you set up your Active Directory Rights Management Services (AD RMS) cluster to support users that need to work with rights-protected content when they are not connected to your organization's network, such as mobile users and telecommuters.

Step | Reference
Install the AD RMS server role | Install AD RMS Server Role
Configure appropriate Windows Firewall exception | Configure Windows Firewall
Open the Active Directory Rights Management Services console | Administer AD RMS by Using the Active Directory Rights Management Services console
Configure the AD RMS cluster settings | Add an Extranet Cluster URL
Note

This checklist does not cover publishing the AD RMS certification and licensing extranet cluster URLs to the Internet. For recommendations about how to securely publish the extranet cluster URLs to the Internet, see Deploying Active Directory Rights Management Services in an Extranet Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=72138).

For more information about configuring AD RMS to collaborating outside of the organizational network, see Deploying Active Directory Rights Management Services in an Extranet Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=72138).


Checklist: Deploying AD RMS in an Organization with Users in Multiple Forests

Only one Active Directory Rights Management Services (AD RMS) root cluster is permitted per forest. If your organization wants to use rights-protected content in more than one forest, you must have a separate AD RMS root cluster for each forest.

The following steps in this checklist describe the tasks required to deploy AD RMS in an organization with users in multiple forests.

  1. Assign a secure sockets layer (SSL) certificate to the Web site that will be hosting the AD RMS cluster.

  2. Install and configure an AD RMS root cluster in each forest.

  3. If you are not using Exchange Server in each forest, you must extend the Active Directory schema.

  4. Add the AD RMS service account to the access control list of the group expansion pipeline.

For detailed instructions about setting up AD RMS in a multiple forest environment, see Deploying Active Directory Rights Management Services in a multiple forest environment Step-by-Step guide (http://go.microsoft.com/fwlink/?LinkId=72139).

Additional references

  • Install AD RMS Server Role

  • Configure the Access Control List on the GroupExpansion Folder

  • Export a Trusted User Domain

  • Add a Trusted User Domain


Checklist: Deploying an AD RMS Licensing-only Cluster

The following steps in this checklist describe the tasks required to deploy an Active Directory Rights Management Services (AD RMS) licensing-only cluster.

  1. Assign a secure sockets layer (SSL) certificate to the Web site that will be hosting the AD RMS cluster.

  2. Install and configure the AD RMS licensing-only cluster. A root AD RMS cluster must already be present in the AD DS forest before you can install the licensing-only cluster.

    1. During the installation, choose the Create a new AD RMS cluster option.

    2. Enter the name of the computer that will host the AD RMS licensing-only configuration database and the database instance name.

    3. Select the type of key protection to be used for the licensing-only cluster. If you choose to have AD RMS centrally manage the keys, enter the AD RMS cluster key password. If you are using a cryptographic service provider (CSP) to protect the cluster key, create a new key pair or use an existing key pair.

    4. Enter a service account to be used for the licensing-only cluster.

    5. Choose the appropriate Web site where AD RMS should be installed.

    6. Enter the cluster name to be used for the new licensing-only cluster and type the appropriate port number. By default, the port number is 80 if configuring for HTTP and 443 for configuring HTTPS.

    7. Enter a friendly name for the new AD RMS cluster.

For detailed instructions about setting up a licensing-only AD RMS cluster in a test environment, see Deploying and Active Directory Rights Management Services Licensing-only Cluster Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=72141).

Additional reference

  • Installing an AD RMS Cluster


Checklist: Deploying AD RMS with AD FS

The following steps in this checklist describe the tasks required to configure identity federation support with Active Directory Rights Management Services (AD RMS) cluster.

  1. Assign a secure sockets layer (SSL) certificate to the Web site that will be hosting the AD RMS cluster.

  2. Install and configure the AD RMS cluster.

  3. Grant the AD RMS service account privileges to Generate Security Audits found in the Local Security Policy console. This privilege allows the AD RMS service account to generate events and write them to the Security log.

  4. On the AD FS resource partner, create a claims-aware application for the AD RMS certification and licensing pipelines.

  5. Configure the AD RMS extranet cluster URL by using the Active Directory Rights Management Services console.

  6. Add the AD RMS Identity Federation Support role service by using Server Manager.

For detailed instructions about setting up AD RMS and AD FS, see AD RMS with AD FS Identity Federation Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=72135).

Additional references

  • Installing an AD RMS Cluster

  • Configure Federated Identity Support Settings

  • Add an Extranet Cluster URL

  • Import an SSL Certificate Using Internet Information Services (IIS) Manager


Checklist: Deploying AD RMS with Microsoft Federation Gateway Support

The following steps in this checklist describe the tasks required to install and configure Microsoft Federation Gateway Support on an Active Directory Rights Management Services (AD RMS) cluster. For more information about Microsoft Federation Gateway, see Understanding the Microsoft Federation Gateway.

  1. If you have not already done so, on each server in the cluster assign a secure sockets layer (SSL) certificate to the Web site that is hosting the AD RMS cluster. The certificate must be from a certificate authority that is trusted by the Microsoft Federation Gateway. For more information, see Important considerations for installing AD RMS with Microsoft Federation Gateway Support.

  2. If you have rights policy templates that grant user rights to Anyone, you should consider modifying them to prevent granting rights to external users who are authenticated through the Microsoft Federation Gateway. For information on changing a rights policy template, see Edit a Rights Policy Template.

  3. In order to ensure that you can recover your AD RMS cluster in case of a problem, you should back up your AD RMS databases. The AD RMS databases have names that begin with the DRMS_ prefix. The method and procedure you use to back up the databases will depend on the server on which they are stored and the procedure that you typically follow to back up the server databases.

  4. On each server of the AD RMS cluster, install the Microsoft Federation Gateway Support package that you copied in the first step of this checklist and then add Microsoft Federation Gateway Support to each server in the cluster by following the instructions in Add Microsoft Federation Gateway Support.

  5. On one server in the AD RMS cluster, enroll the cluster with the Microsoft Federation Gateway and then enable Microsoft Federation Gateway Support by following the instructions in Enroll with the Microsoft Federation Gateway.

Additional references

  • Installing an AD RMS Cluster

  • Configuring Microsoft Federation Gateway Support


Installing an AD RMS Cluster

The procedures in this section are designed to help you set up Active Directory Rights Management Services (AD RMS) in your organization.

This section contains the following procedures:

  • Understanding AD RMS Clusters

  • Understanding AD RMS Key Protection and Storage

  • Install AD RMS Server Role

  • Upgrade to AD RMS

  • Join an AD RMS Server to an Existing Cluster

  • Administer AD RMS by Using the Active Directory Rights Management Services console

  • Change AD RMS Proxy Settings

  • Add an Extranet Cluster URL

  • Register a Service Connection Point

  • Configure Windows Firewall

  • Check the Password Policy for Your Organization

  • Import an SSL Certificate Using Internet Information Services (IIS) Manager

  • Enable support for Kerberos authentication


Understanding AD RMS Clusters

AD RMS clusters are defined as a single server running AD RMS or a group of servers that share AD RMS publishing and licensing requests from AD RMS clients. When the first AD RMS server is provisioned in an Active Directory forest, it becomes a AD RMS cluster. More servers can be provisioned and added to an AD RMS cluster at any time.

There are two types of clusters: root clusters and licensing-only clusters. The first server in an AD RMS installation always becomes the root cluster. The root cluster handles all certification and licensing requests for the Active Directory Domain Services (AD DS) domain in which it was installed. For complex environments, licensing-only clusters can be created in addition to the root cluster. However, it is recommended to use only a root cluster and join more AD RMS servers to this cluster because root and licensing-only clusters cannot be used in the same load-balancing pool.

Additional reference

  • Installing an AD RMS Cluster


Understanding AD RMS Key Protection and Storage

You can protect the AD RMS cluster key by using a hardware- or software-based cryptographic service provider (CSP) or by storing the cluster key in the AD RMS configuration database. A hardware-based CSP stores the cluster key in a hardware device.

As a best security practice, we recommend using a hardware-based CSP to protect the AD RMS cluster key. When using AD RMS to centrally manage the cluster key from the AD RMS configuration database, you should use a strong cluster key password. If you are upgrading from RMS to AD RMS and using a hardware-based CSP, ensure that the drivers are compatible with Windows Server 2008 R2 before proceeding with the upgrade.

Note

If there are multiple servers in the AD RMS cluster and you are using either a software- or hardware-based CSP to protect the cluster key, you must manually move the cluster key to the other computers before installing AD RMS. Consult the CSP documentation for procedures on moving the cluster key.

Additional references

  • Pre-installation Information for Active Directory Rights Management Services

  • Understanding AD RMS Certificates


Install AD RMS Server Role

The computer on which you are installing AD RMS must be a member server in a domain, or it must be a domain controller. You cannot deploy AD RMS on a server that is part of a workgroup.

Note

If you are installing AD RMS on a domain controller, you must add the AD RMS service account to the Domain Admins group. We do not recommend adding the AD RMS service account to the Enterprise Admins group.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To install the AD RMS Server Role

  1. Log on to the server on which you want to install AD RMS.

  2. Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.

  3. In the Roles Summary box, click Add Roles.

  4. Read the Before You Begin section, and then click Next.

  5. On the Select Server Roles page, select the Active Directory Rights Management Services box.

  6. The Role Services page appears informing you of the AD RMS dependent role services and features. Make sure that Web Server (IIS), Windows Process Activation Service (WPAS), and Message Queuing are listed, and then click Add Required Role Services. Click Next.

  7. Read the AD RMS introduction page, and then click Next.

  8. On the Select Role Services page, verify that the Active Directory Rights Management Server check box is selected, and then click Next.

  9. Select the Create a new AD RMS cluster option, and then click Next.

  10. Select the Use a different database server option, and then click Select.

    Note

    If you choose to use the Windows Internal database to host the AD RMS databases for a single-server installation, steps 11 and 12 are not required.

  11. Type the name of the computer that will be hosting AD RMS databases, and then click OK.

  12. In Database Instance, choose the appropriate instance, click Validate, and then click Next.

  13. On the Specify Service Account page, click Specify, type the domain user account and password that should be used as the AD RMS service account, click OK, and then click Next.

  14. Ensure that the Use AD RMS centrally managed key storage option is selected, and then click Next.

    Note

    If you choose to protect the AD RMS cluster key by using a cryptographic storage provider, step 15 is not required.

  15. Type a strong password in the Password box and in the Confirm password box, and then click Next.

  16. Choose the Web site where the AD RMS Web services will be installed, and then click Next. In a default installation, the name of the Web site should be Default Web Site.

  17. As a best security practice, the AD RMS cluster should be provisioned by using an SSL-encrypted connection. Select the Use an SSL-encrypted connection (https://) option.

  18. Type the fully-qualified domain name of the AD RMS cluster in the Internal Address box, and then click Validate. If you want to change the default port on which AD RMS communicates, you can do that on this page of the wizard as well. If validation succeeds, the Next button will become active. Click Next.

  19. Select the Choose an existing certificate for SSL encryption option, click the appropriate certificate or click Import to import the certificate, and then click Next.

    Important

    Self-signed certificates should only be used for test environments. In a production environment, we strongly recommend using an SSL certificate issued from a certification authority, such as Verisign Inc.

  20. Type a name that will help you identify the AD RMS cluster in the Friendly name box, and then click Next.

  21. Ensure that the Register the AD RMS service connection point now option is selected, and then click Next to register the AD RMS service connection point (SCP) in Active Directory Domain Services (AD DS).

    Important

    In order to register the AD RMS SCP, you must be logged on to the AD RMS server with a user account with write access to the Services container in AD DS.

  22. Read the Introduction to Web Server (IIS) page and then click Next.

  23. Click Next again, leaving the Web server defaults.

  24. Click Install to provision AD RMS on the computer. It can take up to 60 minutes to complete the installation.

  25. Click Finish.

  26. Log off from the server, and then log back on to update the permissions granted to the logged on user account. The user account that is logged on when the AD RMS server role is provisioned is automatically made a member of the AD RMS Enterprise Administrators group. A user must be a member of that group to administer AD RMS.

Additional references

  • Installing an AD RMS Cluster

  • Check the Password Policy for Your Organization


Upgrade to AD RMS

To upgrade to AD RMS from Rights Management Services (RMS) with Service Pack 1 (SP1) or Service Pack 2 (SP2), do the following steps after upgrading the operating system to Windows Server® 2008 R2:

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure, and the user account must be a member of the System Administrators database role, or equivalent, on the database server.

To upgrade to AD RMS

  1. Log on to the server on which you want to upgrade to AD RMS.

  2. Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.

  3. Expand Roles, and then click Active Directory Rights Management Services.

    Note

    An error message might appear when you perform this step. This does not indicate a problem with the upgrade. Click OK to continue.

  4. In the results pane, click Complete Installation of Active Directory Rights Management Services, and then follow the steps in the upgrade wizard to AD RMS.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Pre-installation Information for Active Directory Rights Management Services


Join an AD RMS Server to an Existing Cluster

Additional servers can be joined to a cluster at any time. You can join servers to an AD RMS installation by using any one of the following methods:

  • Join one or more AD RMS servers to a root cluster.

  • Join one or more AD RMS servers to a licensing-only cluster.

Joining servers to a root cluster

For most purposes, joining one or more AD RMS servers to a root cluster is the best way to increase the availability and redundancy of your deployment. A root cluster can contain one or many servers that provide all services to AD RMS clients.

During installation and provisioning, you can choose the option to join a server to a cluster. When you do this, the new AD RMS server is automatically configured as a member of the cluster.

In addition to this provisioning step, if you are creating a cluster for the first time, you must also set up software or hardware with clustering and load balancing as needed. If you have already implemented a cluster, you must configure your load balancing software or hardware to work with the new cluster member.

Joining servers to a licensing-only cluster

Unlike the root cluster, which provides all of the AD RMS services, servers in a licensing-only cluster provides only licensing and publishing services.

Licensing-only clusters are optional and are most often deployed to address specific licensing requirements, such as the following:

  • To support unique rights-management requirements of a department. For instance, a group within your organization may have a different set of rights policy templates that should not be shared with the rest of the organization. Because only one root cluster is allowed in a forest, setting up a separate root cluster is not possible unless a new forest is created. In this case, you could set up a licensing-only cluster that is dedicated to this group’s needs, and then set up rights policy templates separately for that licensing-only cluster.

  • To support rights management for external business partners as part of an extranet that requires strong separation and tracking of resources for specific business partners.

Important

If you are using a software or hardware-based cryptographic service provider (CSP) to protect the AD RMS cluster key, you should import this key container before joining the server to an AD RMS cluster.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To join an AD RMS server to an existing cluster

  1. Log on to the server that you want to join to an existing AD RMS cluster.

  2. Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.

  3. In the Roles Summary box, click Add Roles.

  4. Read the Before You Begin section, and then click Next.

  5. On the Select Server Roles page, select the Active Directory Rights Management Services box check box.

  6. The Role Services page appears informing you of the AD RMS dependent role services and features. Make sure that Web Server (IIS), Windows Process Activation Service (WPAS), and Message Queuing are listed, and then click Add Required Role Services. Click Next.

  7. Read the AD RMS introduction page, and then click Next.

  8. On the Select Role Services page, verify that the Active Directory Rights Management Server check box is selected, and then click Next.

  9. Select the Join an existing AD RMS cluster option, and then click Next.

  10. Type the name of the database server in the Database server box, choose the appropriate database server instance from the Select or enter database server instance box, type the name of the AD RMS configuration database in the Enter database name box, click Validate, and then click Next.

  11. If you are using AD RMS to centrally manage the cluster key, confirm that the database is correct, type the cluster key password in the Password box, type the cluster password again in the Confirm Password box, and then click Next.

  12. Read the Introduction to Web Server (IIS) page, and then click Next.

  13. Keep the Web server default check box selections, and then click Next.

  14. Click Install to join this computer to the existing AD RMS cluster. It can take up to 60 minutes to complete the installation.

  15. Click Finish.

  16. Log off the server, and then log back on to update the permissions granted to the logged on user account. The user account that is logged on when the AD RMS server role is provisioned is automatically made a member of the AD RMS Enterprise Administrators group.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Installing an AD RMS Cluster


Administer AD RMS by Using the Active Directory Rights Management Services console

When you add a cluster to the Active Directory Rights Management Services console, a connection is made between the console and a server in the cluster that serves as the AD RMS cluster connection point. The other servers in the cluster are joined with that server to create the cluster and are managed together.

To administer AD RMS you must have been granted an Administration role on each server in the AD RMS cluster. For day-to-day operations there are three administration groups identified for AD RMS:

  • AD RMS Enterprise Administrators

    Members of this group have access to all features in the AD RMS console. During installation of AD RMS, the installing user account is automatically added to this group.

  • AD RMS Template Administrators

    Members of this group can only access rights policy template administration features in the AD RMS console.

  • AD RMS Auditors

    Members of this group can only access the reports feature in the AD RMS console.

Note

There is also the AD RMS Service Group. Members of this group act as the AD RMS service account. During the installation of AD RMS, the user account designated as the service account is automatically added to this group.

In addition to these administrative groups, some features are restricted to users that have additional credentials:

  • Changing the AD RMS service account.

    Performing this task requires that the logged in user account be a member of the AD RMS Enterprise Administrators group and a member of the local administrators group on the server.

  • Changing the cluster key password

    Performing this task requires that the logged on user account be a member of the AD RMS Enterprise Administrators group and a member of the local administrators group on the server.

  • Registering or changing the service connection point (SCP)

    Performing this task requires that the logged in user account be a member of the AD RMS Enterprise Administrators and have permission to change and create object in Active Directory Domain Services (AD DS). For example, a user who is a member of the AD RMS Enterprise Administrators group and the AD DS Enterprise Admins group would have the proper credentials to perform this task.

Membership in the local AD RMS Enterprise Administrators, AD RMS Template Administrators, or AD RMS Auditors, or equivalent, is the minimum required to complete this procedure.

To open the Active Directory Rights Management Services console

  1. Click Start, point to Administrative Tools, and then click Active Directory Rights Management Services.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

  3. The AD RMS cluster to which this computer is assigned to is added automatically. If you want to add additional clusters, click Add Cluster in the results pane.

Additional reference

  • Installing an AD RMS Cluster


Change AD RMS Proxy Settings

If you control access to resources outside of the local forest by a Web proxy server, you might need to configure AD RMS to use the proxy in some scenarios. Situations that require this are the following:

  • You are supporting Microsoft Rights Management Services (RMS) version 1.0 clients in your organization that do not have Internet connectivity.

    RMS version 1.0 clients must be activated by Microsoft over the Internet prior to the first use. The RMS version 1.0 clients attempts to have the AD RMS cluster proxy the activation request, but if the AD RMS cluster does not respond, the client then tries to obtain the credentials directly through an Internet connection on the local computer, if one is available. In RMS with Service Pack 1 (SP1) and later, AD RMS client computer activation over the Internet is no longer required.

  • You are trusting rights account certificates (RACs) from Windows Live ID users.

    When you select to trust Windows Live ID sites and services as one of your trusted user domains, the AD RMS cluster needs to be able to validate the user against Windows Live ID sites and services.

  • You have multiple forests in your organization that are separated by a Web proxy server and you have established trusts across those forests.

    This is similar to the scenario with Windows Live ID in that the registry of user accounts that the AD RMS cluster must validate against is behind the Web proxy server.

If your AD RMS cluster does not need to negotiate a connection through a proxy server, you do not need to configure these settings. If the proxy server authenticates users before allowing outbound access, you must provide a user account that AD RMS can use when challenged for credentials by the proxy server.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To change the AD RMS Proxy settings

  1. Open the Active Directory Rights Management Services console, right-click the AD RMS cluster, and then click Properties.

  2. Click the Proxy Settings tab, and then select the This cluster uses a proxy server to access external networks box.

  3. In the Address box, type the IP address or DNS name of the proxy server that you want to use.

  4. In the Port box, type the port number that the proxy server uses to connect to the Internet.

  5. If you do not use the proxy server to connect to local resources, select the Bypass proxy server for local addresses check box.

  6. If you have addresses that should not be using the proxy server at all, type them in the Do not use proxy server for address beginning with box.

  7. If appropriate, select the This proxy server requires authentication check box.

    • In Authentication type, choose the appropriate authentication type from the list: Basic, Digest, or Integrated Windows.

    • In the User name box, type the user name that should be supplied in response to the challenge from the proxy server.

    • In the Password and Confirm password boxes, type the password that should be supplied in response to the challenge from the proxy server.

    • If your proxy server uses Integrated Windows authentication, in the Domain box, type the domain to which the user belongs.

  8. Click OK.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Installing an AD RMS Cluster


Add an Extranet Cluster URL

The extranet cluster URLs are used by AD RMS clients that are outside of your internal network to connect to the AD RMS cluster for licensing and certification. Be sure to register the URLs in your Domain Name System (DNS), and verify that it is available from the Internet.

If you are adding extranet cluster URLs to an existing AD RMS cluster, new client licensor certificates (CLC) must be obtained by the current AD RMS clients. The extranet cluster URLs are added to the Extranet-License-Acquisition-URL field in the issuance license and used in AD RMS client service discovery.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To add an extranet cluster URL

  1. Open the Active Directory Rights Management Services console and connect to the AD RMS cluster.

  2. Right-click the cluster, and then click Properties.

  3. Click the Cluster URLs tab.

  4. In the Extranet cluster URLs area, click the Extranet URLs check box, and then specify the URLs from which you want external users to acquire licenses. You can also select either HTTP or HTTPS.

  5. Click Apply.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Installing an AD RMS Cluster

  • AD RMS Client Service Discovery


Register a Service Connection Point

The service connection point (SCP) for AD RMS identifies the connection URL for the service to the AD RMS-enabled clients in your organization. After you register the SCP in Active Directory Domain Services (AD DS), clients will be able to discover the AD RMS cluster to request use licenses, publishing licenses, or rights account certificates (RACs).

When the AD RMS role is configured on your server, the installation attempts to register the AD RMS SCP, but if it is unable to do so, you can register or change the SCP from the cluster Properties sheet in the Active Directory Rights Management Services console.

If you are registering a service connection point (SCP) from an AD RMS cluster in a child domain, you might receive an error stating that SCP registration failed. In many cases, the registration was successful, but the registration first takes place in the top-level domain and it takes time to replicate to the child domain where the AD RMS cluster checks for the SCP object. As soon as the SCP has been replicated to all global catalog servers in the forest, the message will no longer appear.

Membership in the AD RMS Enterprise Administrators and the Enterprise Admins group in AD DS, or equivalent, is the minimum required to complete this procedure.

To register a service connection point

  1. Log on to a server in the cluster on which you need to register an SCP.

  2. Open the Active Directory Rights Management Services console.

  3. Right-click the AD RMS cluster, and then click Properties.

  4. Click the SCP tab.

  5. Select the Change SCP check box.

  6. Click the Set the SCP to current certification cluster option, and then click OK.

  7. Click Yes to confirm.

Additional references

  • Installing an AD RMS Cluster

  • AD RMS Client Service Discovery


Configure Windows Firewall

The Windows Firewall is a host-based firewall application that is installed and turned on by default in Windows Server 2008 R2. If you want to use the functionality of the Windows Firewall within your Active Directory Rights Management Services (AD RMS) infrastructure, you must create a few firewall exceptions.

Note

This topic only discusses the firewall exceptions that are specific to AD RMS. Sometimes additional exceptions need to be made for other applications.

The following table shows the port exceptions that should be made on each AD RMS server in the cluster. It is not necessary to open both ports at the same time. For HTTP transmission, you should only open TCP port 80. If your AD RMS environment is using Secure Sockets Layer (SSL) or HTTPS, you should only open TCP port 443. The default port for SSL is TCP port 443. If your organization is using a port number for SSL other than the default, you should use that port instead.

Note

When AD RMS is installed, the appropriate exception described in the following table is created and enabled automatically.

Port Exception | Description
TCP 80 | HTTP
TCP 443 | HTTPS or SSL communication

If there is more than one server in the AD RMS cluster, or the AD RMS database server is not on the AD RMS in a single-server deployment, the following port exceptions should be created on the database server that is hosting the AD RMS databases. This table assumes that you are using Microsoft SQL Server 2005 or later.

Port Exception | Description
TCP 1433 | Default Microsoft SQL Server listening port
TCP 445 | SQL Server Named Pipes (used for provisioning the AD RMS server)

In addition to creating these port exceptions, special considerations should be taken when configuring the firewall scope. Unless your AD RMS environment is used in an extranet scenario, you should restrict all traffic to your organization's network. If your AD RMS environment needs to be available to client computers outside of your organization's network, you should allow any computer on the Internet to connect to only TCP port 443 or TCP port 80.

Caution

In an AD RMS environment, TCP port 445 is used to provision an AD RMS server, but this port is also the file sharing port for all computers that are running Microsoft Windows 2000 or later. Unless you have a specific need for other computers on your network to have access to this port, you should restrict the scope so that only the AD RMS cluster has access to TCP port 445 on the AD RMS database server.

Additional reference

  • Installing an AD RMS Cluster


Check the Password Policy for Your Organization

When installing an AD RMS cluster, the password used to encrypt the server licensor certificate must conform to the password complexity requirement set forth within your organization.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To check the password complexity requirements in your organization

  1. Log on to a domain controller in the forest where AD RMS should be installed.

  2. Click Start, point to Administrative Tools, and then click Group Policy Management.

  3. Expand the appropriate forest, expand Domains, and then click the appropriate domain.

  4. Double-click Default Domain Policy.

  5. Navigate to:

    Computer Configuration/Windows Settings/Security Settings/Account Policies/Password Policy

  6. Verify that the password you are entering conforms to this password policy.

Additional reference

  • Understanding AD RMS Key Protection and Storage


Import an SSL Certificate Using Internet Information Services (IIS) Manager

As a best security practice, AD RMS should be installed with a Secure Sockets Layer (SSL) certificate used for Web communications. A certificate trusted by a certification authority is recommended.

If you decide to use an SSL certificate in your AD RMS installation, you can either add the certificate during the AD RMS installation or import the certificate after installation is complete. To import the certificate after AD RMS is installed, do the following steps:

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To import an SSL certificate using Internet Information Services (IIS) Manager

  1. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

  3. Click the local computer, and then double-click Server Certificates.

  4. In the Actions pane, click Import.

  5. In the Certificate File (.pfx) box, type the path to the SSL certificate.

  6. In Password, type the password that was used to create this certificate, and then click OK.

Additional reference

  • Installing an AD RMS Cluster


Enable support for Kerberos authentication

If you plan to use Active Directory Rights Management Services (AD RMS) with Kerberos authentication, you must take additional steps to configure the server running AD RMS after installing the AD RMS server role and provisioning the server. Specifically, you must perform these procedures:

  • Set the Internet Information Services (IIS) useAppPoolCredentials variable to True

  • Set the Service Principal Names (SPN) value for the AD RMS service account

Membership in the AD RMS Enterprise Administrators and the Enterprise Admins group in AD DS, or equivalent, is the minimum required to complete this procedure.

Set the IIS useAppPoolCredentials value to True

  1. Open an elevated command prompt window. To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  2. Navigate to %windir%\system32\inetsrv.

  3. Type appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication -useAppPoolCredentials:true.
Important

To perform the following procedure successfully, the AD RMS service account must be in the same forest as the AD RMS cluster. Also, if you change the AD RMS service account, you must delete the SPN registrations for the previous service account and then perform this procedure for the new service account.

Set the Service Principal Names (SPN) value for the AD RMS service account

  1. Open an elevated command prompt window. To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  2. Type setspn -a HTTP/<ServerName> <ServiceAccountDomain>\<ServiceAccount>, where <ServerName> is the name of the server, <ServiceAccountDomain> is the name of the domain containing the AD RMS service account, and <ServiceAccount> is the name of the AD RMS service account.

  3. Type setspn -a HTTP/<ServerFQDN> <ServiceAccountDomain>\<ServiceAccount>, where <ServerFQDN> is the fully qualified domain name (FQDN) of the server.

  4. Type setspn -a HTTP/<ClusterName> <ServiceAccountDomain>\<ServiceAccount>, where <ClusterName> is the name of the AD RMS cluster.

  5. Type setspn -a HTTP/<ClusterFQDN> <ServiceAccountDomain>\<ServiceAccount>, where <ClusterFQDN> is the fully qualified domain name (FQDN) of the cluster.

Note

If the cluster is using Secure Sockets Layer (SSL), repeat steps 2 through 5, substituting HTTPS for HTTP.

Additional reference

Installing an AD RMS Cluster


Installing Microsoft Federation Gateway Support

The procedures in this section are designed to help you add Microsoft Federation Gateway Support to your Active Directory Rights Management Services (AD RMS) cluster. You should perform these procedures as part of the deployment steps described in Checklist: Deploying AD RMS with Microsoft Federation Gateway Support.

This section contains the following procedures:

  • Add Microsoft Federation Gateway Support

  • Enroll with the Microsoft Federation Gateway

See Also

  • Installing an AD RMS Cluster
  • Configuring Microsoft Federation Gateway Support


Add Microsoft Federation Gateway Support

Windows Server® 2008 R2 with Service Pack 1 (SP1) must be installed on every server in your Active Directory Rights Management Services (AD RMS) cluster before you can add Microsoft Federation Gateway Support to the servers in your cluster.

Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure.

Important

Before adding Microsoft Federation Gateway Support, back up the AD RMS configuration database.

To add Microsoft Federation Gateway Support

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  3. In the console tree, click Trust Policies, and then in the Actions pane, click Add Microsoft Federation Gateway Support.

  4. When the Microsoft Federation Gateway wizard appears, click Next.

  5. Click Finish.

  6. Repeat steps 1-5 on all other servers in the AD RMS cluster.
Caution

Before uninstalling Service Pack 1 for Windows Server® 2008 R2, you must remove Microsoft Federation Gateway Support from the AD RMS cluster. Failure to do this may cause an inconsistent configuration of your AD RMS cluster. For more information, see Remove Microsoft Federation Gateway Support.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Installing Microsoft Federation Gateway Support

  • Checklist: Deploying AD RMS with Microsoft Federation Gateway Support


Enroll with the Microsoft Federation Gateway

In order to use the Microsoft Federation Gateway, after you add Microsoft Federation Gateway Support, you must enroll your Active Directory Rights Management Services (AD RMS) cluster with the Microsoft Federation Gateway. After this, you must configure and enable Microsoft Federation Gateway Support. The following procedure explains this process.

Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To enroll the AD RMS cluster and enable Microsoft Federation Gateway Support

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  3. In the console tree, expand Trust Policies, and then click Microsoft Federation Gateway Support.

  4. In the Actions pane, click Configure Microsoft Federation Gateway Support.

  5. When the Enroll Cluster with the Microsoft Federation Gateway wizard appears, verify that the SSL certificate is the correct certificate that proves domain ownership for enrolling with the Microsoft Federation Gateway. If it is not, click Browse to select the correct certificate. For information about which certificate to select, see Important considerations for installing AD RMS with Microsoft Federation Gateway Support.

  6. Click Next, and then click Finish.

  7. On all servers in the AD RMS cluster, perform the task described in Grant the AD RMS Service Group Permission to the SSL Certificate.

  8. Perform the following tasks, as needed:

    • Set the Microsoft Federation Gateway RAC Validity Period

    • Manage the Microsoft Federation Gateway Licensing Filter List

    • Manage the Microsoft Federation Gateway Publishing Filter List

  9. In the Actions pane, click Enable Microsoft Federation Gateway Support.
Important

If the certificate you select in step 5 contains a subject alternate name (SAN), the last entry in the SAN list must be the fully qualified domain name of the domain you want to enroll with the Microsoft Federation Gateway.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Installing Microsoft Federation Gateway Support

  • Checklist: Deploying AD RMS with Microsoft Federation Gateway Support


Configuring an AD RMS Cluster

The procedures in this section are designed to help you configure Active Directory Rights Management Services (AD RMS) in your organization.

This section contains the following procedures:

  • Administering Certificates

  • Enabling Exclusion Policies

  • Establishing Trust Policies

  • Managing the AD RMS Databases

  • Configuring Accounts

  • Configuring Rights Policy Templates

  • Configuring AD RMS Across Forests


Administering Certificates

The procedures in this section are designed to help you manage rights account certificates (RACs) and server licensor certificates (SLC) in your AD RMS environment.

This section contains the following procedures:

  • Understanding AD RMS Certificates

  • Export the Server Licensor Certificate

  • Specify the Rights Account Certificate Validity Duration

  • Enable Certification of Mobile Devices

  • Enable Certification of Server Services

  • Authenticate Clients Using Smart Cards


Understanding AD RMS Certificates

The different components of Active Directory Rights Management Services (AD RMS) have trusted connections that are implemented by a set of certificates. Enforcing the validity of these certificates is a core function of AD RMS technology. Each piece of rights-protected content is published with a license that expresses its usage rules, and each consumer of that content receives a unique license that reads, interprets, and enforces those usage rules. In this context, a license is a particular type of certificate.

AD RMS uses an XML vocabulary to express usage rights for rights-protected content called eXtensible rights Markup Language (XrML).

The certificates and licenses used by AD RMS are connected in a hierarchy, so that the AD RMS client can always follow a chain from a particular certificate or license through trusted certificates, up to a trusted key pair.

The following table lists the certificates and licenses that are used by AD RMS:

Certificate or License Purpose Content

Server licensor certificate (SLC)

The SLC is created when the AD RMS server role is installed and configured on the first server in the cluster. It generates a unique SLC for itself that establishes its identity, called self-enrollment, and has a validity time of 250 years. This enables the archiving of rights-protected data for an extended period of time. A root cluster handles both certification, by issuing a rights account certificate (RAC), and licensing rights-protected content. Other servers added to the root cluster share an SLC. In complex environments, licensing-only clusters can be deployed, which generate their own SLC.

The SLC contains the public key of the server.

Client licensor certificate (CLC)

The CLC is created by the AD RMS cluster in response to a request from the client application. The CLC is sent to the client while it is connected to the organization's network and grants the user the right to publish rights-protected content when the client is not connected. The CLC is tied to the RAC of the user, so that if the RAC is not valid or not present, the user is not able to access the AD RMS cluster.

The CLC contains the client licensor public key, along with the client licensor private key that is encrypted by the public key of the user who requested the certificate. It also contains the public key of the cluster that issued the certificate, which is signed by the private key of the cluster that issued the certificate. The client licensor private key is used to sign publishing licenses.

Machine certificate

The machine certificate is created on the client computer the first time that an AD RMS-enabled application is used. The AD RMS client in Windows Vista and Windows 7 automatically activates and enrolls with the root cluster to create this certificate on the client computer. This certificate identifies a lockbox on a computer or device that is correlated with the logged-on user profile.

The machine certificate contains the public key of the activated computer. The corresponding private key is contained by that computer's lockbox.

Rights account certificate (RAC)

The RAC established a user's identity in the AD RMS system. It is created by the AD RMS root cluster and provided to the user when first attempting to open rights-protected content.

A standard RAC identifies a user by account credentials in the context of a specific computer or device and has a validity time measured in number of days. The default validity time for a standard RAC is 365 days.

A temporary RAC identifies a user based on account credentials only and has a validity time measured in number of minutes. The default validity time for a temporary RAC is 15 minutes.

The RAC contains the public key of the user and the private key of the user encrypted with the public key of the activated computer.

Publishing license

The publishing license is created by the client when content is saved with rights-protection. It specifies the users that can open the rights-protected content, under which conditions the content may be opened by the user, and the rights that each user will have to the rights-protected content.

The publishing license contains the symmetric content key for decrypting the content, which is encrypted with the public key of the server that issued the license.

Use license

The use license specifies the rights that apply to the rights-protected content in the context of a specific authenticated user. This license is tied to the RAC. If the RAC is not valid or not present, the use license cannot be used to open the content.

The use license contains the symmetric content key for decrypting the content, which is encrypted with the public key of the user.

Additional references

  • Administering Certificates


Export the Server Licensor Certificate

Server licensor certificates (SLCs) are exported to be used in establishing trusted publishing domains and trusted user domains.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To export the server licensor certificate to a file

  1. Open the Active Directory Rights Management Services console.

  2. In the console tree, select the AD RMS cluster whose certificate you want to export.

  3. Right-click the cluster name, and then click Properties.

  4. On the Server Certificate tab, click Export Certificate.

  5. The Export Certificate As dialog box appears. We recommend that you modify the .bin file name to include the name of your server, such as AD RMS_Cluster1_LicensorCert.bin.

  6. Specify the location where the SLC certificate should be saved, and then click Save.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Understanding AD RMS Certificates

  • Administering Certificates


Specify the Rights Account Certificate Validity Duration

You can specify the validity periods for both standard and temporary rights account certificates (RACs). By default, a standard RAC is valid for 365 days and a temporary RAC is valid for 15 minutes. After the end of these periods, users must acquire new certificates when they attempt to acquire publishing or use licenses. The manner in which the RAC is renewed depends on the AD RMS-enabled application. In some cases, it might be transparent; in others, the user might need to actively submit a request.

Note

If you are using Active Directory Federation Services (AD FS) with AD RMS, the rights account certificate validity duration is specified in Federated Identity Support. For more information, see Configure Federated Identity Support Settings.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To specify the Rights Account Certificate Validity Duration for standard certificates

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, select Rights Account Certificate Policies, and then click Change standard RAC validity period.

  3. On the Standard RAC tab, in Standard RAC validity period, type the number of days that standard RACs are to be valid, and then click OK.

To specify the Rights Account Certificate Validity Duration for temporary certificates

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, select Rights Account Certificate Policies and then click Change temporary RAC validity period.

  3. On the Temporary RAC tab, in Temporary RAC validity period, type the number of minutes that temporary RACs are to be valid, and then click OK.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Understanding AD RMS Certificates

  • Administering Certificates

  • Configure Federated Identity Support Settings


Enable Certification of Mobile Devices

AD RMS can provide rights account certificates (RACs) and use licenses to AD RMS-enabled applications that are running Windows Mobile 6. There are a few things that you should be aware of when configuring mobile services:

  • Discretionary access control lists (DACLs) on the AD RMS pipelines use the most secure settings by default. You must modify the DACL when using AD RMS mobile services.

  • Many mobile services use advanced Active Directory Domain Services (AD DS) functionality that is available only if all AD DS domain controllers are running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2. If you are using any mobile services, we recommend that all domain controllers are running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2, and that both the domain and forest Active Directory functional levels are at least at Windows Server 2003.

In a default AD RMS installation, the DACL of the AD RMS mobile certification pipeline is restricted, which means an application cannot obtain certificates and licenses for their users. However, if you have an AD RMS-enabled application for these computers, you can enable them to participate in your AD RMS system by configuring the DACLs on the AD RMS mobile certification pipeline.

AD RMS-enabled mobile applications can connect to the AD RMS mobile certification server by using the MobileDeviceCertification.asmx file.

Note

If there is more than one AD RMS server in the AD RMS cluster, the DACL on the mobile certification service must be changed on each server in the cluster.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To enable certification of mobile devices

  1. Open Windows Explorer and navigate to the folder where Internet Information Services was installed. By default, the folder path is %systemdrive%\Inetpub\wwwroot\_wmcs\Certification folder.

  2. To enable mobile devices to receive RACs, right-click the MobileDeviceCertification.asmx file, and then click Properties.

  3. On the Security tab, click Add, and then add the user account object of the AD RMS-enabled mobile application and the AD RMS Service Group.

  4. In the Permissions list for the groups, select the Allow check box for both Read and Read & Execute permissions, and then click OK.

    Note

    If several servers are hosting AD RMS-enabled mobile applications, consider creating a group, adding all of the user objects to this group, and then adding the group to the ACL of the certification pipeline instead.

  5. Restart Internet Information Services by running IISRESET at a command prompt to implement the changes on the DACLs on the Web services. Do this on each server in the AD RMS cluster.

Additional reference

  • Administering Certificates


Enable Certification of Server Services

Server services in AD RMS allows for AD RMS-enabled server applications to request rights account certificates (RACs) on behalf of other users. An example of an AD RMS-enabled server application is Microsoft Exchange Server 2007. There are a few things that you should be aware of when configuring server services:

  • Discretionary Access Control Lists (DACLs) on the AD RMS pipelines use the most secure settings by default. You must modify the DACL when using AD RMS server services.

  • If the AD RMS client is installed on a Windows Server 2003-based, Windows Server 2008, or Windows Server 2008 R2-based server and Internet Explorer Enhanced Security Configuration is enabled, you must add the AD RMS cluster URL to the Local Intranet security zone in Internet Explorer.

  • Many server services use advanced Active Directory Domain Services (AD DS) functionality that is only available if all AD DS domain controllers are running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2. If you are using any server services, we recommend that all domain controllers are running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2, and that both the domain and forest AD DS functional levels are at least Windows Server 2003.

In a default AD RMS installation, the DACL of the AD RMS server certification pipeline is restricted, which means an application cannot obtain certificates and licenses for their users. However, if you have an AD RMS-enabled application for these computers, you can enable them to participate in your AD RMS system by configuring the DACLs on the AD RMS server certification pipeline.

AD RMS-enabled server applications can connect to the AD RMS server certification service by using the ServerCertification.asmx file.

Note

If there is more than one AD RMS server in the AD RMS cluster, the DACL on the server certification service must be changed on each server in the cluster.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To enable certification of server services

  1. Open Windows Explorer and navigate to the folder where Internet Information Services was installed. By default, the folder path is %systemdrive%\Inetpub\wwwroot\_wmcs\Certification.

  2. To enable server services to receive RACs, right-click the ServerCertification.asmx file, and then click Properties.

  3. On the Security tab, click Add, and then add the computer account object of the AD RMS-enabled server application and the AD RMS Service Group.

  4. In the Permissions lists for the groups, select the Allow check box for both Read and Read & Execute permissions, and then click OK.

    Note

    If several servers are hosting AD RMS-enabled server applications, consider creating a group, adding all of the computer objects to this group, and then adding the group to the DACL of the certification pipeline instead.

  5. Restart Internet Information Services by running IISRESET at a command prompt to implement the changes to the DACLs on the AD RMS Web services.

Additional reference

  • Administering Certificates


Authenticate Clients Using Smart Cards

If you are using smart cards in your organization to provide additional security and control over user credentials, users can now use those smart cards with authentication credentials to obtain rights account certificates (RACs) and use licenses from servers in the AD RMS cluster.

Note

The steps in this procedure assume that a Secure Sockets Layer (SSL) certificate has already been installed. For more information about adding SSL, see Import an SSL Certificate Using Internet Information Services (IIS) Manager.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To add Client Certificate Mapping Authentication role service

  1. Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

  3. Expand Roles, and then click Web Server (IIS).

  4. In the results pane under Role Services, click Add Role Services.

  5. Select the Client Certificate Mapping Authentication check box, and then click Next.

  6. Click Install.

  7. When the role service is added, click Close.

Next, configure the authentication method in IIS:

To configure the authentication method in IIS

  1. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

  3. In the console tree, expand the server name.

  4. In the results pane of the server Home page, double-click Authentication to open the Authentication page.

  5. In the results pane of the Authentication page, right-click AD Client Certificate Authentication, and then click Enable.

  6. Close IIS Manager.

Finally, enable client authentication for the Web site that is hosting AD RMS:

To enable client authentication on a Web site hosting AD RMS

  1. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

  3. In the console tree, expand the server name.

  4. Expand Sites, and then expand the Web site that is hosting AD RMS. By default, the Web site name is Default Web site.

  5. In the console tree, expand _wmcs, right-click either the certification virtual directory (to support RACs or the licensing virtual directory (to support use licenses), and then click Switch to Content View.

  6. In the results pane of the Content View, right-click certification.asmx or license.asmx as appropriate, and then choose Switch to Features View.

  7. In the results pane on the Home page, double-click SSL Settings.

  8. Choose the appropriate Client certificates setting (Accept or Require). You should accept client certificates if you want clients to have the option to supply authentication credentials by using either a smart card certificate or a user name and password. You should require client certificates if you want only clients with client-side certificates such as smart cards to be able to connect to the service.

  9. Click Apply.

  10. If you want to use client authentication for both certification and licensing, repeat this procedure but select the alternate virtual directory the second time.

  11. Close IIS Manager.

  12. Repeat steps 1–10 for every server in the AD RMS cluster.

Next, you need to force the authentication method to use Client Certificate Mapping Authentication for the AD RMS cluster.

To force the client authentication method in the applicationhost.config file

  1. To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  2. Navigate to %windir%\system32\inetsrv\config.

  3. Type notepad applicationhost.config, and then press ENTER.

    Caution

    You should make a backup copy of this file before making changes.

  4. Go to the section similar to <location path="Default Web Site/_wmcs/certification/certification.asmx"> section of the applicationhost.config file.

    Note

    The location of the file above depends on the file or virtual directory that where you are trying to enforce client certificate mapping.

  5. If you want to allow smart card authentication in addition to Windows authentication, do the following:

    1. Change:

      <access sslFlags="Ssl, SslNegotiateCert, SslRequireCert, Ssl128" />

      To:

      <access sslFlags="Ssl, SslNegotiateCert, Ssl128" />

    2. Add a new line under <windowsAuthentication enabled="true" />, and then type:

      <clientCertificateMappingAuthentication enabled="true" />

  6. If you want to allow only smart card authentication, do the following. Ensure that SSL client authentication with Internet Information Services is required.

    1. Add a new line under <windowsAuthentication enabled="true" />, and then type:

      <clientCertificateMappingAuthentication enabled="true" />

    2. Change:

      <windowsAuthentication enabled="true" />

      To:

      <windowsAuthentication enabled="false" />

    3. Click File, click Save, and then close Notepad.

    4. In the command prompt window, type iisreset, and then press ENTER.

    Caution

    Running iisreset from a command prompt will restart the services associated with Internet Information Services.

  7. Repeat steps 1–5 for every server in the AD RMS cluster.

After these settings have been configured, a user who attempts to open rights-protected content published by this AD RMS cluster is prompted to provide authentication credentials before the cluster provides the user with a RAC or use license.

Additional references

  • Administering Certificates

  • Import an SSL Certificate Using Internet Information Services (IIS) Manager


Enabling Exclusion Policies

The procedures in this section are designed to help you define exclusion policies on your AD RMS cluster.

This section contains the following procedures:

  • Understanding AD RMS Exclusion Policies

  • Exclude Users

  • Exclude Applications

  • Exclude Lockbox Versions


Understanding AD RMS Exclusion Policies

You can implement exclusion policies to deny certain entities the ability to acquire certificate and license requests There are three ways to exclude these entities: by user, by application, and by lockbox version.

When an entity is excluded, use licenses that are created by servers in the AD RMS cluster will have that entity specified in the exclusion list. If, after a period of time, you decide to remove an entity that you have previously included in an exclusion policy, you can delete the entity from the exclusion list. Any new certification or licensing requests will not consider this entity as excluded.

We recommend that you do not remove an entity from an exclusion policy until you can be sure that all of the certificates issued before the exclusion policy was created have expired. Otherwise, both the old certificates and the new certificates will allow the content to be decrypted, which might not be what your organization wants.

Additional reference

  • Enabling Exclusion Policies


Exclude Users

You can exclude a user account from obtaining use licenses from an Active Directory Rights Management Services (AD RMS) cluster by specifying either the user's e-mail address or the public key string of the rights account certificate (RAC) associated with the user's RAC.

Users who are not allowed to consume rights-protected content but have e-mail accounts in your Active Directory Domain Services (AD DS) forest should be excluded by their e-mail addresses.

If a user is trusted but his or her AD RMS credentials are compromised, you can exclude only the compromised RAC by excluding its public key. When you do this, AD RMS denies new use license requests that involve that RAC. After you exclude a RAC, the next time that user attempts to acquire a use license for new content, the request will be denied. To acquire a use license, the user will have to retrieve a new RAC with a new key pair.

If you need to exclude external users, such as Windows Live ID users, federated users, and users identified by a trusted user domain, who are not part of your AD DS forest, you can also specify a RAC to exclude their public keys.

If you add a user to the exclusion list of the AD RMS root cluster, you should also exclude the user on all licensing-only clusters in your organization. Each AD RMS cluster has independent exclusion lists.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To exclude a user

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, expand Exclusion Policies and then click Users.

  3. In the Actions pane, click Enable User Exclusion.

  4. In the Actions pane, click Exclude user. The Exclude User Account wizard appears.

  5. Do one of the following:

    • To exclude a user by e-mail address, click the Use this option for excluding rights account certificates of internal users who have an Active Directory Domain Services account option, and then click Browse to browse to a user or group in your Active Directory Domain Services directory or type the e-mail address of the user to be excluded.

    • To exclude a user by the public key assigned to the user's rights account certificate, click the Use this option for excluding rights account certificates of external users who do not have an Active Directory Domain Services account option, and then type the appropriate rights account certificate public key string in the Public key string box.

  6. Click Finish.
To stop excluding users

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, expand Exclusion Policies, and then click Users.

  3. Do one of the following:

    • To disable user exclusion for all user accounts. In the Actions pane, click Disable User Exclusion. All user accounts previously excluded will be able to acquire AD RMS use licenses.

    • To stop excluding a specific user account. In the results pane, select the excluded user certificate.

  4. In the Actions pane, click Delete, and then click Yes to confirm the removal.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Enabling Exclusion Policies


Exclude Applications

You can specify the version of an AD RMS-enabled application that all licensing requests are checked against. Application exclusion stamps every use license with a condition that the license can bind only to the rights-protected content for which it is issued if the application that is requesting the license is not on the excluded list.

This can be useful, for example, when an enterprise deploys an update for an AD RMS-enabled application. System administrators can use their usual mechanism to cause client computers to install the update. They can then set application exclusion policies that are defined by using the version information of the application. This exclusion policy restricts AD RMS from issuing licenses to clients that are running previous versions of the software.

As with other types of exclusion, you must configure application exclusion on each cluster for which you want it to take effect.

When you apply this exclusion policy on your cluster, clients cannot use the excluded application to request and bind new use licenses to rights-protected content. However, clients can continue to use the excluded application to consume previously licensed files.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To exclude applications

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, expand Exclusion Policies, and then click Applications.

  3. In the Actions pane, click Enable Application Exclusion.

  4. In the Actions pane, click Exclude Application. The Exclude Application wizard appears.

  5. In Application file name, type the file name and file name extension (such as example.exe) of the application or component to be excluded.

  6. In Minimum version, type the minimum version number (in the format x.x.x.x) of the application that is not allowed to decrypt rights-protected content.

  7. In Maximum version, type the maximum version (in the format x.x.x.x) of the application that is not allowed to decrypt rights-protected content.

  8. Click Finish.

    Note

    AD RMS requires the application version to be specified in a 4-digit period-delimited format (#.#.#.# ). However, some applications specify their application version with 2-digit or 3-digit period-delimited numbers. In this case, you should append a .0 as appropriate to make the version number match the format required by AD RMS.
To stop excluding applications

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, expand Exclusion Policies, and then click Applications.

  3. Do one of the following:

    • To disable all application exclusions, in the Actions pane, click Disable Application Exclusion.

    • To disable a specific application exclusion, in the results pane, select the excluded application.

  4. In the Actions pane, click Delete, and then click Yes to confirm the removal.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Enabling Exclusion Policies


Exclude Lockbox Versions

Lockboxes are used to store a user's private key. If a vulnerability is found in a certain version of a lockbox, a new lockbox is released by Microsoft. You can ensure that clients use a minimum version of the Active Directory Rights Management Services (AD RMS) client software by using the lockbox version associated with the client to exclude the previous versions of the AD RMS client software. When you enable this feature, you specify the latest minimum lockbox version that was signed by the Microsoft Activation Service. You then enable lockbox exclusion on the each AD RMS cluster on which you want it to take effect. All certification and licensing requests are checked to make sure that the lockbox meets the minimum version criteria.

If you have enabled an exclusion based on lockbox version, clients that are using a version of the lockbox software earlier than the specified version cannot acquire rights account certificates (RACs) or use licenses because their requests will be denied. These clients must install a new version of the AD RMS client software to acquire a new lockbox that uses the current version of the software.

If a user who has an excluded lockbox was previously issued licenses for content, the user can still consume that content without acquiring a new lockbox.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To exclude lockbox versions

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, expand Exclusion Policies, and then select Lockbox.

  3. Click Enable Lockbox Exclusion to exclude lockbox versions.

  4. Click Change minimum lockbox version. The Lockbox properties sheet opens.

  5. Click View the recommended minimum lockbox version to connect to the Internet and view the minimum lockbox version that is signed by the Microsoft Activation Service. If you do not have an Internet connection on the AD RMS server, you can go directly to the Windows AD RMS Activation Service Web site (http://go.microsoft.com/fwlink/?LinkID=12995) and view the minimum lockbox version.

  6. On the Minimum RM lockbox version page that appears, copy the version number, and then close your Web browser.

  7. In the Minimum lockbox version box, paste the version number, and then click OK.
To stop excluding lockbox versions

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, expand Exclusion Policies, and then select Lockbox.

  3. Click Disable Lockbox Exclusion to stop excluding lockbox versions.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Enabling Exclusion Policies


Establishing Trust Policies

The procedures in this section are designed to help you establish a trust relationship between your AD RMS cluster and an AD RMS cluster in another domain or that is part of a different organization.

This section contains the following procedures:

  • Understanding AD RMS Trust Policies

  • Understanding the Microsoft Federation Gateway

  • Configure Federated Identity Support Settings

  • Add a Trusted User Domain

  • Export a Trusted User Domain

  • Add a Trusted Publishing Domain

  • Export a Trusted Publishing Domain

  • Use Windows Live ID to Establish RACs for Users

  • Configuring Microsoft Federation Gateway Support


Understanding AD RMS Trust Policies

You can add trust policies so that AD RMS can process licensing requests for content that was rights-protected by a different AD RMS cluster. You can define trust policies as follows:

  • Trusted user domains. The addition of a trusted user domain allows the AD RMS root cluster to process requests for client licensor certificates or use licenses from users whose rights account certificates (RACs) were issued by a different AD RMS root cluster. You add a trusted user domain by importing the server licensor certificate of the AD RMS cluster to trust.

  • Trusted publishing domains. The addition of a trusted publishing domain allows one AD RMS cluster to issue use licenses against publishing licenses that were issued by a different AD RMS cluster. You add a trusted publishing domain by importing the server licensor certificate and private key of the server to trust.

  • Windows Live ID. Setting up a trust with Microsoft’s online RMS service allows an AD RMS user to send rights-protected content to a user with a Windows Live ID. The Windows Live ID user will be able to consume rights-protected content from the AD RMS cluster that has trusted Microsoft’s online RMS service, but the Windows Live ID user will not be able to create content that is rights-protected by the AD RMS cluster.

  • Federated trust. Establishing a federated trust between two forests is done by using Active Directory Federation Services. This is useful if one forest does not have AD RMS installed, but its users need to consume rights-protected content from another forest. For more information about setting up federation support in AD RMS, see Configure Federated Identity Support Settings.

  • Microsoft Federation Gateway. Establishing a trust through the Microsoft Federation Gateway enables an AD RMS cluster to accept certification and licensing requests from external organizations by accepting claims-based authentication tokens from the Microsoft Federation Gateway. In effect, the Microsoft Federation Gateway acts as a trusted broker between the two organizations by verifying the identity of the two organizations in the transaction. Unlike a federated trust, establishing a trust relationship through Microsoft Federation Gateway does not require a forest in one organization to explicitly federate with a forest in the other organization. Instead, you can use filter lists to determine which domains can receive certificates or licenses from the AD RMS cluster.

    For example, Microsoft© Exchange Server 2010 is designed to take advantage of this capability by enabling messages protected by AD RMS to be sent between organizations that do not share an Active Directory Domain Services infrastructure. Exchange Server 2010 incorporates a number of features to support secure messaging by using AD RMS. These features include the following that rely on the Microsoft Federation Gateway:

    • The ability to send AD RMS–protected e-mail messages to a recipient in an organization outside the sender’s organization. The recipient can then access the message by using Exchange Server 2010 Outlook Web Access (OWA) or by using Microsoft Outlook.

    • The ability of a sender to grant a recipient organization that uses Exchange Server 2010 permission to decrypt content for such purposes as journaling and malware scanning.

    Because these features require the ability of two organizations to establish a trust relationship, Microsoft Federation Gateway Support plays a crucial role in their deployment.

Additional references

  • Establishing Trust Policies

  • Configure Federated Identity Support Settings

  • Configuring Microsoft Federation Gateway Support


Understanding the Microsoft Federation Gateway

The Microsoft Federation Gateway is an identity service that runs over the Internet and mediates between an organization or business and the external services that the organization wants to use. The gateway acts as a hub for many of the connections the organization wants to make with applications built on Windows Azure or to a Microsoft application that is running on the Internet. The gateway connects users and other identities to the services that it works with, so that an organization only has to manage a single identity-federation relationship to enable its identities to access all Microsoft and Microsoft-based services they want to use.

The Microsoft Federation Gateway provides applications with a simple, standards-based method of establishing trust between separate organizations that uses SSL certificates to prove domain ownership. Because the organizations federate with the gateway instead of with each other, it is much easier for an organization to establish trust relationships with multiple partners than is possible when it uses conventional one-on-one federation or other trust relationships. The scope of the federation can be easily controlled by creating allow or deny lists of users and domains for licensing and by specifying the domains that can receive publishing licenses. This guarantees that that only appropriate organizations are given access to protected information.

A federated-identity relationship is a standards-based arrangement between organizations in which claims from one organization are passed to and recognized by another. Through this relationship, users can sign in to and be authenticated by their identity provider—the organization that manages their identity account—and then have their authentication passed to a federated partner without being required to sign in again.

The Microsoft Federation Gateway establishes federated-identity relationships by building on the Web service (WS-*) specifications such as WS-Trust and WS-Security that work together to simplify interoperability and improve security. By using these industry-standard protocols, organizations can establish a federated-identity relationship without requiring them to use identical platforms or infrastructure.

When two organizations establish a federated-identity relationship, one partner (the identity provider) controls its own user accounts while the other partner (the resource provider) grants access to its resources by relying on the authentication performed by the identity provider. A user’s identity is defined as a set of claims, that is, statements that a server makes about a user. Examples of such claims are the user’s name, groups, or permissions. Identity federation enables the sharing of these identity claims.

With the Microsoft Federation Gateway, authentication from the identity provider is supplied to the gateway by using a standard format called Security Assertion Markup Language (SAML). The Microsoft Federation Gateway then converts the authentication information into a service token that can be used by Microsoft services.

Microsoft Federation Gateway Support in Windows Server® 2008 R2 enables AD RMS to accept tokens from the Microsoft Federation Gateway to authenticate users for certification and licensing. For example, Microsoft Exchange Server 2010 is designed to take advantage of this capability by enabling messages protected by AD RMS to be sent between organizations that do not share an Active Directory Domain Services (AD DS) infrastructure. When the Exchange Server 2010 infrastructure is configured to take advantage of these features, users can send AD RMS–protected e-mail messages to recipients outside the sender’s organization who can than view the messages by using Exchange Server 2010 Outlook Web App or Microsoft Outlook. Also, senders can grant permission recipient organizations that use Exchange Server 2010 permission to decrypt content for such purposes as journaling and malware scanning.

For more information about how to deploy Microsoft Federation Gateway Support on AD RMS, see Checklist: Deploying AD RMS with Microsoft Federation Gateway Support.

Additional references

  • Establishing Trust Policies


Configure Federated Identity Support Settings

Once enabled, Federated Identity Support allows user accounts to use credentials established by a federated trust relationship through Active Directory Federation Services (AD FS) as a basis for obtaining a rights account certificate (RAC) from an AD RMS cluster. This is an alternative to setting up trusted publishing domains or trusted user domains between entities that have previously established trust infrastructures, such that in most cases the cluster is supporting both users that are inside of the organization and users from a partner organization.

When rights account certificates (RACs) are issued from a federated identity, the standard rights account certificate validity period does not apply. Instead, the RAC validity period is specified in the Federated Identity Support setting. Users with federated identities do not use temporary rights account certificates.

By default, federated trust relationships are not transitive. When a federated trust relationship is established between two organizations, any AD RMS trusted user domains that are established in either organization are not automatically trusted by the other organization. However, when you are importing a Trusted User Domain, there is an option to trust federated users of the imported domain.

Great care should be taken when allowing proxy addresses through a federated trust. If you allow proxy addresses through federation, it is possible for a malicious user to spoof an authorized user's credentials and access the user's rights-protected content. If proxy addresses through federation is a requirement of your organization, you should implement a claims transformation module that will examine a proxy address from a federated user and make sure that it matches the forest in which the request originated. The option to allow a proxy address from a federated user is turned off by default in the Active Directory Rights Management Services console.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To enable and configure federated identity support settings

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, expand Trust Policies, and then click Federated Identity Support.

  3. In the Actions pane, click Enable Federated Identity Support to enable Federated Identity Support.

  4. In the Actions pane, click Properties.

  5. On the Active Directory Federation Service Policies tab, in Federated Identity Certificate validity period, type the number of days that federated rights account certificates are to be valid.

  6. In Federated Identity Certificate Service URL, provide the location of the root cluster that will provide RACs to external users. If the default is selected, users will attempt to obtain a RAC from the AD RMS cluster that published the content.

  7. Click OK.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Establishing Trust Policies

  • Configuring AD RMS Across Forests


Add a Trusted User Domain

By default, Active Directory Rights Management Services (AD RMS) does not service requests from users whose rights account certificate (RAC) was issued by a different AD RMS installation. However, you can add user domains to the list of trusted user domains (TUDs), which allows AD RMS to process such requests.

For each trusted user domain (TUD), you can also add and remove specific users or groups of users. In addition, you can remove a TUD; however, you cannot remove the root cluster for this Active Directory forest from the list of TUDs. Every AD RMS server trusts the root cluster in its own forest.

You can add TUDs as follows:

  • To support external users in general, you can trust Windows Live ID. This allows an AD RMS cluster that is in your company to process licensing requests that include a RAC that was issued by Microsoft’s online RMS service. For more information about trusting Windows Live ID in your organization, see Use Windows Live ID to Establish RACs for Users.

  • To trust external users from another organization’s AD RMS installation, you can add the organization to the list of TUDs. This allows an AD RMS cluster to process a licensing request that includes a RAC that was issued by an AD RMS server that is in the other organization.

  • In the same manner, to process licensing requests from users within your own organization who reside in a different Active Directory forest, you can add the AD RMS installation in that forest to the list of TUDs. This allows an AD RMS cluster in the current forest to process a licensing request that includes a RAC that was issued by an AD RMS cluster in the other forest.

  • For each TUD, you can specify which e-mail domains are trusted. For trusted Windows Live ID sites and services, you can specify which e-mail users or domains are not trusted.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To add a trusted user domain

  1. The TUD of the AD RMS installation to be trusted should already be exported and available. For more information about exporting a TUD, see Export a Trusted User Domain.

  2. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  3. In the console tree, expand Trust policies, and then click Trusted User Domains.

  4. In the Actions pane, click Import Trusted User Domain.

  5. In the Trusted user domain file box, type the path to the exported server licensor certificate of the user domain to trust or click Browse to locate it.

  6. In Display name, type a name to identify this trusted user domain. If you would like to extend this trust to federated users, select Extend trust to federated users of the imported server.

  7. Click Finish.
Note

The private key information is not transferred when you set up a TUD.

The name of the domain appears in the Trusted user domains list in the results pane. To further configure e-mail domains within that trusted user domain, do the following steps:

To specify properties of the trusted user domain

  1. If the trusted user domain is based on another AD RMS cluster's server licensor certificate, you can specify which e-mail domains within the trusted user domain are trusted.

  2. Select the certificate name in the results pane and then in the Actions pane, click Properties.

  3. Click the Trusted E-mail Domains tab, and then 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.

    • 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. Adding a domain includes all of its child domains.

  4. Select the Trust AD RMS licensing to security identifiers (SIDs) for this user domain check box, if necessary.

  5. When finished, click OK.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Export a Trusted User Domain

  • Establishing Trust Policies

  • Use Windows Live ID to Establish RACs for Users


Export a Trusted User Domain

Trusted user domains (TUDs) enable an AD RMS cluster to provide licenses to users whose rights account certificate (RAC) was granted by another server in a AD RMS cluster. Exporting a TUD and importing it into another AD RMS cluster allows the cluster to process requests for use licenses from users whose rights account certificates (RACs) are in a different cluster.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To export a trusted user domain

  1. Open the Active Directory Rights Management Services console, and then expand the AD RMS cluster.

  2. In the console tree, expand Trust Policies and then click Trusted User Domains.

  3. In the Actions pane, click Export Trusted User Domain.

  4. The Save As dialog box appears. We recommend that you modify the .bin file name to include the name of your server, such as ADRMS_Cluster1_LicensorCert.bin.

  5. Click Save to save the file with the name and location you specified.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Add a Trusted User Domain

  • Establishing Trust Policies


Add a Trusted Publishing Domain

By default, servers in an Active Directory Rights Management Services (AD RMS) cluster can issue use licenses only against the publishing licenses that it, or another server in its cluster, issued. If you have content that was published by using another AD RMS root cluster either in your organization, for example a subsidiary organization in another forest, or in another separate organization, your AD RMS cluster can grant use licenses to users for this content if you configure a trusted publishing domain (TPD). By adding a trusted publishing domain, you set up a trust relationship between your AD RMS cluster and the other root cluster by importing the server licensor certificate (SLC) of the other cluster. There is no limit to the number of TPDs that you can configure for your AD RMS cluster.

If the cluster key is stored in a CSP, you must transfer the cluster key to the CSP key container on each trusted server in the cluster by following the instructions in the CSP manufacturer's documentation. Depending on the type of CSP on each server and the configuration of any hardware security module devices, you might not be able to transfer the cluster key from one hardware security module to another. If you are using a CSP with a hardware security module, review the hardware security module documentation to determine whether you can transfer the cluster key without losing data that is in the destination hardware security module. If you cannot successfully transfer the cluster key, you cannot establish a trusted publishing domain.

Note

If you are using a hardware-based CSP, also known as a hardware security module (HSM), to protect your AD RMS cluster key and you are importing an SLC from an AD RMS installation that internally manages the AD RMS cluster key, you must specify a cluster key password on the Security Policies settings of the cluster before you attempt to import the certificate.

This procedure assumes that you have exported the TPD of another AD RMS cluster. For more information about exporting the TPD, see Export a Trusted Publishing Domain.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To add a trusted publishing domain

  1. Open the Active Directory Rights Management Services console, and then expand the AD RMS cluster.

  2. In the console tree, expand Trust Policies, and then click Trusted Publishing Domains.

  3. In the Actions pane, click Import Trusted Publishing Domain.

  4. In Trusted Publishing Domain file, type the path to the trusted publishing domain file or click Browse to locate it.

    This file contains the licensor certificate, private key (if the key is stored in software), and rights policy templates. This file is encrypted.

  5. In Password, type the password required to decrypt this file.

  6. In Display name, type a name to identify this trusted user domain.

    Click Finish.
Note

You can remove a TPD at any time by removing its certificate from the list of certificates for TPDs under the Trust Polices node in the Active Directory Rights Management Services console.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Export a Trusted Publishing Domain

  • Reset the AD RMS Cluster Key Password

  • Establishing Trust Policies


Export a Trusted Publishing Domain

Use the following procedure to export a trusted publishing domain (TPD) to a file.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To export a trusted publishing domain

  1. Open the Active Directory Rights Management Services console, and then expand the AD RMS cluster.

  2. In the console tree, expand Trust Policies and then click Trusted Publishing Domains.

  3. In the results pane, select the certificate for the domain you want to export.

  4. In the Actions pane, click Export Trusted Publishing Domain.

  5. In the Publishing domain file box, type the name of the publishing domain file you are exporting or click Save As to export it to a special location. Make sure you specify the .xml file name extension.

  6. In the Password and Confirm password boxes, type a strong password that will be used to encrypt the trusted publishing domain file. You need this password to import this file into another AD RMS cluster.

  7. If this trusted publishing domain file will be imported into versions of Rights Management Services (RMS), click the Saved as V1 compatible trusted publishing domain file check box.

  8. Click Finish to create the trusted publishing domain file.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Add a Trusted Publishing Domain

  • Understanding AD RMS Trust Policies

  • Establishing Trust Policies


Use Windows Live ID to Establish RACs for Users

Microsoft provides an account certification service that uses Windows Live ID to establish the rights account certificate (RAC) for the user. If you want users with RACs from that service to be able to obtain use licenses from your Active Directory Rights Management Services (AD RMS) cluster, you need to set up a trusted user domain that accepts user credentials from Microsoft’s online RMS service.

To use this feature you must configure Internet Information Services (IIS) to allow access to the AD RMS licensing service, for example, by allowing anonymous access. This step is essential because the licensing service is configured to use Windows Integrated authentication by default. If IIS is not configured to allow access to the AD RMS licensing service, users with Windows Live ID-based RACs will not be able to acquire licenses.

If necessary, after they are configured, you can filter (allow or block) users of this service based on their e-mail addresses.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To enable anonymous access to the AD RMS licensing service

  1. Log on to a server in the AD RMS cluster.

  2. Open the Internet Information Services (IIS) Manager console and expand the server that is hosting AD RMS.

  3. In the console tree, expand Web sites and then expand the Web site on which you have configured AD RMS. By default this is the Default Web site.

  4. In the console tree, expand the _wmcs Web site and then select the licensing virtual directory.

  5. In the results pane, double-click Authentication to open the Authentication page.

  6. Select Anonymous Authentication and then, under Tasks, select the Enabled checkbox and then click Save.

  7. Repeat steps 1-6 for each server in the AD RMS cluster.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To trust Windows Live ID-based rights account certificates

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  3. In the console tree, expand Trust Policies, and then click Trusted User Domains.

  4. In the Actions pane, click Trust Windows Live ID. The Windows Live ID certificate appears in the Trusted user domain list in the results pane.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To specify Windows Live ID e-mail users and domains to allow or block

  1. Log on to a server in the AD RMS cluster.

  2. Open the AD RMS snap-in and expand the AD RMS cluster.

  3. In the console tree, expand Trust Policies, and then click Trusted User Domains.

  4. Select the Windows Live ID certificate in the results pane, and then in the Actions pane, click Properties.

  5. Click the Filtered Windows Live IDs tab.

  6. Do one of the following:

    • To create a list of users and domains that will be allowed to receive licenses, click Allow.

    • To create a list of users and domains that will be blocked from receiving licenses, click Block.

  7. Type the user e-mail address (in the form user@domain.com) or domain name (in the form domain.com) to be added to the filter list, and then click Add. You can also use an asterisk (*) to specify all users and domains.

  8. Repeat the previous step for all e-mail users and domains that should be allowed or blocked.

  9. Click OK to apply the filter list to the cluster.

Additional references

  • Establishing Trust Policies


Configuring Microsoft Federation Gateway Support

The procedures in this section are designed to help you configure Microsoft Federation Gateway Support on your Active Directory Rights Management Services (AD RMS) cluster.

This section contains the following procedures:

  • Update a Microsoft Federation Gateway Support Certificate

  • Grant the AD RMS Service Group Permission to the SSL Certificate

  • Set the Microsoft Federation Gateway RAC Validity Period

  • Manage the Microsoft Federation Gateway Licensing Filter List

  • Manage the Microsoft Federation Gateway Publishing Filter List

  • Terminate the Federation Relationship

  • Remove Microsoft Federation Gateway Support


Update a Microsoft Federation Gateway Support Certificate

You can update the token decryption certificate or the Microsoft Federation Gateway certificate, as needed. Because the token decryption certificate is the SSL certificate for the Active Directory Rights Management Services (AD RMS) cluster, you must update the token decryption certificate if the cluster SSL certificate expires. After you update the token decryption certificate, you must grant the AD RMS Services group permission to access the certificate on all servers in the AD RMS cluster.

Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To update the token decryption certificate

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services snap-in and expand the AD RMS cluster.

  3. Expand Trust Policies, and then click Microsoft Federation Gateway Support.

  4. In the pane, click Configure Microsoft Federation Gateway settings.

  5. In the Enroll Cluster with Microsoft Federation Gateway wizard, click Update Microsoft Federation Gateway Settings, select Update Token Decryption Certificate, and then click Browse.

  6. In the Select Certificate dialog box, select the SSL certificate of the AD RMS cluster, and then click Select. For information about which certificate to select, see Important considerations for installing AD RMS with Microsoft Federation Gateway Support.

  7. Click Next, and then click Finish.

  8. Perform the task described in Grant the AD RMS Service Group Permission to the SSL Certificate.

Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To update the Microsoft Federation Gateway certificate

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services snap-in and expand the AD RMS cluster.

  3. Expand Trust Policies, and then click Microsoft Federation Gateway Support.

  4. In the pane, click Configure Microsoft Federation Gateway settings.

  5. In the Enroll Cluster with Microsoft Federation Gateway wizard, click Update Microsoft Federation Gateway Settings, select Update Microsoft Federation Gateway Certificate, and then click Next.

  6. Click Finish.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Configuring Microsoft Federation Gateway Support

  • Understanding AD RMS Trust Policies


Grant the AD RMS Service Group Permission to the SSL Certificate

After enrolling the cluster with the Microsoft Federation Gateway or updating the token decryption certificate, you must grant the AD RMS Services group permission to access the token decryption certificate on all servers in the cluster.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To grant permission to the AD RMS Services group for the SSL certificate

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  3. In the console tree, expand Trust Policies, and then click Microsoft Federation Gateway Support.

  4. In the Actions pane, click Grant permissions to token decryption certificate on this server.

    Note

    If this link is not present in the Actions pane, the necessary permission has already been granted on this server.

  5. Repeat steps 1-4 on all other servers in the cluster.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Installing Microsoft Federation Gateway Support

  • Update a Microsoft Federation Gateway Support Certificate

  • Checklist: Deploying AD RMS with Microsoft Federation Gateway Support


Set the Microsoft Federation Gateway RAC Validity Period

You can configure how long the Microsoft Federation Gateway rights account certificate (RAC) remains valid.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To set the Microsoft Federation Gateway RAC validity period

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services snap-in and expand the AD RMS cluster.

  3. Expand Trust Policies, and then click Microsoft Federation Gateway Support.

  4. In the results pane, click Manage Microsoft Federation Gateway Support.

  5. In the Microsoft Federation Gateway Support dialog box, in Microsoft Federation Gateway RAC validity period (days), select or type the number of days you want the RAC to remain valid, and then click OK.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Configuring Microsoft Federation Gateway Support

  • Understanding AD RMS Trust Policies

  • Understanding AD RMS Certificates


Manage the Microsoft Federation Gateway Licensing Filter List

You can control the federated domains that the Active Directory Rights Management Services (AD RMS) cluster will provide licenses to. You can do this either by specifying the users and domains that can receive licenses, or by specifying the users and domains that will be blocked from receiving licenses.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To allow or block domains for licensing

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services snap-in and expand the AD RMS cluster.

  3. Expand Trust Policies, and then click Microsoft Federation Gateway Support.

  4. In the results pane, click Manage Microsoft Federation Gateway Support.

  5. In the Microsoft Federation Gateway Support dialog box, click the Licensing Domains tab.

  6. Do one of the following:

    • Click Allow to specify which users and domains will be permitted receive licenses from the AD RMS cluster.

    • Click Block to specify which users and domains will not be permitted to receive licenses from the AD RMS cluster.

  7. To add a user or domain to the list, in the box type the user’s e-mail address in the form user@domain.com or domain name in the form domain.com, and then click Add. You can also use an asterisk (*) to specify all users and domains.

  8. To remove a user or domain from the list, select the user’s e-mail address or the domain, and then click Remove.

  9. Click OK.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Configuring Microsoft Federation Gateway Support

  • Understanding AD RMS Trust Policies


Manage the Microsoft Federation Gateway Publishing Filter List

You can control the federated domains that the Active Directory Rights Management Services (AD RMS) cluster will provide publishing licenses to.

Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To allow domains for publishing

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services snap-in and expand the AD RMS cluster.

  3. Expand Trust Policies, and then click Microsoft Federation Gateway Support.

  4. In the results pane, click Manage Microsoft Federation Gateway Support.

  5. In the Microsoft Federation Gateway Support dialog box, click the Publishing Domains tab.

  6. To add a domain to the list, in the box type the domain name, and then click Add. You can also use an asterisk (*) to specify all domains.

  7. To remove a domain from the list, select the domain, and then click Remove.

  8. Click OK.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Configuring Microsoft Federation Gateway Support

  • Understanding AD RMS Trust Policies


Terminate the Federation Relationship

When the Active Directory Rights Management Services (AD RMS) cluster is enrolled with the Microsoft Federation Gateway, you can stop the enrollment without disabling Microsoft Federation Gateway Support. You can enroll again with the Microsoft Federation Gateway later.

Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To terminate the federation relationship

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services snap-in and expand the AD RMS cluster.

  3. Expand Trust Policies, and then click Microsoft Federation Gateway Support.

  4. In the Actions pane, click Configure Microsoft Federation Gateway settings.

  5. In the Enroll Cluster with Microsoft Federation Gateway wizard, click Terminate Federation Relationship, and then verify that the SSL certificate is the correct certificate for enrolling with the Microsoft Federation Gateway. If it is not, click Browse to select the correct certificate.

  6. Click Next, and then click Finish.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Configuring Microsoft Federation Gateway Support

  • Understanding AD RMS Trust Policies


Remove Microsoft Federation Gateway Support

If you no longer want to use Microsoft Federation Gateway Support in Active Directory Rights Management Services (AD RMS), you can remove Microsoft Federation Gateway Support from your AD RMS cluster

Caution

Before uninstalling Service Pack 1 for Windows Server® 2008 R2, you must remove Microsoft Federation Gateway Support from the AD RMS cluster. Failure to do this may cause an inconsistent configuration of your AD RMS cluster.

Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To remove Microsoft Federation Gateway Support

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services snap-in console and expand the AD RMS cluster.

  3. In the Actions pane, click Configure Microsoft Federation Gateway settings.

  4. In the Enroll Cluster with Microsoft Federation Gateway wizard, click Terminate Federation Relationship, and then verify that the SSL certificate is the certificate that was used to enroll with the Microsoft Federation Gateway. If it is not, click Browse to select the correct certificate.

  5. Click Next, and then click Finish.

  6. In the tree, click Trust Policies, and then in the Action pane, click Remove Microsoft Federation Gateway Support.

  7. In the Microsoft Federation Gateway Support wizard, click Next, and then click Finish.

  8. Repeat steps 6 and 7 on all other servers in the AD RMS cluster before uninstalling Service Pack 1 for Windows Server 2008 R2 from those servers.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Configuring Microsoft Federation Gateway Support

  • Understanding AD RMS Trust Policies


Managing the AD RMS Databases

AD RMS events and messages can be logged to a database on your database server. This section describes the following operations:

  • Understanding the AD RMS Databases

  • Turn on or Turn off Logging

  • Monitor the AD RMS Message Queue


Understanding the AD RMS Databases

Servers in the AD RMS cluster are tightly integrated with the database server during normal operations. The AD RMS database server stores configuration, logging, and directory services information for use by AD RMS.

You can use the Windows Internal Database in Windows Server® 2008 R2 to support a new installation of AD RMS using a single server.

Caution

If you are using the MSDE 2000 or Microsoft SQL Server 2000 to host the Rights Management Services (RMS) databases, you cannot upgrade to AD RMS. An upgrade is only supported if you are using Microsoft SQL Server 2005 or Microsoft SQL Server 2008 to host the AD RMS databases.

We recommend that you use a separate database server such as Microsoft SQL Server 2005 or Microsoft SQL Server 2008. AD RMS uses the following databases:

  • Configuration database

    The configuration database is a critical component of an AD RMS installation because it stores, shares, and retrieves all configuration data and other data that you need to manage account certification, licensing, and publishing services for a cluster. The way that you manage your configuration database directly affects the security and availability of rights-protected content.

    Each AD RMS cluster has one configuration database. The configuration database for the root cluster contains a list of Windows user identities and their rights account certificate (RAC)s. If the cluster key is centrally managed by AD RMS, the certificate key pair is encrypted to the AD RMS cluster key before it is stored in the database. The configuration databases for licensing-only clusters do not contain this information.

  • Logging database

    For each root or licensing-only cluster, by default AD RMS installs a logging database in the same database server instance that hosts the configuration database. AD RMS also creates a private message queue on each server in the AD RMS cluster for logging in Message Queuing. The AD RMS logging service transmits data from this message queue to the logging database.

  • Directory services database

    This database contains information about users, identifiers (such as e-mail addresses), security ID (SID), group membership, and alternate identifiers. This information is obtained from Lightweight Directory Access Protocol (LDAP) queries made to the Active Directory Domain Services (AD DS) global catalog by the AD RMS licensing service.

The user account that was logged on when the AD RMS server role was added has Database Owner permissions on all of these databases.

Additional references

  • Managing the AD RMS Databases


Turn on or Turn off Logging

You can turn on and turn off logging for the current cluster from the Logging tab of the cluster properties sheet in the Active Directory Rights Management Services snap-in. Turning off logging stops the Active Directory Rights Management Services (AD RMS) Web services from sending data to the logging message queue.

AD RMS logs are sent to the database server by Message Queuing. If a connection to the database server is not present, Message Queuing stores the logs in a local cache until connectivity is restored. The first time you enable logging, you should make sure that the AD RMS server has a connection to the database server and that the database service is started. If Message Queuing cannot deliver the logs to the logging database, it keeps the data in a queue on the hard disk of the AD RMS server. It continues to do this until all of the storage space on the server is full. When there is no disk space is left on the server, Message Queuing will stop. AD RMS does not display an error in this condition, because the feature is meant to support logging during times when the connection to the database server is interrupted.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To turn on logging or turn off logging

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services console, and select the AD RMS cluster.

  3. Right-click the cluster name, and then click Properties.

  4. Click the Logging tab, and then do one of the following:

    • To turn logging on, select the Enable Logging check box.

    • To turn logging off, clear the Enable Logging check box.

  5. Click OK.

  6. Repeat steps 1-5 for each server in the AD RMS cluster.

If you are using Microsoft SQL Server as your database server, you can verify that the logs are being written to the database:

Membership in the local Administrators group and the System Administrators database role on the database server hosting the AD RMS configuration database, or equivalent, is the minimum required to complete this procedure.

To verify that the logs are being written to the database

  1. Log on to the database server hosting the AD RMS logging database.

  2. In SQL Server Enterprise Manager, expand Databases, and then expand the AD RMS logging database.

  3. Expand Tables, right-click ServiceRequest, and then click Open table - return all rows. If log files are being created, you will see one or more rows in this table.

Additional references

  • Managing the AD RMS Databases


Monitor the AD RMS Message Queue

AD RMS logging uses Message Queuing to send events to the logging database. Each server in the AD RMS cluster sends messages to its own message queue. The AD RMS logging service on each server retrieves logging messages from the Message Queuing queue and writes them to the logging database. If your logging database or database server becomes unavailable, or if the AD RMS logging service is stopped, Message Queuing stores the messages in the queue. If you are planning to shut down the logging database or database server temporarily, we recommend that you first stop the AD RMS logging service on every server in the cluster. When you are ready to restart the database server, restart the AD RMS logging service on every server in the AD RMS cluster.

In the default configuration, Message Queuing will store all queued messages up to the limit of the free storage space on the server. If Message Queuing uses all of the available hard disk space, the AD RMS server cannot service client requests.

Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To limit the amount of disk space used for message queuing

  1. Log on to a server in the AD RMS cluster.

  2. Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.

  3. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

  4. Expand Features, expand Message Queuing, and then click Private Queues.

  5. Right-click the AD RMS logging queue, click Properties, select the Limit message storage to (KB) check box, and then type the total size, in kilobytes, of all queue messages that can be stored in the queue.

  6. Click OK.

  7. Repeat steps 1–6 for all AD RMS servers in the cluster.

Additional references

  • Managing the AD RMS Databases

  • Turn on or Turn off Logging


Configuring Accounts

Accounts in AD RMS are used for the operation and maintenance of an AD RMS cluster.

This section describes the following procedures:

  • Understanding AD RMS User Accounts

  • Add Users to AD RMS Administrative Groups

  • Set up a Super Users Group

  • Reset the AD RMS Cluster Key Password

  • Change the AD RMS Service Account

  • Specify the Administrative Contact


Understanding AD RMS User Accounts

Active Directory Domain Services (AD DS) provides authentication for users of AD RMS. All of the user account requests received by the AD RMS cluster are recorded into the logging database if logging is enabled.

Deleting accounts from the configuration database

When you delete a user account from AD DS, the configuration database entry in the user key table for the user’s rights account certificate (RAC) is not automatically deleted. Because of this, the user key table can grow unbounded as new user keys are added, but old ones are not deleted.

There are two approaches that you can use to maintain the configuration database. First, you can create and run a stored procedure that deletes a user key identified by its security identifier (SID) when you remove the associated user account from AD DS.

Alternately, you can write a script that deletes user keys from the configuration database when their associated SIDs no longer exist in AD DS and run it periodically. Because this method creates a large load on both the database server and AD DS, you should schedule the running of your script during times of low activity.

Moving user accounts to another AD DS forest

When you set up and provision a root cluster in an organization, there can be only one root cluster for every Active Directory forest.

In general, when you move a user account from one domain to another domain in the same forest, a new SID is created for the user account in the new domain. Then, when a user attempts to acquire a new RAC from a server in the cluster, the user appears to be a new user because the SID is different. The cluster generates new keys for the user account and issues the new RAC by using the original e-mail address of the user. If the user attempts to use the new RAC with an existing use license, the SID and keys will not match. The user needs to acquire a new use license. This is also true for moving a user account to a domain that is in a different forest.

Additional references

  • Configuring Accounts


Add Users to AD RMS Administrative Groups

User accounts are added to the AD RMS administrative groups by using Server Manager.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To add users to AD RMS administrative groups

  1. Log on to a server in the AD RMS cluster.

  2. Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.

  3. Expand Configuration, expand Local Users and Groups, and then click Groups.

  4. Double-click the desired group, such as AD RMS Enterprise Administrators, AD RMS Auditors, or AD RMS Template Administrators.

  5. Click Add.

  6. In the Select Users, Computers, or Groups dialog box, type the user name of the account in the form user_name@domain_name, click OK, and then click OK again.

  7. Repeat steps 1-6 for each server in the AD RMS cluster.

To reduce administrative overhead, you can add a security group to the AD RMS administrative group in Active Directory Domain Services (AS DS) and add the user accounts to the AD DS group.

Additional reference

  • Configuring Accounts


Set up a Super Users Group

The AD RMS super user group is a special group that has full control over all rights-protected content managed by the cluster. Its members are granted full owner rights in all use licenses that are issued by the AD RMS cluster on which the super users group is configured. This means that members of this group can decrypt any rights-protected content file and remove rights-protection from it.

The super users group is not enabled and is not assigned a group by default. When you enable the Super Users setting in the Active Directory Rights Management Services console, you can specify an Active Directory Domain Services (AD DS) universal group to use as the super users group for AD RMS. The group must exist in the same forest as the AD RMS installation. Any user accounts that are members of the group that you specify as the AD RMS super users group are automatically granted the permissions of the super users group.

Caution

Enabling the super users group should be done only on an as-needed basis. During normal operations, the super users group should be disabled. It should be enabled only when it can be justified.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To set up a super users group

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, expand Security Policies, and then click Super Users.

  3. In the Actions pane, click Enable Super Users.

  4. In the results pane, click Change Super User Group to open the Super Users properties sheet.

  5. In the Super user group box, type the e-mail address of an existing group in the Active Directory forest, or click Browse to navigate through the defined users and groups in the directory.

  6. Click OK.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Configuring Accounts


Reset the AD RMS Cluster Key Password

When a new AD RMS cluster is provisioned, a method to protect the AD RMS cluster key is chosen. If you chose the default option of using AD RMS cluster key protection, you specified a strong password that was used to encrypt the cluster key in the configuration database. The AD RMS cluster key is used to sign the certificates and licenses granted by the cluster. The cluster key is generated and the password specified during the initial configuration of the AD RMS server role.

If you are running AD RMS in a clustered environment, and you decided to reset the cluster key, it must be completed on every AD RMS server in the cluster. If you do not, those servers will not be able function as they will be unable to decrypt the cluster key in the configuration database.

Important

This procedure applies only if you are using AD RMS to centrally manage the cluster key. If you are using either a hardware-based or software-based cryptographic service provider (CSP), consult the documentation of the CSP manufacturer.

Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To reset the cluster key password

  1. Log on to a server in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  3. In the console tree, expand Security Policies, and then click Change cluster key password.

  4. In the Cluster Key Password wizard, type the new password for the cluster key in the Password box.

  5. In the Confirm Password box, type the new password again.

  6. Click Apply to complete the password reset.

  7. Repeat steps 1–6 for each server in the AD RMS cluster.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Configuring Accounts


Change the AD RMS Service Account

During installation, Active Directory Rights Management Services (AD RMS) creates the AD RMS Service Group on the local computer and grants it appropriate permissions on all of the resources that are required for AD RMS to operate. When you provision AD RMS on a server, you must define a domain account for use as the AD RMS service account.

That account is made a member of the AD RMS Service Group, and it is granted the permissions that are associated with this group. During routine operations, AD RMS runs under the AD RMS service account.

You can change the AD RMS service account at any time. When you do so, the previously specified account is automatically removed from the AD RMS Service Group, and the new account is made a member of it. If there is more than one server in the AD RMS cluster where you are changing the AD RMS service account, you must change the service account on all servers in the cluster.

To run the Change Service Account wizard, you must be logged on locally on the AD RMS server with a user account that has administrative privileges to the configuration database.

Important

For security reasons, we highly recommend that you create a special user account to use as the AD RMS service account, and that you use this account only as the AD RMS service account and for no other purpose. In addition, you should not grant this account any additional permissions.

Membership in the AD RMS Enterprise Administrators and the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To change the AD RMS Service Account

  1. Open the Active Directory Rights Management Services console and select the AD RMS cluster.

  2. In the Actions pane, click Change Service Account.

  3. In the Change Service Account wizard, read the text on the Before Changing the AD RMS Service Account page, and then click Next.

  4. In the User name box, specify the name of the account within which AD RMS will run for most operations. The user name should use the format domain_name\user_name. In the Password box, type the password for the associated user account.

  5. Click Next, and then click Finish.

  6. Repeat steps 1–5 for each server in the AD RMS cluster.
Important

The AD RMS service account cannot be the same domain account that was used to install AD RMS.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Configuring Accounts


Specify the Administrative Contact

The administrative contact is the person or group of persons in your organization that can assist a user in resolving issues with AD RMS.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To specify the administrative contact

  1. Open the Active Directory Rights Management Services console and select the AD RMS cluster.

  2. Right-click the cluster, and then click Properties.

  3. On the General tab in the Administrative contact area, type the e-mail address of the administrator to contact.

  4. Click OK to close the properties sheet.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Configuring Accounts


Configuring Rights Policy Templates

Rights policy templates are configured by using the Active Directory Rights Management Services console. After they are configured, these templates are stored in the configuration database and in an optional shared folder.

This section provides the following:

  • Understanding Rights Policy Templates

  • Understanding Rights Enforcement

  • Specify the Location of Rights Policy Templates

  • Create a New Rights Policy Template

  • Edit a Rights Policy Template

  • View a Summary of User Rights for a Rights Policy Template

  • Archive a Rights Policy Template

  • Delete a Rights Policy Template

  • Add New Language to Rights Policy Template

  • Deploy Rights Policy Templates Through Group Policy

  • Deploy Rights Policy Templates Manually

  • Restore Rights Policy Templates


Understanding Rights Policy Templates

Rights policy templates are used to control the rights that a user or group has on a particular piece of rights-protected content. AD RMS stores rights policy templates in the configuration database. Optionally, it maintains a copy of all rights policy templates in a shared folder that you specify. For information about how rights are enforced, see Understanding Rights Enforcement.

When publishing protected content, the author selects the rights policy template to apply from the templates that are available on the local computer. To make rights policy templates available to use for offline publishing, the administrator must deploy them to user computers from a shared folder. For AD RMS running on Windows Server 2008 R2 or Windows Server® 2008, rights policy templates are automatically managed by the AD RMS client. A template distribution pipeline enables the AD RMS client to poll for updates to the rights policy templates. If a rights policy template has been added, changed, or deleted, the client detects these changes and updates the local rights policy templates during its next refresh. The rights policy templates are stored locally on the AD RMS client running Windows Server 2008 R2, Windows 7, Windows Server 2008, or Windows Vista in the %localappdata%\Microsoft\DRM\templates folder. For Windows XP, Windows 2000, and Windows Server 2003, the path is %appdata%\Microsoft\DRM\templates.

Note

The new rights policy templates distribution method is only available for AD RMS clients running Windows Server 2008, Windows Vista RC1, Windows Server 2008 R2 or Windows 7. All versions of the Rights Management Services (RMS) client use the previous method for rights policy template distribution.

When you modify a rights policy template on the AD RMS server, the server updates the template in both the configuration database and the shared folder (if the AD RMS cluster is configured to specify a file location for storing copies of rights policy templates). When using AD RMS clients other than Windows Server 2008, Windows Vista RC1, Windows 7, or Windows Server 2008 R2, you should redeploy each rights policy template to client computers when it has been modified so that users have the most current version available on their computers. AD RMS clients running on Windows Server 2008, Windows Vista RC1, Windows 7, or Windows Server 2008 R2 will automatically detect this change and update the rights policy templates accordingly.

For more information about deploying rights policy templates, see http://go.microsoft.com/fwlink/?LinkId=81070.

Rights policy templates for the RMS client

For users to be able to author rights-protected content using a rights policy template they must have access to the template. If client computers are always connected to the internal network and can access shared folders, you can have them use a shared folder for template access. However, most administrators choose to place the template files on the local client computers so that they can be used for offline as well as online publishing of rights-protected content. AD RMS-enabled clients running Windows Server 2008, Windows Vista RC1, Windows 7, or Windows Server 2008 R2 can use the template distribution pipeline to automatically update their rights policy templates.

Note

If a template is moved to this AD RMS server from another AD RMS server, the template must then be exported from this server and redistributed to the clients before it can be used.

The following are a set of best practices to follow when deploying rights policy templates to versions of the RMS client:

  • Deploy the template files locally to user's computers, so they can use templates while their computers are not connected to the network.

  • Set up a shared folder as the deployment point on a server in the AD RMS cluster. Set the permissions on the shared folder and on the template files as described in the following table:

Account | Permissions
AD RMS Service Group | Modify
System | Modify
Users | Read

Additional references

  • Configuring Rights Policy Templates


Understanding Rights Enforcement

Active Directory Rights Management Services (AD RMS) rights provide the means for controlling how a user can access, use, and redistribute rights-protected content. Some rights are enforced exclusively by AD RMS-enabled applications or browsers, while others are enforced primarily by the AD RMS client (although applications can still apply their own interpretation of the right). The rights enforced by the AD RMS client control how license information is used, such as whether the license can be used to re-encrypt previously decrypted content. Rights that control how content is used are interpreted and enforced by AD RMS-enabled applications, such as Microsoft Office applications. For example, Microsoft Office applications enforce the View right by allowing a user to decrypt and view the contents of a protected document if the user has been granted the View right.

The following table lists the rights that are available by default when you create a rights policy template and gives a brief description of how the right is enforced by the AD RMS client and interpreted by common AD RMS-enabled applications.

Note

AD RMS-enabled applications can interpret these rights differently. This is intended as a general description for how these rights are typically used. Consult the documentation of the specific application for information on how these rights are enforced.

Right | Description
Full control | If granted, this right allows a user to exercise all rights in the license, whether or not the rights are specifically granted to that user.
View | If this right is granted, the AD RMS client allows protected content to be decrypted. Typically, when this right is granted, the application will allow the user to view protected content.
Edit | If this right is granted, the AD RMS client allows protected content to be decrypted and then re-encrypted by using the same content key. Typically, when this right is granted, the application will allow the user to change protected content and then save it to the same file. This right is effectively identical to the Save right.
Save | If this right is granted, the AD RMS client allows protected content to be decrypted and then re-encrypted by using the same content key. Typically, when this right is granted, the application will allow the user to change protected content and then save it to the same file. This right is effectively identical to the Edit right.
Export (Save As) | If this right is granted, the AD RMS client allows protected content to be decrypted and then re-encrypted by using the same content key. Typically, when this right is granted, the application will allow the user to use the “Save As” feature to save protected content to a new file.
Print | Typically, when this right is granted, the application will allow the user to print protected content.
Forward | Typically, when this right is granted, the application will allow an e-mail recipient to forward a protected message.
Reply | Typically, when this right is granted, the application will allow an e-mail recipient to reply to a protected message and include a copy of the original message.
Reply All | Typically, when this right is granted, the application will allow an e-mail recipient to reply to all recipients of a protected message and include a copy of the original message.
Extract | Typically, when this right is granted, the application will allow the user to copy and paste information from protected content.
Allow Macros | Typically, when this right is granted, the application will allow the user to run macros in the document or use an editor to modify macros in the document.
View Rights | If this right is granted, the AD RMS client allows a user to view the user rights that are assigned by the license.
Edit Rights | If this right is granted, the AD RMS client allows a user to edit the user rights that are assigned by the license.

Additional references

  • Understanding Rights Policy Templates

  • Configuring Rights Policy Templates


Specify the Location of Rights Policy Templates

With Windows Server 2008 or Windows Server 2008 R2, AD RMS clients running on Windows Server 2008, Windows Vista with Service Pack 1, Windows Server 2008 R2, or Windows 7 can automatically obtain rights policy templates from an AD RMS cluster and keep them up-to-date through an automated scheduled task. For more information about creating this scheduled task, see Active Directory Rights Management Services (AD RMS) Rights Policy Templates Deployment Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=93718). However, you might need to continue exporting templates to a folder for distributing them manually to clients that do not support this feature. The location you specify by using the following procedure creates a point from which you can distribute the templates to client computers.

Note

Only distributed rights policy templates are stored in the shared folder. If you are using archived rights policy templates, you must change them to distributed rights policy templates before they can appear in the shared folder.

If you are using Microsoft Office 2003 or later as your AD RMS-enabled application, the location where Microsoft Office applications acquire the rights policy templates is controlled by the AdminTemplatePath registry key. This registry entry should be configured to point to a local folder where the rights policy templates are stored. For more information about deploying rights policy templates, see the Rights Policy Templates Deployment Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=81070).

Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure.

To specify the location of rights policy templates

  1. Create a folder on the server to be used to store the exported rights policy templates.

  2. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  3. In the console tree, click Rights Policy Templates.

  4. In the Actions pane, click Properties, and then select the Enable export check box.

  5. In the Specify templates file location (UNC) box, type the location of a shared folder in which to store the rights policy templates for this cluster, in the format \\server_name\share_name or click Browse to navigate to the location.

  6. Make sure that the following criteria are met before exporting the rights policy templates:

    • The AD RMS Service Group must have Write permission on the shared folder.

    • Shared folders for templates are not created in the core folders that are used by AD RMS, such as the _wmcs folder in the %systemdrive%\inetpub\wwwroot folder.

    • Make sure that the shared folder is accessible before exporting the rights policy templates to it. Otherwise, you need to clear the Enable export box, click OK, set the Enable export box, type the name of the shared folder again, and then click OK. This action forces all rights policy templates to export to the shared folder.

  7. Click OK.

After you export the rights policy templates, make them available to users. Different versions of the AD RMS client and AD RMS-enabled applications have different means of specifying where rights policy templates should be stored on the client computer. Consult the manufacturer of the AD RMS-enabled application to determine how rights policy templates are handled for that application.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Configuring Rights Policy Templates


Create a New Rights Policy Template

When you create a new rights policy template, the Create Distributed Rights Policy Template or Create Archived Rights Policy Template wizard , steps you through the different elements of the template depending on the desired type of rights policy template. These elements can be modified later by selecting the template and opening its properties sheet. A distributed rights policy template allows users to publish and consume rights-protected content, and an archived rights policy template only allows consumption once the rights policy template has been removed from the client computer. The properties included in these two rights policy templates are the same and are configured in the following procedure.

Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure.

To create a rights policy template

  1. Open the Active Directory Rights Management Services console and expand the Active Directory Rights Management Services (AD RMS) cluster.

  2. In the console tree, click Rights Policy Templates.

  3. In the Actions pane, click Create Distributed Rights Policy Template. The Create Distributed Rights Policy Template wizard appears.

  4. On the Add Template identification Information page, click Add.

  5. Specify a language, name, description, and for the template, and then click Add.

  6. Click Next.

  7. On the Add User Rights page do the following:

    1. Click Add. In the Add User or Group dialog box, click Browse to browse to a user or group in your Active Directory Domain Services directory or type the valid e-mail address of a user or group to add, and then click OK. Repeat to add additional users or groups as necessary.

      To specify that any user can acquire a use license for the protected content, select the Anyone option, which is a special group that is recognized by AD RMS.

    2. Under Users and rights, select a user or group to which to assign rights. Select the check box of each right to grant to the selected user or group.

      Select another user or group and repeat the process to grant rights to the remaining users and groups. If your AD RMS-enabled application has custom usage rights, you can assign those rights to users and groups by clicking Create Custom Right. In the Create Custom Right dialog box type the name of the right defined by your application. A check box will then be available for that right in your template.

    3. In the Rights request URL box, type the URL from which users can request additional rights to rights-protected content.

    4. Click Next.

  8. On the Specify Expiration Policy page:

    1. In Content expiration, select one of the three expiration options:

      • Select Never expires to prevent the content from expiring.

      • Select Expires on the following date (UTC) and then select the date and time on which you want the content to expire. The time is expressed in Coordinated Universal Time (UCT), also known as Greenwich Mean Time.

      • Select Expires after the following duration (days) and then select the number of days you want the content to remain valid.

    2. If appropriate, in Use license expiration, select Expires after the following duration (days) and then select the number of days you want the license to remain valid.

    Click Next.

  9. On the Specify Extended Policy page:

    1. Click Enable users to view protected content using a browser add-on if you want the user who does not have an AD RMS-enabled application installed to view rights-protected content.

    2. Click Request a new use license every time content is consumed (disable client-side caching) if you want the user to re-authenticate with AD RMS each time the rights-protected content is consumed.

    3. Click If you would like to specify additional information for your AD RMS-enabled applications, you can specify them here as name-value pairs if you want to add application-specific data as custom name value pairs in addition to the XrML rights supported by AD RMS. An application developer can add to an AD RMS-enabled application to limit interaction with the protected content. Application-specific data is enforced at the AD RMS-enabled application level and applies to all users who use the application.

    Click Next.

  10. To implement revocation, in the Specify Revocation Policy page, select the Require revocation check box, and then take the following steps:

    1. In Location where the revocation list is published (URL or UNC), type the URL where the revocation list file is posted. If you need to support disconnected users or external users, this URL should be accessible from both the internal organization's network and the Internet.

    2. In Refresh interval for revocation list (days), type the number of days that the revocation list remains valid. If a user has a copy of the revocation list that is older than this value, the user must obtain an updated revocation list to consume the content.

    3. In File containing public key corresponding to the signed revocation list, type the path and file name, or click Browse to locate the public key file for the revocation list.

    Caution

    Be careful when implementing revocation. Based on the refresh interval that you specify, you must renew a revocation list periodically or it will automatically expire, preventing users from consuming content that requires that list. To ensure that you do not inadvertently prevent users from consuming content, carefully evaluate the interval you require for refreshing the revocation list.

  11. Click Finish.

You can also create copies of rights policy templates. This can be useful if you have a template that you want to use as the basis for other templates with only minor modifications.

To copy a rights policy template

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, click Rights Policy Templates.

  3. In the results pane, select the rights policy template to be copied.

  4. Click Copy in the Actions pane. A new rights policy template will appear in the results pane.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Configuring Rights Policy Templates


Edit a Rights Policy Template

To edit an existing rights policy template, use the following procedure.

Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure.

To edit a rights policy template

  1. Open the Active Directory Rights Management Services console and expand the Active Directory Rights Management Services (AD RMS) cluster.

  2. In the console tree, click Rights Policy Templates.

  3. If you are editing a distributed rights policy template, click Manage Distributed Rights Policy Templates in the Actions pane. If you are editing an archived rights policy template, click Managed Archived Rights Policy Templates in the Actions pane.

  4. In the results pane, click the name of the template to edit.

  5. In the Actions pane, click Properties of the rights policy template.

  6. On the Identification Information tab, modify the information in the Template name, and Template description areas as appropriate. You can add additional languages to Template language as necessary.

  7. On the User Rights tab, do one or more of the following:

    • To add a user or group, in Users and rights, click Add, type the valid e-mail address of a specific user or group to select Anyone to allow all users to view content, and then click OK.

    • Select the name in Users and rights. In the Rights for area, select all rights to be granted to the selected user or group.

    • To modify the rights of an existing user or group, select the name in Users and rights, and then select or clear the rights check boxes, as appropriate.

    • To remove a user or group, select the name in Users and rights, and then click Remove.

    • To add a custom right, click Create Custom Right and then type the name of the right supported by your rights-enabled application.

    • To change the URL that users can request additional rights through in Rights request URL, type the new URL.

  8. On the Expiration Policy tab, edit the information to change when content licenses expire and when they must be renewed, as appropriate.

    • Click Never Expires to set no expiration date on content that is protected with this rights policy template.

    • Click Expires on the following date (UTC) to set a specific date and time when the content protected with this rights policy template expires. The date and time are expressed in Coordinated Universal Time (UTC), also known as Greenwich Mean Time.

    • Click Expires after the following duration to set the content to expire after a set amount of days.

    • Under Use license expiration, set Expires after the following duration to force the user to request a new use license for all content protected by using this rights policy template.

  9. On the Extended Policy tab, edit the information to change how content licenses are to be implemented, including the persistence of author rights, whether trusted browsers are supported, license persistence within the content, and enforcement of any application-specific data, as appropriate.

    • Select Enable users to view protected content using a browser add-on if you want content protected by this rights policy template to be accessible by means of a Web browser, such as Internet Explorer with the Rights Management add-on.

    • Select Require a new use license every time content is consumed if you want users to request a new use license whenever the content protected with this rights policy template is opened. The AD RMS client must be able to connect to the AD RMS cluster each time that this content is consumed. This is not ideal for offline publishing.

    • To add additional name/value pairs created with AD RMS-enabled applications, select the If you would like to specify additional information for your AD RMS-enabled application box.

  10. On the Revocation policy tab, select whether a revocation list is to be required for content that is created by using this template. If you select Require revocation, complete the following settings, as appropriate:

    • In Location where the revocation list is published, type the URL where the revocation list file is posted. If you need to support disconnected users or external users, this URL should be accessible from both the corporate network and the Internet.

    • In Refresh interval for Revocation list, type the number of days that the revocation list remains valid. If a user has a copy of the revocation list that is older than this value, the user must obtain an updated revocation list to consume the content.

    • In File containing public key corresponding to the signed revocation list, type the path and file name of the public key file for the revocation list.

    Caution

    Be careful when implementing revocation. Based on the refresh interval that you specify, you must renew a revocation list periodically or it will automatically expire, preventing users from consuming content that requires that list. To ensure that you do not inadvertently prevent users from consuming content, carefully evaluate the interval you require for refreshing the revocation list.

  11. Click OK.

Once a rights policy template is edited on the cluster, the local copies of the template on the client computers must be updated as well.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Configuring Rights Policy Templates


View a Summary of User Rights for a Rights Policy Template

The summary of user rights lets you compare the rights granted to users and groups by a specific template without opening the rights policy template properties.

Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure.

To view a summary of user rights for a rights policy template

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, click Rights Policy Templates.

  3. In the results pane, select the template for which you want to view rights.

  4. In the Actions pane, click View Rights Summary. The rights for each user and group specified for the template are displayed for your review.

  5. To view the user rights for another rights policy template, repeat steps 3 and 4.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Configuring Rights Policy Templates


Archive a Rights Policy Template

Rights policy templates can be archived by using the Active Directory Rights Management Services console. Archived templates are not exported to the template export location and are not distributed by the template distribution pipeline. After the client computers refresh their rights policy templates, the archived templates are no longer available to users for publishing new content. At the same time, archived templates allow the server to continue issuing use licenses for content already published against them.

Note

Archived rights policy templates are not exported to the shared templates folder. If you want to export this template, you must change it back to distributed rights policy template.

Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure.

To archive a rights policy template

  1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  2. In the console tree, click Rights Policy Templates.

  3. Select the name of the rights policy template to archive, and then, in the Actions pane, click Archive this Rights Policy Template.

  4. Click Yes to confirm.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Configuring Rights Policy Templates


Delete a Rights Policy Template

When you delete a rights policy template from the AD RMS cluster, content published using that template can no longer be consumed. As a best practice, you should back up the configuration database before deleting a rights policy template to ensure that you can recover rights-protected content if necessary.

An alternative to backing up the whole database is to archive the template that you want to stop using to add rights-protection to documents. Archiving a rights policy template will allow users to consume the content but not create new rights-protected content with the template. For more information about archiving templates, see Archive a Rights Policy Template.

For AD RMS clients that are not running Windows Server 2008 or Windows Server 2008 R2, or clients for which the automatic rights policy template distribution has not been enabled, you must manually remove the rights policy template from a user's computer. If you do not remove the deleted rights policy template and someone uses it to publish content, AD RMS will not be able to issue any use licenses for the content, because it will not be able to locate the specified template in the configuration database.

Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure.

To delete a rights policy template

  1. Log on to a computer in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  3. In the console tree, click Rights Policy Templates.

  4. Select the name of the rights policy template to delete, and then, in the Action pane, click Delete.

  5. Click Yes to confirm the deletion.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Configuring Rights Policy Templates

  • Archive a Rights Policy Template


Add New Language to Rights Policy Template

When you create a rights policy template, you select the language that the template uses. By default, rights policy templates use the language setting of your server operating system.

If you have AD RMS-enabled clients that use a different language setting on their operating systems, selecting their language setting when you create the rights policy template. This enables the template to reflect the preferred regional language option of the client.

Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure.

To add a new language to a rights policy template

  1. Log on to a computer in the AD RMS cluster.

  2. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  3. In the console tree, click Rights Policy Templates.

  4. Select the name of the desired rights policy template, and then, in the Actions pane, click Properties.

  5. On the Identification Information tab, click Add.

  6. Select the desired language from the Language box.

  7. In the Name box, type a name that will be displayed to AD RMS users. As a best practice, use the name of the language in the template name to allow you to easily distinguish which templates have which language identifiers.

  8. In the Description box, type a description for the rights policy template.

  9. Click OK, and then click OK again to close the properties sheet.
Note

To select a given language, you must have the language installed on your server. Adding a new language is done though the Regional and Language Options in Control Panel. Click the Keyboard and Languages tab and then click Install/uninstall languages to start the Install or Uninstall Display Languages wizard.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional reference

  • Configuring Rights Policy Templates


Deploy Rights Policy Templates Through Group Policy

New Group Policy template files (ADM files) are available that assist Active Directory administrators in making and distributing settings for Office 2007 by using Group Policy. To download the 2007 Office System Administrative Templates, see http://go.microsoft.com/fwlink/?LinkId=80639.

The following files in the Administrative Templates package are extracted to a folder that you choose:

  • Access12.adm

  • Cpao12.adm

  • Excel12.adm

  • Groove12.adm

  • Ic12.adm

  • Inf12.adm

  • Office12.adm

  • Onent12.adm

  • Outlk12.adm

  • Ppt12.adm

  • Proj12.adm

  • Pub12.adm

  • Spd12.adm

  • Visio12.adm

  • Word12.adm

Once the ADM files are imported into Group Policy (at minimum you must have Office12.adm), IRM settings can be found under User Configuration, Administrative Templates, Microsoft Office 2007 System, Manage Restricted Permissions. Configure the Specify Permission Policy Path setting to reflect the local template store on the client computer.

Additional reference

  • Configuring Rights Policy Templates


Deploy Rights Policy Templates Manually

If you choose to configure the registry settings directly on the client computers, you must create the following registry key:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\12.0\Common\DRM\AdminTemplatePath

Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

For the registry value, you must specify the path to the templates folder. You can create the registry setting using a data type of REG_SZ or REG_EXPAND_SZ.

If you create the AdminTemplatePath registry entry with a data type of REG_SZ, you must specify the explicit path for the templates folder, such as C:\Documents and Settings\All Users\Local Settings\Application Data\Microsoft\DRM. If you create the AdminTemplatePath with a data type of REG_EXPAND_SZ you can specify the path using environment variables, for example, %allusersprofile%\Application Data\Microsoft\DRM.

Once this registry entry is created, you must copy the templates files manually from the exported template location path. If you are using Windows Server 2008, Windows Vista, Windows Server 2008 R2, or Windows 7 as your AD RMS client, the rights policy templates are automatically managed when the automatic rights policy template management feature is enabled. For more information about deploying rights policy templates, see http://go.microsoft.com/fwlink/?LinkId=81070.

Additional references

  • Configuring Rights Policy Templates

  • Specify the Location of Rights Policy Templates


Restore Rights Policy Templates

To ensure that rights policy templates are available in the export location after a system restore of the computer where the rights policy templates are stored, you must export the rights policy templates from the configuration database again.

Note

If you are using Windows Server 2008 R2 with automatic template distribution enabled, exporting the rights policy templates is not required.

Membership in the local AD RMS Template Administrators, or equivalent, is the minimum required to complete this procedure.

To restore a rights policy template

  1. Log on to a computer in the AD RMS cluster.

  2. Delete the rights policy templates that are in the rights policy templates export folder.

  3. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.

  4. In the console tree, click Rights Policy Templates.

  5. In the Actions pane, click Properties, clear the Enable export check box, and then click Apply.

  6. Select the Enable export check box, specify a valid network path in the Specify templates file location (UNC) box, and then click OK. All the rights policy templates from the configuration database will be exported and overwrite the ones currently in this folder.

Additional considerations

  • You can also perform the task described in this procedure by using Windows PowerShell. For more information about Windows PowerShell for AD RMS, see http://go.microsoft.com/fwlink/?LinkId=136806.

Additional references

  • Specify the Location of Rights Policy Templates

  • Configuring Rights Policy Templates


Configuring AD RMS Across Forests

The procedures in this section are designed to help you configure AD RMS across Active Directory forests.

This section contains the following topics:

  • Understanding AD RMS Across Forests

  • Configure the Access Control List on the GroupExpansion Folder


Understanding AD RMS Across Forests

If you are deploying AD RMS in an environment with multiple Active Directory Domain Services (AD DS) forests, you need to determine what support might be required for users or groups who are outside of the forest in which AD RMS is deployed. AD RMS uses AD DS to identify users and distribution groups. When an organization’s AD DS deployment includes multiple forests, AD RMS uses AD DS contact objects to obtain the identities of users and groups that are part of a different forest than the AD RMS cluster. The problem is that user or group objects from other forests do not typically have representative objects that are in the forest where AD RMS resides. If you intend to use AD RMS to restrict permissions to users or groups who are from other forests, you need to configure your Active Directory forest appropriately to allow group expansion to occur across forests.

You can implement group expansion support across forests for AD RMS in two ways:

  • Deploy an AD RMS cluster into the forest where the groups are defined, and where it will be used to expand the membership of these groups. AD DS Universal groups should be used so that the group membership is replicated to every global catalog server in the forest. Schema extensions must exist in forests that contain contact objects that allow the schema extensions to point back to the forests that contain the actual objects. If schema extensions are not used, client registry overrides are required.

  • Synchronize group definitions among forests to allow the local AD RMS installation to determine the complete group membership for any user. If the user who is requesting a use license has a Windows account in a separate forest, there also must be a contact object in the local forest to represent that user’s group membership.

Additional references

  • Configuring AD RMS Across Forests

  • Understanding AD RMS Trust Policies


Configure the Access Control List on the GroupExpansion Folder

The following procedure describes how to set the access control list (ACL) on the GroupExpansion folder and the GroupExpansion.asmx file, assuming that there are only the two forests (Forest1 and Forest2) in the organization. If you have more than two forests, repeat the procedure as necessary to configure the ACLs on all the servers in the Active Directory Rights Management Services (AD RMS) cluster.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To set the ACL on the GroupExpansion folder and GroupExpansion.asmx file

  1. Log on to a server of your AD RMS cluster in Forest1.

  2. Click Start, and then click Computer.

  3. Navigate to the %systemdrive%\inetpub\wwwroot\_wmcs folder.

  4. Right-click GroupExpansion folder, and then click Properties.

  5. Click the Security tab, and then click Edit.

  6. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

  7. Click Add, add the AD RMS service account from Forest2, for example, Forest2\ADRmsServiceAccount, and then click OK to close the dialog box. Continue to click OK until all of the open dialog boxes are closed.

  8. Repeat steps 1–7 for the GroupExpansion.asmx file located in the GroupExpansion folder.

  9. At a command prompt, type iisreset, and then press ENTER to restart Internet Information Services.

Additional reference

  • Configuring AD RMS Across Forests


Removing an AD RMS Cluster

There can be instances when you need to retire an Active Directory Rights Management Services (AD RMS) server or remove an existing AD RMS cluster entirely. Before you retire a server, you should back up all AD RMS databases that are used by the server, especially the configuration database.

After you back up the databases, you can remove the server. The requirements for removing an AD RMS server depend on the role of the server and topology of the AD RMS installation:

  • Removing one server from a cluster. If the AD RMS server that you want to retire is in a cluster in which other servers in that AD RMS cluster are still active and required, removing an individual AD RMS server from the cluster requires that you unprovision and uninstall AD RMS on the server that you want to retire, and remove the server from the load-balancing rotation. Consult the documentation of the load balancer for instructions about removing a server.

    Note

    Only servers in the root cluster must be unprovisioned before you uninstall AD RMS. This process is not required for servers that are in licensing-only clusters.

  • Retiring a stand-alone server. If the AD RMS server to be retired is the only server in that cluster, take the following steps: decommission, unprovision, and uninstall the existing AD RMS server, remove it from the network, and then immediately install and provision AD RMS on the replacement server. Configure the new AD RMS server (this will create a new single-server cluster) and use the same URL and configuration database as the retired AD RMS server. Keep in mind that, until the replacement server is installed and provisioned, users cannot consume rights-protected content that was published by the single-server cluster.

    Important

    If the AD RMS server that you are replacing uses a hardware or software-based cryptographic service provider (CSP), you must move the key container to the new server before you install and provision AD RMS on it. For information about moving the key container, see the documentation that came with your CSP.

  • Replacing an AD RMS installation with another, existing AD RMS installation. In some circumstances, you might need to retire an AD RMS installation and replace it with another, existing AD RMS installation, for example, in the case of a company merger where both companies are running AD RMS. In this case, you should export the trusted user domain (TUD) and trusted publishing domain (TPD) from the AD RMS cluster being retired. Import the TUD and TPD into the AD RMS cluster that is still active. Importing the TUD and TPD will ensure that the rights-protected content that was previously protected from the retired AD RMS installation can be consumed in the active cluster.

When you decommission, unprovision, and uninstall an AD RMS server, the server is removed from the ClusterServer table of the configuration database, and the directory services database is deleted from the database server.

This section contains the following procedures:

  • Decommission AD RMS

  • Remove the AD RMS Server Role


Decommission AD RMS

Before you remove the Active Directory Rights Management Services (AD RMS) role from a server, you should first decommission AD RMS. When you decommission AD RMS, the behavior of the AD RMS cluster is changed such that it can now provide a key that decrypts the rights-protected content that it had previously published. This key allows the content to be saved without AD RMS protection. This can be useful if you have decided to stop using AD RMS protection in your organization, or still need the information.

You should enable decommissioning on each server in the cluster long enough for users to have the opportunity to save their content without AD RMS protection and for your network and system administrators to disable any AD RMS-enabled clients from using the service.

After you enable decommissioning, the Active Directory Rights Management console will only show the Decommissioning server information page in the results pane; no further administration is supported.

Caution

When you decommission a server, it cannot be restored to its previous AD RMS configuration. This process cannot be reversed. Once you have decommissioned AD RMS, you must completely remove AD RMS by using Server Manager before you attempt to install another instance of AD RMS.

Membership in the local AD RMS Enterprise Administrators, or equivalent, is the minimum required to complete this procedure.

To decommission AD RMS

  1. Log on to the server on which you want to decommission AD RMS.

  2. Modify the access control list (ACL) on the decommissioning.asmx file by granting the Everyone group Read & Execute permissions. The default location for this file is %systemdrive%\inetpub\wwwroot\_wmcs\decommission.

  3. Open the Active Directory Rights Management Services console and add the AD RMS cluster.

  4. Expand the AD RMS cluster, expand Security Policies, and then select Decommissioning.

  5. Select the Enable Decommissioning option in the Actions pane.

  6. Click Decommission.

  7. When prompted, click Yes to confirm that you want to permanently decommission the AD RMS installation.

  8. Repeat steps 1–7 for all AD RMS servers in the cluster.

  9. Inform your users that you are decommissioning the AD RMS installation and advise them to connect to the cluster to save their content without AD RMS protection. Alternatively, you could delegate a trusted person to decrypt all rights-protected content by temporarily adding that person to the AD RMS super users group.

  10. After you believe that all of the content is unprotected and saved, you should export the server licensor certificate, and then uninstall AD RMS from the server.

Additional references

  • Removing an AD RMS Cluster

  • Export the Server Licensor Certificate


Remove the AD RMS Server Role

The AD RMS server role is removed from an AD RMS cluster by using Server Manager.

Important

If you are removing every server in the AD RMS cluster, be sure to first decommission AD RMS and remove all protection from the content that is rights-protected by this AD RMS cluster. If you are only removing one AD RMS server from the cluster, you do not need to decommission the AD RMS environment because other servers continue to issue certification and licensing requests to AD RMS users.

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

To remove the AD RMS server role

  1. Log on to the server on which you want to remove the AD RMS server role.

  2. Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.

  3. In the tree, click Manage Roles.

  4. Under Roles Summary, click Remove roles.

  5. Read Before You Begin, and then click Next.

  6. Clear the Active Directory Rights Management Services check box. If you no longer have a need for Internet Information Services (IIS) on this server, clear the Web Server (IIS) box, and then click Next.

  7. Click Remove. Removing the AD RMS server role can take several minutes.

  8. When the server role is removed, click Finish.

Additional references

  • Decommission AD RMS

  • Removing an AD RMS Cluster


Working with the AD RMS Client

The Active Directory Rights Management Services (AD RMS) client is included with the Windows Vista, the Windows 7, the Windows Server 2008, and the Windows Server 2008 R2 operating systems. If you are using Windows XP, Windows 2000, or Windows Server 2003 as your client operating system, a compatible version of the AD RMS client is available for download from the Microsoft Download Center.

The AD RMS client can be used with the AD RMS server role included in Windows Server 2008 or Windows Server 2008 R2 or with previous versions of RMS running on Windows Server 2003.

The AD RMS client creates the machine certificate, which is used to identify the lockbox that stores the key pair for the current user. You can verify the presence of the AD RMS client on a computer by finding the msdrm.dll file on the computer. This file is protected by Windows Resource Protection in Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2, and cannot be modified except through official Microsoft updates.

Applications can use the AD RMS client to incorporate rights management features into their application. For example, Microsoft Office 2003, Microsoft Office 2007, and Windows Mobile 6 use the AD RMS client to support the information rights management features that provide rights management for documents, e-mails, spreadsheets, and slide presentations.

This section contains the following procedures:

  • Install the AD RMS Client on Earlier Versions of Windows

  • AD RMS Client Service Discovery


Install the AD RMS Client on Earlier Versions of Windows

Beginning with Windows Vista and Windows Server 2008, the name of the AD RMS client has changed to Active Directory Rights Management Services (AD RMS) client and is integrated into the operating system so that a separate installation is not required. In earlier versions of Windows, the client is named Microsoft Windows Rights Management Services (RMS) client and is available from the Microsoft Download Center as a separate downloadable component. The RMS client can be installed on the Windows 2000, Windows XP, and Windows Server 2003 operating systems.

The RMS client supports three different architectures: x86, x64, and Itanium. The download locations for each version of the RMS client are the following:

  • RMS client (x86 version): http://go.microsoft.com/fwlink/?LinkId=76880.

  • RMS client (x64 version): http://go.microsoft.com/fwlink/?LinkId=76882.

  • RMS client (Itanium version): http://go.microsoft.com/fwlink/?LinkId=76884.

The AD RMS client requires little interaction from the system administrator who is administering the client computers. However, in more complex environments, it might be necessary to adjust the default AD RMS client configuration.

For more information about adjusting the default configuration, see AD RMS Client Service Discovery.

Additional references

  • AD RMS Client Service Discovery

  • Working with the AD RMS Client


AD RMS Client Service Discovery

Active Directory Rights Management Services (AD RMS) client service discovery is the method by which the AD RMS client discovers an AD RMS cluster. There are three ways in which this can occur:

  • Active Directory Domain Services (AD DS) service connection point (SCP) automatic service discovery. This is the recommended way to deploy an AD RMS environment. In this scenario, an SCP is created in the Active Directory forest where the AD RMS cluster is installed. When the AD RMS client attempts user activation on the computer, it queries the SCP to find the AD RMS cluster and download the rights account certificate (RAC). With automatic service discovery, no additional configuration is required on the AD RMS client.

  • AD RMS client registry overrides. In complex AD RMS deployment topologies, more specific control of the AD RMS client is required. For versions of the Rights Management Services (RMS) client running on Windows XP, Windows 2000, or Windows Server 2003, these overrides are required for topologies where multiple Active Directory forests are deployed. Another example of where client registry overrides can be used is to support extranet users. In these cases, client registry overrides are created on the AD RMS client to force either certification or licensing of rights-protected content from an AD RMS cluster that is different from the one published in the SCP. The AD RMS client registry overrides used to override the SCP are created in:

    HKEY_LOCAL_MACHINE\Software\Microsoft\MSDRM\ServiceLocation.

    The client registry override keys are the following:

    • Activation. This key is used to override the default AD RMS certification service that is configured in the SCP. The syntax for this key is http(s)://<your cluster>/_wmcs/certification where <your cluster> is the URL of the root cluster that should be used for certification.

    • EnterprisePublishing. This key is used to override the default AD RMS licensing service to which the AD RMS client connects. The syntax for this key is http(s)://<your cluster>/_wmcs/licensing where <your cluster> is the URL of the licensing-only cluster.

    Note

    The client registry overrides are configured as registry keys. The value of these registry keys should be added to the default entry of the registry key of type REG_SZ.

    • If the AD RMS client computer is connecting by using a federated trust, you must configure the federation home realm. The registry key is:

      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDRM\Federation

      Within this registry key create an registry entry named FederationHomeRealm of type REG_SZ. The value of this registry entry is the federation service URI.

  • Examine issuance license for extranet URLs. The last method for AD RMS client service discovery is by means of the issuance license. When rights-protected content is published, the intranet as well as the extranet licensing service URLs are added to the issuance license. When an AD RMS client opens the rights-protected content for the first time and the other methods of service discovery are not available, the client can retrieve the licensing URLs from the issuance license.

Additional references

  • Working with the AD RMS Client

  • Configure Federated Identity Support Settings


Resources for AD RMS

For more information about Active Directory Rights Management Services (AD RMS), see the following resources:

  • For information about getting started with AD RMS, see http://go.microsoft.com/fwlink/?LinkId=84730.

  • For information about evaluating AD RMS, see http://go.microsoft.com/fwlink/?LinkId=84732.

Additional reference

  • Active Directory Rights Management Services


User Interface: AD RMS

The topics in this section are designed to be read while viewing the associated window in the Active Directory Rights Management Services console.

  • Add Cluster - Add Cluster Wizard

  • Cluster - AD RMS Server Cluster Results Pane

  • Cluster - Change AD RMS Service Account Wizard

  • Cluster - Cluster Properties - General Tab

  • Cluster - Cluster Properties - Cluster URLs Tab

  • Cluster - Cluster Properties - AD RMS Servers Tab

  • Cluster - Cluster Properties - Server Certificate Tab

  • Cluster - Cluster Properties - Proxy Settings Tab

  • Cluster - Cluster Properties - Logging Tab

  • Cluster - Cluster Properties - SCP Tab

  • Trust Policies - Trust Policies Results Pane

  • Trust Policies - Trusted User Domains - Trusted User Domains Results Pane

  • Trust Policies - Trusted User Domains - Trusted User Domain Certificate

  • Trust Policies - Trusted User Domains - Trusted User Domain Properties

  • Trust Policies - Trusted User Domains - Import Trusted User Domain Wizard

  • Trust Policies - Trusted Publishing Domains - Trusted Publishing Domains Results Pane

  • Trust Policies - Trusted Publishing Domains - Trusted Publishing Domain Certificate

  • Trust Policies - Trusted Publishing Domains - Trusted Publishing Domain Properties

  • Trust Policies - Trusted Publishing Domains - Import Trusted Publishing Domain Wizard

  • Trust Policies - Trusted Publishing Domains - Export Trusted Publishing Domain Wizard

  • Trust Policies - Federated Identity Support - Federated Identity Support Results Pane

  • Trust Policies - Federated Identity Support - Federated Identity Support Properties

  • Rights Policy Templates - Rights Policy Templates Results Pane

  • Rights Policy Templates - Rights Policy Templates Properties

  • Rights Policy Templates - Create Distributed Rights Policy Template Wizard - Add Template Identification Page

  • Rights Policy Templates - Create Distributed Rights Policy Template Wizard - Add User Rights Page

  • Rights Policy Templates - Create Distributed Rights Policy Template Wizard - Rights Policy Template - Specify Expiration Policy Page

  • Rights Policy Templates - Create Distributed Rights Policy Template Wizard - Specify Extended Policy Page

  • Rights Policy Templates - Create Distributed Rights Policy Template Wizard - Specify Revocation Policy Page

  • Rights Account Certificate Policies - Rights Account Certificate Policies Results Pane

  • Rights Account Certificate Policies - Rights Account Certificate Policies Properties - Standard RAC Tab

  • Rights Account Certificate Policies - Rights Account Certificate Policies Properties - Temporary RAC Tab

  • Exclusion Policies - Exclusion Policies Results Pane

  • Exclusion Policies - Users - User Exclusion Policies Results Pane

  • Exclusion Policies - Users - Exclude User Wizard

  • Exclusion Policies - Applications - Application Exclusion Policies Results Pane

  • Exclusion Policies - Applications - Exclude Application Wizard

  • Exclusion Policies - Applications - Excluded Application Results Pane

  • Exclusion Policies - Applications - Excluded Application Properties

  • Exclusion Policies - Lockbox - Lockbox Results Pane

  • Exclusion Policies - Lockbox - Lockbox Properties

  • Security Policies - Security Policies Results Pane

  • Security Policies - Super Users - Super Users Results Pane

  • Security Policies - Super Users - Super Users Properties

  • Security Policies - Cluster Key Password Results Pane

  • Security Policies - Cluster Key Password - Cluster Key Password Properties

  • Security Policies - Decommissioning Results Pane

  • Reports - Reports Results Pane


Add Cluster - Add Cluster Wizard

Parameter | Details
Connection protocol | This area defines how the console will communicate with the AD RMS cluster.
URI scheme Port number | If you have enabled SSL, select HTTPS in the URI Scheme box. If you configured IIS with a different port than port 80 (for http) or port 443 (for https), specify the port number in the Port number box.
Connect to | This area identifies whether you are connecting to an AD RMS cluster on the local computer or on another computer on the network, or another AD RMS cluster. If you are connecting to another computer, type the fully qualified domain name or IP address in the Remote computer box.
Connect as | If the currently logged-on user account does not have the required permissions to modify settings on the cluster, you can specify a different user name and password.

Additional reference

  • Administer AD RMS by Using the Active Directory Rights Management Services console


Cluster - AD RMS Server Cluster Results Pane

Each AD RMS root or licensing-only cluster can be managed by using the Active Directory Rights Management Services console. This console can be used directly on an AD RMS server, through a Remote Desktop connection, or in a Microsoft Management Console (MMC) to which the remote cluster has been added.

For more information about tasks that can be accomplished by using the Active Directory Rights Management Services console, see Configuring an AD RMS Cluster and Administer AD RMS by Using the Active Directory Rights Management Services console.

Additional reference

  • User Interface: AD RMS


Cluster - Change AD RMS Service Account Wizard

Parameter | Details
Current AD RMS service account | Domain and user name specified for the AD RMS service account
New AD RMS service account | The AD RMS service account must be configured as a domain user account.

Additional reference

  • Change the AD RMS Service Account


Cluster - Cluster Properties - General Tab

Parameter | Details
Display name for cluster | Display name of AD RMS cluster
Actual cluster name | Actual name of AD RMS cluster
Current Cluster Connection Point | Name of the server that serves as the cluster connection point.
Administrative Contact | E-mail address of a person or group who can help users resolve issues with AD RMS.

Additional references

  • Specify the Administrative Contact


Cluster - Cluster Properties - Cluster URLs Tab

Parameter | Details
Intranet URLs | These URLs are used by AD RMS-enabled clients that are connected to your organization's private network to connect to certification and licensing services in the AD RMS cluster.
Extranet URLs | These URLs are used by AD RMS clients that are connecting to your cluster over the Internet. The licensing and certification URLs will be created based on these URLs.

Additional reference

  • Add an Extranet Cluster URL


Cluster - Cluster Properties - AD RMS Servers Tab

Because AD RMS is managed on a cluster basis, individual servers do not appear in the Active Directory Rights Management Services console as objects that you can administer. This tab provides a list of all the servers that are members of the AD RMS cluster.

Additional reference

  • User Interface: AD RMS


Cluster - Cluster Properties - Server Certificate Tab

Parameter Details

Friendly name

Name of the server licensor certificate (SLC) associated with this cluster.

Hierarchy

Identifies the certificate hierarchy this cluster belongs to.

  • Production—For use by servers in AD RMS clusters that are deployed using released software.

  • Pre-production—For use by servers in AD RMS clusters deployed by application or service developers in support of a development project that has not yet been released.

Export Certificate

Exports the SLC to a binary file that can be used for backup or for import by another AD RMS cluster.

Additional reference

  • Export the Server Licensor Certificate


Cluster - Cluster Properties - Proxy Settings Tab

Parameter | Details
This cluster uses a proxy server to access external networks | If a proxy server is required, selecting this check box enables your AD RMS cluster to connect to the Internet.
Address | Address of the proxy server.
Port | Port the proxy server is configured to use.
Bypass proxy server for local addresses | Selecting this check box prevents addresses without fully-qualified domain names (FQDNs) from connecting to the proxy server.
Do not use proxy server for address beginning with | This box is used to enter addresses that should not go through the proxy server.
This proxy server requires authentication | Some proxy servers require credentials in order to connect to them. This box enables the AD RMS server in the cluster to authenticate with the proxy server.
Authentication type | The authentication type used to connect to the proxy server. The authentication type can be Basic, Digest, or Integrated Windows.
User name | User name of the account that is used to authenticate to the proxy server.
Password Confirm Password | Password of the account that is used to authenticate to the proxy server.
Domain | Domain name where the user account that is used to authenticate to the proxy server resides.

Additional reference

  • Change AD RMS Proxy Settings


Cluster - Cluster Properties - Logging Tab

Parameter | Details
Enable logging | Enables and disables AD RMS logging.
Logging database | Name of the logging database.
Logging service name | Name of the Windows service on the AD RMS server that sends logging messages to the logging database. By default, this service is named ADRmsLoggingService.
Logging queue name | Name of the Message Queuing queue on the AD RMS server that holds messages before they are sent to the logging database.

Additional reference

  • Turn on or Turn off Logging


Cluster - Cluster Properties - SCP Tab

Parameter | Details
Registered service domain | The fully-qualified domain name that this AD RMS cluster serves.
Current SCP | URL that is currently present in the domain specified for connecting to AD RMS services. If another AD RMS installation was present in this domain, this object can still be identified with that connection URL.
Change SCP | Allows you to change or create the AD RMS service connection point (SCP).
Set SCP to current certification cluster | Provides a means for you to update the SCP when your AD RMS clusters change or to register the SCP for the first time.
Remove current SCP | Select this option to remove the current SCP from Active Directory Domain Services (AD DS).

Additional reference

  • Register a Service Connection Point


Trust Policies - Trust Policies Results Pane

Trust policies are designed to help you establish a trust relationship between your AD RMS infrastructure to an AD RMS infrastructure in another domain or organization's infrastructure.

Additional references

  • Establishing Trust Policies

  • Understanding AD RMS Trust Policies


Trust Policies - Trusted User Domains - Trusted User Domains Results Pane

By default, an AD RMS cluster does not service requests from users with a rights account certificate (RAC) that was issued by a different AD RMS cluster. However, you can add user domains to the list of trusted user domains, which allows AD 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 cluster for this Active Directory Domain Services (AD DS) forest from the trusted user domains. Every AD RMS server in a deployment trusts the root cluster in its own forest.

The Trusted User Domains results pane lists the trusted user domains for the cluster.

Additional reference

  • Export a Trusted User Domain

  • Add a Trusted User Domain

  • Understanding AD RMS Trust Policies


Trust Policies - Trusted User Domains - Trusted User Domain Certificate

Parameter | Details
Export Trusted User Domain | Export a server licensor certificate (SLC) to a file that can be imported into another AD RMS cluster as a trusted user domain.
Properties | Configure the properties of the selected trusted user domain to give greater control of the trust level of user accounts.
Delete | Stop trusting users from a domain. You cannot remove the core SLC of your installation, which named Enterprise by default.

Additional references

  • User Interface: AD RMS


Trust Policies - Trusted User Domains - Trusted User Domain Properties

This properties sheet contains the following tabs:

  • Trusted User Domains tab

  • Trusted E-mail Domains tab

Trusted User Domains tab

Parameter | Details
Display name | Display name of the trusted user domain (TUD). This name is assigned when the TUD is imported from another root cluster.
Type | Identifies whether the certificate is internal or external to the AD DS forest.
Expiration | Date that the imported TUD will expire.
Enable licensing to SIDs for these e-mail domains | Gives the option to issue licenses to SIDs as opposed to using just the E-mail address attribute in AD DS.

Trusted E-mail Domains tab

Parameter | Details
Trust all e-mail domains | This default setting allows all e-mail domains contained in the TUD to acquire AD RMS licenses and certificates.
Trust only specified e-mail domains | Use this option when not all e-mail domains in the TUD should be trusted. All trusted e-mail domains must be added to this list.
Trusted e-mail domains | List of all trusted e-mail domains in the TUD.

Additional references

  • User Interface: AD RMS


Trust Policies - Trusted User Domains - Import Trusted User Domain Wizard

Parameter | Details
Trusted user domain file | Path to the trusted user domain file to be imported
Display name | Name for the trusted user domain that will be displayed in the Active Directory Rights Management Services console

Additional reference

  • User Interface: AD RMS


Trust Policies - Trusted Publishing Domains - Trusted Publishing Domains Results Pane

A trusted publishing domain allows one AD RMS cluster to issue use licenses against publishing licenses that were issued by a different AD RMS cluster. You add a trusted publishing domain by importing the server licensor certificate and private key of the server to trust.

The Trusted Publishing Domains results pane lists the trusted publishing domains for the cluster.

Additional references

  • Export a Trusted Publishing Domain

  • Add a Trusted Publishing Domain

  • Understanding AD RMS Trust Policies


Trust Policies - Trusted Publishing Domains - Trusted Publishing Domain Certificate

Parameter | Details
Export Trusted Publishing Domain | Export a server licensor certificate (SLC) to a file that can be imported into another AD RMS cluster as a trusted publishing domain.
Properties | Configure the properties of the selected trusted publishing domain.
Delete | Stop trusting publishing domains. You cannot remove the core trusted publishing domain, which is the name of the AD RMS cluster by default.

Additional references

  • User Interface: AD RMS


Trust Policies - Trusted Publishing Domains - Trusted Publishing Domain Properties

Parameter | Details
Display name | Display name of the trusted publishing domain
CSP | Cryptographic service provider (CSP) used to protect the AD RMS cluster key
Key container | Key container on the CSP in which the AD RMS cluster key is stored

Additional references

  • User Interface: AD RMS


Trust Policies - Trusted Publishing Domains - Import Trusted Publishing Domain Wizard

Parameter | Details
Trusted publishing domain file | Path to the trusted publishing domain file to be imported
Password | Specify a password to decrypt the trusted publishing domain file. This password must match the password specified when the trusted publishing domain file was exported from another AD RMS cluster.
Display name | Name for the trusted publishing domain that will be displayed in the Active Directory Rights Management Services console

Additional reference

  • User Interface: AD RMS


Trust Policies - Trusted Publishing Domains - Export Trusted Publishing Domain Wizard

Parameter | Details
Publishing domain file | Path to the trusted publishing domain you are exporting
Password Confirm Password | Type a strong password that is used to encrypt the trusted publishing domain file
Saved as V1 trusted publishing domain file | Select this check box if the trusted publishing domain will be imported into an earlier version of Rights Management Services (RMS).

Additional references

  • User Interface: AD RMS


Trust Policies - Federated Identity Support - Federated Identity Support Results Pane

Parameter | Details
Federated Identity certificate validity period (days) | Displays the number of days a rights account certificate (RAC) is valid once it is issued to federated identities.
Federated Identity certificate service URL | Displays the URL of the federated resource partner that all federated identity certification requests will go to. When this value is not set, the certification request is handled by the AD RMS cluster.
Allow proxy email address | Displays whether or not proxy e-mail addresses are allowed to consume rights-protected content.
Change Federated Identity Support | Click this link to change AD RMS federated identity support options.

Additional references

  • User Interface: AD RMS


Trust Policies - Federated Identity Support - Federated Identity Support Properties

Parameter | Details
Federated Identity certificate validity period (days) | Enter the validity periods for federated identity rights account certificates (RACs). The value must be within the range of 1 to 9,999 days.
Federated Identity certificate service URL | Select https:// and enter a different server cluster URL that should issue RACs to all federated identities requesting RACs form this server. Use default Federated Identity Certificate Service URL is select to enable this server to issue federated identity RACs.
Allow proxy email address | Select this check box to enabled and disable trust of proxy address of a federated identity.

Additional reference

  • User Interface: AD RMS


Trust Policies - Microsoft Federation Gateway Support - Microsoft Federation Gateway Support Results Pane

The Microsoft Federation Gateway is an identity service that runs over the Internet and mediates between an organization and the external services that the organization wants to use. The gateway acts as a hub for many of the connections the organization wants to make with applications built on Windows Azure or to a Microsoft application that is running on the Internet. The gateway connects users and other identities to the services that it works with, so that an organization only has to manage a single identity-federation relationship in order to enable its identities to access all Microsoft and Microsoft-based services they want to use. enables Active Directory Rights Management Services (AD RMS) to accept tokens from the Microsoft Federation Gateway to authenticate users for certification and licensing.

The Microsoft Federation Gateway Support results pane shows the status of Microsoft Federation Gateway Support for the cluster.

Additional reference

  • Configuring Microsoft Federation Gateway Support

  • Understanding the Microsoft Federation Gateway

  • Understanding AD RMS Trust Policies


Trust Policies - Enroll Cluster with the Microsoft Federation Gateway - Enroll AD RMS Cluster with the Microsoft Federation Gateway Wizard

Parameter | Details
Select SSL Certificate | The secure sockets layer (SSL) certificate assigned to the Web site that hosts the Active Directory Rights Management Services (AD RMS) cluster. For more information about the requirements for the SSL certificate, see Important considerations for installing AD RMS with Microsoft Federation Gateway Support.

Additional references

  • Understanding the Microsoft Federation Gateway

  • User Interface: AD RMS


Trust Policies - Configure Microsoft Federation Gateway Support - Update Microsoft Federation Gateway Support

Parameter | Details
Update Microsoft Federation Gateway settings | Click to update a certificate that is used with the Microsoft Federation Gateway.
Update token decryption certificate | Select this check box if you want to update the SSL certificate that is used to enroll with the Microsoft Federation Gateway. For information about the requirements for this certificate, see Important considerations for installing AD RMS with Microsoft Federation Gateway Support.
Update Microsoft Federation Gateway certificate | Select this check box to force the Microsoft Federation Gateway to update the certificate it uses to verify its identity.
Select SSL certificate | If the indicated certificate is not the secure sockets layer (SSL) certificate of the Active Directory Rights Management Services (AD RMS) cluster, click Browse to select the correct certificate.
Terminate Federation Relationship | Cancel enrollment with the Microsoft Federation Gateway.

Additional references

  • User Interface: AD RMS


Trust Policies - Enroll Cluster with the Microsoft Federation Gateway - Summary

If you ran the wizard to enroll with the Microsoft Federation Gateway, you should list the domains that you want to allow or to block from receiving certificates and licenses from your AD RMS cluster. For more information see Manage the Microsoft Federation Gateway Publishing Filter List and Manage the Microsoft Federation Gateway Licensing Filter List.

If you ran the wizard to update the token decryption certificate, perform the task described in Grant the AD RMS Service Group Permission to the SSL Certificate.

Additional references

  • Understanding the Microsoft Federation Gateway

  • User Interface: AD RMS


Trust Policies - Microsoft Federation Gateway Support - Add Microsoft Federation Gateway Support Wizard

This wizard adds Microsoft Federation Gateway Support to an Active Directory Rights Management Services (AD RMS) cluster. After adding Microsoft Federation Gateway Support, you must enroll the cluster with the Microsoft Federation Gateway and then enable Microsoft Federation Gateway Support. For more information, see Checklist: Deploying AD RMS with Microsoft Federation Gateway Support.

Additional references

  • User Interface: AD RMS


Trust Policies - Microsoft Federation Gateway Support - General

Parameter | Details
Microsoft Federation Gateway RAC validity period (days) | Specifies how long (in days) the Microsoft Federation Gateway rights account certificate (RAC) remains valid.

Additional references

  • User Interface: AD RMS


Trust Policies - Microsoft Federation Gateway Support - Publishing Domains

Parameter | Details
Add | To add an item to the filter list, type the domain in the form domain.com or an asterisk (*) and then click Add.
Delete | Removes the selected item from the filter list.

Additional references

  • User Interface: AD RMS


Trust Policies - Microsoft Federation Gateway Support - Licensing Domains

Parameter | Details
Filtering mode | Specifies whether the Active Directory Rights Management Services (AD RMS) cluster will allow or block the issuing of licenses to the users and domains in the filter list.
Add | To add an item to the filter list, type the user’s e-mail address in the form user@domain.com or the domain in the form domain.com and then click Add. You can also use an asterisk (*) to specify all users and domains.
Delete | Removes the selected item from the filter list.

Additional references

  • User Interface: AD RMS


Trust Policies - Microsoft Federation Gateway Support - Remove Microsoft Federation Gateway Support Wizard

This wizard removes Microsoft Federation Gateway Support from the Active Directory Rights Management Services (AD RMS) cluster. Previously configured settings, such as enrollment with the Microsoft Federation Gateway and certification and licensing block lists, are retained in case you need to add Microsoft Federation Gateway Support again.

Additional references

  • User Interface: AD RMS


Rights Policy Templates - Rights Policy Templates Results Pane

Rights policy templates are XML documents that establish a predefined set of rights for protected content. For example, you can establish a template that is used for intellectual property content that restricts the ability to copy or modify to all users except the content owner.

Additional reference

  • Understanding Rights Policy Templates


Rights Policy Templates - Rights Policy Templates Properties

The current export location of the rights policy templates for the cluster is displayed in the properties of the Rights Policy Templates node in the Active Directory Rights Management Services console.

Parameter | Details
Current templates file location | Displays the current location where the rights policy templates files are stored.
Enable export | Select this check box if you are exporting the rights policy template to a shared folder.
Specify templates file location (UNC) | Type the UNC path to the shared folder in which the rights policy templates will be stored in the format \\server\share.

Additional reference

  • Specify the Location of Rights Policy Templates


Rights Policy Templates - Template

You can perform the following actions on an existing rights policy template:

  • Archive. You can make a template unavailable for use by clients to encrypt new content, but the server can continue to use the template to issue use licenses for existing content that was published against the template.

  • Copy. You can duplicate an existing rights policy template. This duplicate can then be modified as needed.

  • View Rights Summary. You can see which rights are defined for users and groups in the template.

  • Delete. You can delete a template if it is no longer in use. Unlike archiving a template, deleting a template ensures that use licenses are not issued for existing content that was published against the template.

  • View Properties. You can modify the settings of an existing rights policy template through its property sheets. All of the settings that were available when the template was created are available for modification.

Additional references

  • Archive a Rights Policy Template

  • View a Summary of User Rights for a Rights Policy Template

  • Delete a Rights Policy Template


Rights Policy Templates - Create Distributed Rights Policy Template Wizard - Add Template Identification Page

The Identification page of the rights policy template wizard provides the following information about the template:

Parameter | Details
Language | A template can support multiple languages if your organization has clients in different countries/regions or a diverse set of users that use multiple languages within your organization. The template language defaults to the language used on the first AD RMS server in the cluster.
Name | The name that is displayed to the user and to the administrator when the template is selected. The template can support one name per language.
Description | The explanatory text that is displayed to the user and to the administrator when the template is selected. The template can support one description per language.

Additional reference

  • Create a New Rights Policy Template


Rights Policy Templates - Create Distributed Rights Policy Template Wizard - Add User Rights Page

Parameter | Details
Users and rights | Contains the users or groups, specified by their e-mail address, that are granted rights by this template. The accounts must be present in Active Directory Domain Services with the associated e-mail attribute.
Rights for <users> | Each user or group has a set of rights that are defined for that entity in the rights policy template.
Grant owner (author) full control right with no expiration | Select this check box if you do not want the author of the rights-protected document to have an expiration date.
Rights request URL | This URL can be configured to grant user requests for additional rights.

Additional reference

  • Create a New Rights Policy Template


Rights Policy Templates - Create Distributed Rights Policy Template Wizard - Rights Policy Template - Specify Expiration Policy Page

Parameter | Details
Never expires | Default option. This option enables the user to access the content for as long as it is available.
Expires on the following date (UTC) | You can specify a date and time on which the content expires, meaning that a use license that has been granted expires on that date, and that a user cannot acquire a use license for the content after that date. The date and time are expressed as Coordinated Universal Time (UTC), also known as Greenwich Mean Time.
Expires after the following duration (days). | You can specify the number of days after publication after which a user cannot acquire a use license for the content.
Expires are the following duration (days). This is for use licenses. | Used for assigning an expiration date to the use license. You can specify the number of days that a use license is valid after it has been granted to a user. After that time period has passed, the user will have to obtain a new use license from the server.

Additional reference

  • Create a New Rights Policy Template


Rights Policy Templates - Create Distributed Rights Policy Template Wizard - Specify Extended Policy Page

Parameter Details

Enable user to view protected content using a browser add-on

This option controls whether or not the content can be viewed in a browser that is capable of displaying rights-protected content. Even if this option is selected, the AD RMS-enabled application that created the content must also support viewing of this rights-protected content. If you do not select this option, protected content must be viewed by using the application that created it.

Require a new license key every time content is consumed (disable client-side caching)

This option controls whether or not users must acquire a new use license each time they attempt to consume content that was published by using this rights policy template. If this option is not selected, the client can use a cached version of the use license to consume rights-protected content.

If you select this option, note that it requires users to be connected to the network each time they consume content that was published by using this rights policy template.

If you would like to specify additional policies for your AD RMS-enabled application, you can specify them here as name-value pairs.

This option allows you to customize a policy based on a specific AD RMS-enabled application. If you select this policy, you must also add the unique name and value pair required by the application to the template.

Additional reference

  • Create a New Rights Policy Template


Rights Policy Templates - Create Distributed Rights Policy Template Wizard - Specify Revocation Policy Page

Parameter | Details
Location where the revocation list is published (URL or UNC) | Provides a path to the revocation list. You can make the revocation list available by using a Web service that can be accessed by using a URL. When a client computer attempts to open rights-protected content that requires a revocation list, the AD RMS-enabled application first queries the local computer for the revocation list and, if the revocation list is not found or is outdated, the application attempts to connect to the URL that is specified in the template properties.
Refresh interval for revocation list (days) | Provides the number of days that a revocation list is valid. If the revocation list downloaded to the client computer is older than the time that is specified, a new revocation list is downloaded.
File containing public key corresponding to the signed revocation list | Provides both the path of the public key whose corresponding private key is used to sign the revocation list.

Additional reference

  • Create a New Rights Policy Template


Rights Account Certificate Policies - Rights Account Certificate Policies Results Pane

Parameter | Details
Validity Period for Standard RACs | Interval that a standard RAC is valid. The default is 365 days.
Validity Period for Temporary RACs | Interval that a temporary RAC is valid. The default is 15 minutes.

Additional references

  • Specify the Rights Account Certificate Validity Duration


Rights Account Certificate Policies - Rights Account Certificate Policies Properties - Standard RAC Tab

Parameter | Details
Standard RAC validity period (days) | Type a value between 1 and 9,999 days.

Additional reference

  • Specify the Rights Account Certificate Validity Duration


Rights Account Certificate Policies - Rights Account Certificate Policies Properties - Temporary RAC Tab

Parameter | Details
Temporary RAC validity period (minutes) | Type a value between 0 and 600,000 minutes.

Additional reference

  • Specify the Rights Account Certificate Validity Duration


Exclusion Policies - Exclusion Policies Results Pane

AD RMS is designed to help prevent disclosure of information to unauthorized users. One of the risks inherent in a certificate and license based system is that the certificates or licenses might be compromised and thus provide rights to an unauthorized user. Exclusion policies prevent users, applications, and lockboxes from acquiring certificates and licenses from servers in the cluster. Exclusion policies are different from revocation lists in that revocation affects previously granted licenses and certificates from being able to be used to decrypt rights-protected content.

Additional references

  • Understanding AD RMS Exclusion Policies

  • Enabling Exclusion Policies


Exclusion Policies - Users - User Exclusion Policies Results Pane

A rights account certificate (RAC) can be excluded by specifying either the user's e-mail address or the RAC public key string. When you exclude a user’s RAC, AD RMS adds the excluded key, the user’s account name, as well as the date and time of the exclusion to the DRMS_GicExclusionList table of the configuration database for the root cluster.

This results pane lists all of the excluded users of the AD RMS cluster.

Additional references

  • Exclude Users

  • Understanding AD RMS Exclusion Policies


Exclusion Policies - Users - Exclude User Wizard

Parameter | Details
Use this option for excluding rights account certificates of internal users who have an Active Directory Domain Services account | Select this option to exclude the user's RAC by e-mail address.
Use this option for excluding rights account certificates of external users who do not have an Active Directory Domain Services account. | Select this option to exclude the user's RAC by the user's public key.
Public key string | Enter the public key string of the RAC to be excluded.
Note

If you want to exclude a user who does not have an Active Directory Domain Services account, such as a Windows Live ID, or a federated identity, or a user who is not part of the Active Directory forest in which AD RMS is installed, you must exclude the RAC by using the value of the user's public key.

Additional references

  • Exclude Users

  • Understanding AD RMS Exclusion Policies


Exclusion Policies - Applications - Application Exclusion Policies Results Pane

AD RMS-enabled applications can be excluded by their file name and version number. You do this to make sure that users install a newer version of an application when it becomes available.

Additional references

  • Exclude Applications

  • Understanding AD RMS Exclusion Policies


Exclusion Policies - Applications - Exclude Application Wizard

Parameter | Details
Application file name | File name of the application to be excluded
Minimum version | Minimum version of the application
Maximum version | Maximum version of the application

Additional references

  • Understanding AD RMS Exclusion Policies

  • Exclude Applications


Exclusion Policies - Applications - Excluded Application Results Pane

Parameter | Details
Properties | Includes the application name, minimum version, and maximum version. You can modify the application name and the version numbers that make up the exclusion range while the exclusion policy is in effect.
Delete | If you no longer need to exclude an application, you can delete it from the exclusion list.

Additional references

  • Exclude Applications

  • Understanding AD RMS Exclusion Policies


Exclusion Policies - Applications - Excluded Application Properties

Parameter | Details
Application file name | File name of the excluded application
Minimum version | Minimum version of the application
Maximum version | Maximum version of the application

Additional references

  • Exclude Applications

  • Understanding AD RMS Exclusion Policies


Exclusion Policies - Lockbox - Lockbox Results Pane

Parameter | Details
View recommended minimum lockbox version | This option connects to the Windows AD RMS Activation Service Web site (http://go.microsoft.com/fwlink/?LinkId=12995) and displays the current recommended lockbox version number. This number can be used to set the minimum lockbox version.

Additional references

  • Exclude Lockbox Versions

  • Understanding AD RMS Exclusion Policies


Exclusion Policies - Lockbox - Lockbox Properties

Parameter | Details
View recommended minimum lockbox version | This option connects to the Windows AD RMS Activation Service Web site (http://go.microsoft.com/fwlink/?LinkId=12995) and displays the current recommended lockbox version number. This number can be used to enable lockbox exclusion.
Minimum lockbox version | This box allows you to set the minimum lockbox version that servers in AD RMS clusters will grant each RAC and use license to AD RMS clients, in the format X.X.X.X, where X is equal to a numeric value.

Additional references

  • Exclude Lockbox Versions

  • Understanding AD RMS Exclusion Policies


Security Policies - Security Policies Results Pane

Parameter | Details
Change super user settings | This option allows you to enable or disable the AD RMS super users group. This group can decrypt all content published by the cluster.
Reset password | The cluster key password is used to protect the private key of the AD RMS cluster if the cluster's private key is being centrally managed by AD RMS.
Change decommissioning settings | The decommissioning feature is used before you remove AD RMS from your infrastructure and you need to decrypt all of the content that was protected by AD RMS.

Additional references

  • Set up a Super Users Group

  • Reset the AD RMS Cluster Key Password

  • Decommission AD RMS


Security Policies - Super Users - Super Users Results Pane

Parameter | Details
Change super user group | The super users group has no members by default. You can specify an Active Directory Domain Service (AD DS) universal group to use as the super users group for AD RMS, either an existing AD DS group or a new group created for this purpose in the same forest as the AD RMS installation. An e-mail address associated with this group is required.

Additional references

  • Set up a Super Users Group.


Security Policies - Super Users - Super Users Properties

Parameter | Details
Super user group | The e-mail address of the Active Directory Domain Services (AD DS) super users universal group, which is in the same forest in which AD RMS is installed.
Note

As a security best practice, the AD DS group assigned as the AD RMS super users group should be an AD DS restricted group.

Additional references

  • Set up a Super Users Group


Security Policies - Cluster Key Password Results Pane

Parameter | Details
Change cluster key password | Use this option to reset the cluster key password only if the key protection method is AD RMS centrally managed. If you reset the cluster key password, you must reset the cluster key password on every AD RMS server in the cluster. If you do not, those servers will be unable to decrypt the server key in the configuration database.

Additional references

  • Reset the AD RMS Cluster Key Password

  • Understanding AD RMS Key Protection and Storage


Security Policies - Cluster Key Password - Cluster Key Password Properties

Parameter | Details
Password Confirm password | Enter the new password used to protect the cluster key. This should be a strong password.

Additional reference

  • Reset the AD RMS Cluster Key Password


Security Policies - Decommissioning Results Pane

When you decommission AD RMS, the behavior of the AD RMS cluster is changed so that it can provide a key that decrypts the rights-protected content that it had previously published. This key allows the content to be saved without AD RMS protection. This can be useful if you have decided to stop using AD RMS protection in your organization.

Additional references

  • Decommission AD RMS

  • Remove the AD RMS Server Role


Reports - Reports Results Pane

Parameter | Details
Statistics Reports | Lists the number of total accounts, domain accounts, and federated identities certified, or granted a rights account certificate (RAC), by your AD RMS root cluster.
Health Reports | Provides information about the overall health of the AD RMS cluster by using a wizard. The System Health report has two views: Request Type Summary and Request Performance Summary.
Troubleshooting Reports | Assists you in troubleshooting issues with AD RMS licenses by using a wizard.
Note

To access the System Health and Troubleshooting reports, you must install the Microsoft Report Viewer (http://go.microsoft.com/fwlink/?LinkId=83215).

Additional reference

  • User Interface: AD RMS