AD RMS Design Guide

Active Directory Rights Management Services (AD RMS) for the Windows Server 2008 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 the 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 the rights merely
residing on 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, including 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, making 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.

About This Guide

This guide is intended for use by infrastructure specialists, system architects, system administrators and system
engineers. It provides valuable reference information for successfully designing and deploying AD RMS in your
organization. It assumes that you are familiar with AD RMS and the concepts that have are presented in the
Getting Started documentation. If you are not familiar with these documents, it is recommended that you start on
TechNet with the Active Directory Rights Management Services Overview (http://go.microsoft.com/fwlink/?
LinkID=153309).

You can then use this guide to help select and deploy your AD RMS design in your production environment. This
guide provides information for helping to identifying what type of design best fits your organization and on
deploying any of the following AD RMS designs:

 Certification and Licensing

 Additional Licensing-only Clusters

 Trust Policies – Trusted User Domains and Publishing Domains

 Identity Federation Support

  External Access using VPN and Firewall Services

AD RMS Deployment Components

This section will review the various components that make up an AD RMS deployment. The following diagram
shows the components of an AD RMS deployment.

 AD RMS Certification Server Cluster. The primary server in an AD RMS deployment is used for running
administration, account certification, licensing, and publishing services. There can only be one certification
cluster per Active Directory forest, which means that for each Windows Active Directory Forest.

 AD RMS Licensing-only Cluster These are optional servers 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.

 SQL Database. This is the component that stores AD RMS-critical information and log data, comprising of
configuration, directory services, and logging databases.
  Active Directory Domain Services. AD RMS relies on this directory service to identify users and groups.
The AD RMS service is registered in the directory to allow clients to discover the URL of the certification
cluster.

 Active Directory Rights Management Services Client. This will consist of the AD RMS Client software,
working together with AD RMS-enabled applications such as Microsoft Office 2007.

The above covers the basic requirements for an AD RMS solution. For additional information, see the related topics
section

AD RMS with Active Directory Domain Services and Networks

The following sections describe various environmental considerations that need to be taken into account when
developing an AD RMS design.

AD RMS Active Directory Design Considerations

AD RMS requires Active Directory to manage users and groups to assign specific privileges to the documents. The
healthy management of Active Directory is critical for an AD RMS deployment.

When designing your AD RMS environment, you should consider the following aspects of your Active Directory
implementation:

 The scope of an Active Directory Rights Management Services installation is the Active
Directory forest. If you have users deployed in multiple forests, then each forest requires its own
AD RMS server.

 It is good practice to use a virtual name for Active Directory Rights Management Services
Certification Cluster. Typically this name can be a load balancing cluster name.

 Group expansion across forests in multiple forest environments. Microsoft Identity Lifecycle
Manager 2007 Feature Pack 1 (ILM 2007 FP1) or Identity Integration Feature Pack Service Pack 2 (IIFP
SP2) provides GAL Synchronization between forests. This is required for group expansion across forests
when permissions will be validated.

For additional information on Active Directory Domain Services see Active Directory Domain Services
(http://go.microsoft.com/fwlink/?LinkId=154905).

DNS, FQDN, and Server Name Design Considerations

It is a best practice to use a FQDN CNAME record or an A-record for an AD RMS cluster URL, not the NetBIOS
name. If a CNAME record or an A-record is used and the AD RMS cluster URL changes, you can update the CNAME
record or an A-record to point to the new cluster URL. Otherwise, you must reprovision AD RMS with the new
cluster URL.

It is also a best practice to use a FQDN CNAME or an A-record record for your SQL cluster name when provisioning
AD RMS. This is primarily for disaster recovery purposes.

For AD RMS, you will need to change the following registry key on the SQL server in order to force the SQL server
to use the CNAME record. Change the Value from 0 to 1.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

DWORD: DisableStrictNameChecking

Value: 1
You will need to restart you SQL Server for these changes to take effect.

For additional information on DNS see DNS Technical Reference (http://go.microsoft.com/fwlink/?LinkId=154906).

SSL / TLS Security

It is recommended that Secure Socket Layer / Transport Layer Security (SSL/TLS) is used to provide server
authentication and data encryption for the users connecting to the AD RMS server. SSL is not required but it is
highly recommended in order to encrypt traffic over the wire. If SSL is not used, the traffic will be in clear text.
This will protect the client from man-in-the-middle attacks and ensure the confidentiality of any data collected
during the card management workflows. It is required for ADFS.

SSL requires that your server have a valid SSL certificate installed for the Web site. The required Web Server
certificates may be issued by the customer’s PKI itself or purchased externally. When planning the solution
deployment you should consider how these certificates will be made available to the AD RMS servers.

For information on setting up SSL on IIS 7.0 see, How to Setup SSL on IIS 7.0 (http://go.microsoft.com/fwlink/?
LinkId=154906) and Import an SSL Certificate Using Internet Information Services (IIS) Manager
(http://go.microsoft.com/fwlink/?LinkId=154912).

Windows Firewall
The Microsoft Windows Firewall is a host-based firewall application that is installed and turned on by default in
Windows Server 2008. 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)

The AD RMS cluster must be able to communicate with an Active Directory Global Catalog server. The following
port exception should be enabled on the Active Directory Global Catalog server to enable the AD RMS cluster to
communicate with it.

Port Exception Description

TCP 3268 Global Catalog Server port

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.
For information on setting using AD RMS with a firewall see, Configure Windows Firewall
(http://go.microsoft.com/fwlink/?LinkId=154913) and AD RMS Firewall Considerations AD RMS Firewall
Considerations (http://go.microsoft.com/fwlink/?LinkId=154916).

AD RMS and Server Design

The following sections describe various server considerations that need to be taken into account when developing
an AD RMS design. These may or may not all apply to your organization or the environment on which you are
working.

Administrative Accounts
To better delegate control of your AD RMS environment, new administrative roles have been created. These
administrative roles are local security groups that are created when the AD RMS role is installed. Each of these
administrative roles has different levels of access to AD RMS associated with them.

The new AD RMS administrative roles give you the opportunity to delegate AD RMS tasks without giving full
administrative control over the entire AD RMS cluster. It is recommended to create Active Directory security groups
for each of these administrative roles and add them to their respective local security groups. This will give you the
ability to scale your AD RMS deployment across several servers without having to add specific user accounts to
each AD RMS server.

The new local security groups are:

 Active Directory Rights Management Services Enterprise Administrators. The AD RMS Enterprise
Administrators role allows members of this group to manage all AD RMS policies and settings. During
AD RMS provisioning, the user account installing the AD RMS server role is added to the AD RMS
 Enterprise Administrators role. As a best practice, membership of this group should be restricted to only
user accounts that need full AD RMS administrative control.

 Active Directory Rights Management Services Template Administrators. The AD RMS Templates
Administrators role allows members of this group to manage rights policy templates. Specifically, AD RMS
Template Administrators can read cluster information, list rights policy templates, create new rights policy
templates, modify existing rights policy template, and export rights policy templates.

 Active Directory Rights Management Services Auditors. The AD RMS Auditors role allows members
of this group to manage logs and reports. This is a read-only role that is restricted to read cluster
information, read logging settings, and run reports available on the AD RMS cluster.

For additional information on AD RMS Administrative roles see Active Directory Rights Management Services Role
(http://go.microsoft.com/fwlink/?LinkId=154909).

For additional information on AD RMS objects in Active Directory Domain Services see AD RMS and Active Directory
Objects (http://go.microsoft.com/fwlink/?LinkId=154911).

Cross-Boundary Collaboration Considerations

AD RMS can extend its services to other organizations or forests. AD RMS manages multi-forest scenarios using
trust policies settings. 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 the following trust policies:

 Windows Live ID. Setting up a trust relationship with the Microsoft 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 Windows
Live ID, but the Windows Live ID user will not be able to create content that is rights-protected by the
AD RMS cluster.

 Trusted user domains (TUD). The addition of a trusted user domain allows the AD RMS certification
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 certification cluster. You add a trusted user domain
by importing the server licensor certificate of the AD RMS cluster to trust.

 Trusted publishing domains (TPD). 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.

 Active Directory Rights Management Services with ADFS. Establishing a federated trust between
two forests is done by using Active Directory Federation Services. This can also be useful if one forest
does not have AD RMS installed, but its users need to consume rights-protected content from another
forest. This is the recommended connection method between two partners running Windows Server 2008
or later.

For additional information see Understanding AD RMS Trust Policies (http://go.microsoft.com/fwlink/?

LinkID=154667).
Trusted User Domains (TUD)

By default, AD RMS does not service requests from users whose RACs were issued by a different AD RMS
installation. In some situations, this may become necessary. The following are examples in which you require this.

 One organization may have multiple forests and therefore may have multiple AD RMS installations. Each
AD RMS installation may be configured to trust the other AD RMS installations in the organization by
establishing one another as trusted user domains.

 Two companies may want to establish each other as trusted user domains in order to publish AD RMS-
protected content for one another.

 An organization may want to use RMS to protect content for an external user who does not have access to
an AD RMS system. In this case, a third party, such as Windows Live ID, is required by the external user.

A trusted user domain is an entity that has its own AD RMS installation. That entity can be another forest in your
organization or perhaps a partner’s AD RMS installation. Trusted user domains allow users from that domain to
request a use license from your licensing servers.

To allow these scenarios, AD RMS domains can be added 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.
certification

You can manage trusted user domains as follows:

 Using Windows Live ID . To support external users, you can add the Microsoft online RMS service to the
list of trusted domains. This allows an AD RMS server that is in your company to process licensing
requests received with a RAC that was issued by the Windows Live ID service. This option is not
recommended for business-to-business scenarios, but is useful for business-to-consumer scenarios.

 Managing External Users. To trust external users from another organization's AD RMS installation, you
can add the organization to the list of trusted user domains. This allows servers in an AD RMS cluster to
 process a licensing request that includes a RAC that was issued by an AD RMS cluster in the other
organization.

 Managing Internal Users who are members of different forests. 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 trusted user domains. This allows
servers in an AD RMS cluster that is in the current forest to process a licensing request that includes an
RAC that was issued by an AD RMS cluster in the other forest.

To add an AD RMS installation to the list of trusted user domains, you must import the TUD for the AD RMS
installation that you want to add. The administrator must first export the TUD .bin file from the server or cluster to
trust and send the certificate file to you. For additional information on adding and removing trusted user domains
see Adding and Removing Trusted User Domains (http://go.microsoft.com/fwlink/?LinkId=155018).

Note

After defining a trusted user domain, you should specify which e-mail domains are trusted. It is an important
security step to configure e-mail domains; otherwise it would be possible for a user from a trusted user
domain to impersonate an internal user. It is highly recommended that local e-mail domains be excluded
from trusted user domains.

Important

Please remember that an AD RMS Trust does not require a Windows Forest Trust or connectivity between
AD RMS domains. Also, it is unidirectional (one-way), so if you need to establish a bi-directional trust you
must install each companies TUD file in the others organization. That is, if Contoso and Fabrikam want to
setup a Trusted User Domain bi-directionally between each other, Contoso will have to import Fabrikam’s
TUD file into their AD RMS and Fabrikam will have to import Contoso’s TUD file. Also, without a forest trust,
the benefit of group expansion will not be available.
Remember that there are Windows Integrated Authentication constraints placed on the licensing pipeline within
IIS. In order for a user from another domain to be able to request a use license, the user must be able to
authenticate to your server running IIS. This can be accomplished in several ways such as enabling anonymous
authentication, establishing a Windows trust relationship with the other forest, or using a dummy account for
authentication.

For additional information including how to setup a TUD step-by-step see AD RMS Deployment in a Multiple Forest
Environment Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=154940).
The following is an example of how a trusted user domain works:

1. Contoso exports and sends its TUD to Fabrikam.

2. Fabrikam imports the TUD .bin file it receives from Contoso.

3. Alice@Fabrikam.com sends Bob@Contoso.com an item of RMS-protected content.

4. Bob receives the content and in his attempt to consume it, sends his RAC and the publishing license to the
issuing Licensing Server at Fabrikam.

5. The Licensing Server at Fabrikam is aware that Contoso’s domain is a trusted user domain and can use
the imported TUD to verify Bob’s RAC and issue him a use license.

For additional information on Trusted User Domains see AD RMS TUD Business-to-Business Requirements
(http://go.microsoft.com/fwlink/?LinkId=154924) and Add a Trusted User Domain
(http://go.microsoft.com/fwlink/?LinkId=154925).

Trusted Publishing Domains (TPD)

By default, an AD RMS Licensing Server can issue use licenses for only content where it originally issued the
publishing license. It some situations, this may not be acceptable. The following are examples of when this may be
less than desirable.

 In the event when one cluster running AD RMS is to be retired, users may still want to access previously
protected content that was issued a publishing license by that computer. Servers in other clusters can
then add the to-be-retired server as a trusted publishing domain.

 One company acquires another company.

In order to specify a cluster that is allowed to issue use licenses for content protected by a different cluster, the
first cluster must be defined as a trusted publishing domain. If content was published by another certification
cluster either in your organization, for example, a subsidiary organization in another forest, or in a separate
organization, your AD RMS cluster can grant use licenses to users for this content by configuring a Trusted
Publishing Domain on your AD RMS cluster. By adding a Trusted Publishing Domain, you set up a trust relationship
between your AD RMS cluster and the other certification cluster by importing the Trusted Publishing Certificate of
the other cluster..

This scenario is commonly used when a company acquires another company that already has an AD RMS
implementation in place. With this feature, you can centralize all EUL and CLC issuances to a single point, rather
than via the acquired AD RMS forest or forests.

To add a Trusted Publishing Domain, you must import the Trusted Publishing Certificate, the private key (if the
private key is stored in software rather than in an HSM), and all the rights policy templates for the AD RMS server
or cluster that you want to add. The administrator must first export these items from the cluster to a password-
protected XML file, and then specify the password that is required to decrypt it. You can then import the file into
the new AD RMS cluster. You will need to know the password that the administrator specified on the XML file prior
to importing it. For example, the administrator in Fabrikam would export the information to an XML file. He would
then give this file and the password to the administrator in Contoso. The Contoso administrator would then import
the XML file into his AD RMS cluster.

If the private key is stored in an HSM, you must transfer the private key to the HSM on the trusted server by
following the instructions in the HSM documentation. Depending on the type of HSM that is on each server and the
configuration of the HSM devices, you may not be able to transfer the private key from one HSM to another.
Review the HSM documentation to determine whether you can transfer the private key without losing data in the
destination HSM. If you cannot successfully transfer the private key, you cannot establish a Trusted Publishing
Domain between the two servers.

If you are using an HSM to protect your AD RMS private key and are importing an Trusted Publishing Certificate
from an AD RMS installation that uses software-based private key protection, you must specify a private key
password on the Security settings page of each AD RMS server in the cluster before you attempt to import the
certificate.

You can remove a Trusted Publishing Domain that you added at any time by removing its certificate from the list of
certificates for Trusted Publishing Domains.

Remember that DNS records may have to be modified so that the URL in the publishing licenses of content created
in the trusted publishing domain resolves to an IP for the licensing server of AD RMS installation that setup the
trusted publishing domain.
The following is an example of how a trusted publishing domain works:

1. Fabrikam exports and sends the XML file and the password to Contoso.

2. Contoso provides the password and imports the XML file..

3. Alice@Fabrikam.com sends Bob@Contoso.com an item of RMS-protected content.

4. Bob receives the content and sends his RAC and the publishing license to the issuing Licensing Server at
Contoso.

5. The Licensing Server at Contoso can decrypt the publishing license issued by Fabrikam and confirms that
Bob is a named principal in the publishing license. It then issues the use license to Bob.

For additional information on Trusted Publishing Domains see AD RMS Trusted Publishing Domain Considerations
(http://go.microsoft.com/fwlink/?LinkId=154926) and Add a Trusted Publishing Domain
(http://go.microsoft.com/fwlink/?LinkId=154927).

Federated Identity using Active Directory Rights Management Services ADFS

Increasingly, enterprises are feeling the need to collaborate outside their enterprise boundaries and are looking at
federation as a solution. Supporting federation in AD RMS will allow enterprises to leverage their established
federated relationships to enable collaboration with external entities.

In Windows Server 2008 AD RMS rights can be assigned to users who have federated trust via Windows Active
Directory Federation Services. This will enable an organization to share access to rights-protected content with
another organization without having to establish a separate trust or AD RMS infrastructure.

AD RMS will support issuing certificates and licenses to users who authenticate using ADFS. AD RMS will do so
without breaking existing functionality except for group expansion. For additional information see Group Expansion
for Federated Users (http://go.microsoft.com/fwlink/?LinkId=155023).

ADFS uses terms such as "account partner" and "resource partner" to help differentiate the organization that hosts
the accounts (the account partner) from the organization that hosts the Web-based resources (the resource
partner). The term "federation trust" is used in ADFS to characterize the one-way, non-transitive relationship that
is established between the account partner and the resource partner

For additional information on AD FS see Active Directory Federation Services (http://go.microsoft.com/fwlink/?

LinkId=155025).

For additional information on AD RMS and AD FS see AD RMS and AD FS Considerations

(http://go.microsoft.com/fwlink/?LinkId=154929) and the AD RMS with AD FS Step-by-Step Guide
(http://go.microsoft.com/fwlink/?LinkID=153618).

Additional Components for Multi-forest Environments

This section briefly describes the additional components for multi-forest environments. These components are:

 Identity Lifecycle Manager 2007 Feature Pack 1. ILM 2007 FP1 is a stand-alone product that is
designed to synchronize identity information. It can be used to synchronize GALs between companies
Active Directory directories.

 IIS and SSL. Most traffic between clients and AD RMS Servers are encrypted, but, if you want to prevent
spoofing and completely encrypt transmissions, an SSL certificate should be installed on the AD RMS
cluster. This is particularly important when Extranet/Internet access should be defined because of the
Basic Authentication requirement on AD RMS clusters. SSL can be used to protect both Intranet and
Extranet pipelines.

Important

IIS 7.0 can have a single Certificate per Website - Because IIS 7.0 supports only one certificate per Website,
you should use SSL Bridging technologies in the firewall/gateway, such as ISA Server 2006/2004, in front of
the AD RMS installation.
For additional information on AD RMS and multi-forest environments see Understanding AD RMS Across Forests
(http://go.microsoft.com/fwlink/?LinkID=153538), AD RMS Multi Forest Considerations
(http://go.microsoft.com/fwlink/?LinkId=154930), Checkist AD RMS Multi Forest (http://go.microsoft.com/fwlink/?
LinkID=153541), and AD RMS Deployment in a Multiple Forest Environment Step-by-Step Guide
(http://go.microsoft.com/fwlink/?LinkId=154940). .

For additional information on licensing-only clusters see AD RMS Licensing-only Cluster Deployment Step-by-Step
Guide (http://go.microsoft.com/fwlink/?LinkId=155064).

AD RMS Service Discovery

AD RMS uses the concept of service connection point to allow users to automatically locate the AD RMS certification
server cluster. The service connection point (SCP) for AD RMS identifies the connection URL for the service to the
AD RMS-enabled clients in your organization. The SCP is registered in Active Directory Domain Services (AD DS),
and allows clients to discover the AD RMS cluster to request use licenses, publishing licenses, or rights account
certificates (RACs).

Because several AD RMS architecture scenarios exist, as do several applications that use AD RMS in many different
configurations, Microsoft provides different options to configure/override AD RMS default settings to provide
information about the Certification cluster, licensing-only cluster, and other client specific parameters.

If you want clients to discover an AD RMS certification cluster without using Active Directory or the SCP you can
use the following registry keys on the clients. This may be useful in situations where you want to test AD RMS but
do not want to modify Active Directory.

CorpLicenseServer: Typically Active Directory is used to specify the AD RMS Licensing server used for issuing use
licenses. This setting allows you to override the location of the AD RMS cluster specified in Active Directory for
certification. Can be used when auto-discovery is not available, such as when users do not work inside a LAN with
connectivity to Active Directory, or when using Trusted Publishing Domains to override the license servers that
issued publishing licenses. If present, takes precedence over the settings under MSDRM registry branch for Office
applications.

Copy Code

HKLM\Software\Microsoft\Office\12.0\Common\DRM\
REG_SZ: default
Value: < http(or https)://RMS_Cluster_Name /_wmcs/Licensing>
CorpCertificationServer: Typically Active Directory is used to specify the AD RMS Certification server used for
bootstrapping. This setting allows you to override the location of the AD RMS cluster specified in Active Directory
for certification. Can be used when auto-discovery is not available, such as when users do not work inside a LAN
with connectivity to Active Directory. If present, takes precedence over the settings under MSDRM registry branch
for Office applications.

Copy Code

HKLM\Software\Microsoft\Office\12.0\Common\DRM\
REG_SZ: default
Value: <http(or https)://RMS_Cluster_Name/_wmcs/Certification>
Activation: This registry key defines the URL of the user activation service

Copy Code

HKLM\Software\Microsoft\MSDRM\ServiceLocation\Activation
REG_SZ: default
Value: <http(or https)://RMS_Cluster_Name/_wmcs/Certification>
EnterprisePublishing: This registry key defines the URL of an RMS installation that you want this client to use for
license requests.

Copy Code

HKLM\Software\Microsoft\MSDRM\ServiceLocation\EnterprisePublishing
REG_SZ: default
Value: < http(or https)://RMS_Cluster_Name /_wmcs/Licensing>
The CorpLicenseServer and EnterprisePublishing keys can be used even if you do have an SCP registered, if you
want your clients to use a different licensing server.

For additional information on AD RMS service discovery see AD RMS Client Service Discovery
(http://go.microsoft.com/fwlink/?LinkId=154932) and Register a Service Connection Point
(http://go.microsoft.com/fwlink/?LinkId=154934).

Publishing AD RMS to the Internet

Extranet Access scenarios may require the AD RMS to be available on the Internet for external user access. For
some organizations, the AD RMS cluster availability using the Internet/Extranet access is a mission-critical service
required. Therefore, it is crucial that you provide your customers with stable and reliable AD RMS published
services.

For additional information on deploying AD RMS in an extranet see (Add an Extranet Cluster URL
(http://go.microsoft.com/fwlink/?LinkId=154935), Checklist: Deploying AD RMS in an Extranet
(http://go.microsoft.com/fwlink/?LinkId=154936), and AD RMS Deployment in an Extranet Step-by-Step Guide
(http://go.microsoft.com/fwlink/?LinkId=154938).
AD RMS and Database Design
Servers in the AD RMS cluster are tightly integrated with the database server during provisioning and normal
operations. The AD RMS database server stores critical configuration, logging, and directory services information
for use by AD RMS. It is imperative to understand the information stored in the database and appropriate system
and hardware design for the component.

You can use the Windows Internal Database in Windows Server® 2008 to support a new installation of AD RMS
using a single-server. However we recommend that you use a separate database server such as Microsoft SQL
Server 2005. 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 certification cluster contains a list of Windows user identities
and their rights account certificate (RAC). 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.

 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 (Active Directory DS) global
catalog by the AD RMS licensing service.

 Logging Database

For each certification 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.

High Availability
SQL Server provides two different high availability technologies that can be used in conjunction with AD RMS:

 Failover Clustering

 Log Shipping

Failover Clustering
Failover clustering is the perhaps the most widely deployed technology for SQL high availability. It uses the
Microsoft Cluster Service (MSCS) feature of Windows 2003 to provide availability in the event of an application
failure, hardware failure, or operating-system error.

With failover clustering the entire SQL Server instance runs from a shared disk resource and is accessible from a
virtual IP. During failover another cluster node takes control of the shared disk resource and the virtual IP and
restarts the SQL Server instance.
Failover clustering is supported by both SQL 2000 and SQL 2005, requiring the Enterprise Edition in SQL 2000.
Support for failover clustering in Standard Edition is new in SQL Server 2005, and only two-node failover cluster
instances are allowed using that version of SQL Server, even though the cluster itself might have more nodes

Failover clustering requires special hardware such as a shared disk array and cluster-aware disk controllers. It is
imperative that the hardware and software configuration is on the Hardware Compatibility List (HCL) and
purchased as a cluster solution in order to be supported by Microsoft. See, The Microsoft SQL Server support policy
for Microsoft Clustering (http://go.microsoft.com/fwlink/?LinkId=154594).

Unlike other technologies like log shipping, clustering requires no client-side support for the failover, which
happens transparently to client applications. For all purposes AD RMS treats and works with a clustered database
server exactly the same way it would do with a standard non-clustered server.

Log Shipping
Log Shipping is a technology available in both SQL Server 2000 and SQL Server 2005 that allows the creation of a
warm standby server. Log Shipping automatically copies and restores the database's transaction logs the standby
server, making it an exact duplicate of the original database—out of date only by the delay in the copy-and-load
process. You then have the ability to make the standby server a new primary server if the original primary server
becomes unavailable. When the original primary server becomes available again, you can make it a new standby
server—effectively reversing the servers' roles

The primary server is the production server on which the real work takes place; this server holds the source
database. The secondary server holds the destination database to which you copy and restore the source
database's transaction logs. A monitor server monitors both the primary and secondary servers. Microsoft strongly
recommends that you put the log shipping monitor on its own server.

When the primary database server goes down—as the result of planned maintenance or an unexpected event— an
intact copy is available on the secondary server, which can be brought into production. This is called a log shipping
role change. .

During role change, the connection strings will have to be manually changed on the CLM Web servers and on the
Certification Authorities to point to the new production server. Other than this situation, CLM works transparently
with Log Shipping.

For additional information see, (How to configure security for SQL Server log shipping
(http://go.microsoft.com/fwlink/?LinkId=154596).

Sizing Considerations
The scaling requirements depend on the number of AD RMS users and client PCs, and the number of the RMS-
protected documents that are issued and consumed. Each AD RMS server is capable of handling a set number of
client requests in a set amount of time (approximately 30 to 50 licenses per second). Because of this, adding
servers linearly scales out the total license-issuing capacity of a cluster, and also provides increased reliability. As a
result, scaling should be appropriate not only to each individual server, but also to the number of servers that you
deploy. An in depth look at sizing is beyond the scope of this document. For detailed technical information on
database sizing see the additional information referenced below.

For additional information on the AD RMS database see the related resources section.

See Also
Other Resources
Understanding the AD RMS Databases
AD RMS Performance and Logging Best Practices
AD RMS SQL Server Requirements

AD RMS and Client Design

The AD RMS client is built into the Windows Vista with SP1 operating system so that the AD RMS client is no longer
a separate installation. Operating systems prior to Windows Vista with SP1require installation of the AD RMS client
software. The activation process establishes a lockbox and computer certificate for the currently logged-on user.
Activation is a local process and does not require a network connection. Once activation is successful, the first use
of AD RMS by an enabled application obtains a user certificate for the user.

Deploying these software components to clients can be a challenge for large AD RMS deployments, where manually
installing client software is a non-option. The following software distribution technologies can be used to deploy the
AD RMS client components:

 Microsoft Systems Management Server (SMS) 2003 or Microsoft System Center Configuration
Manager 2007. Organization running SMS 2003 or Configuration Manager 2007 can deploy the AD RMS
client to Windows XP, Windows 2000, and Windows 2003.

 Group Policies (GPOs).. Active Directory GPOs can be used to deploy software packages packaged using
Windows Installer.

The client deployment can be achieved using software distribution infrastructure such as Microsoft Systems
Management Server 2003, System Center Configuration Manager 2007 or Active Directory Group Policy (Software
Distribution). It is recommended to distribute the AD RMS client ahead of or at the same time as any deployment
of Office so that the AD RMS users who try to use the IRM functionality will not be asked to download and install
the AD RMS client software.

For information on how to deploy the AD RMS client see AD RMS Client Deployment and Usage Considerations
(http://go.microsoft.com/fwlink/?LinkID=153312), (AD RMS Client Requirements (http://go.microsoft.com/fwlink/?
LinkId=154947), and AD RMS and Microsoft Office Deployment Considerations (http://go.microsoft.com/fwlink/?
LinkId=154948).

AD RMS 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.

Some examples of rights policy templates are:

 Company Confidential. Such a template could be used to allow only employees to view content, but not
forward, copy, or save the document.

 Expires in 30 days. This could be used to ensure that content is not valid after 30 days. A letter of offer,
an RFP, or perhaps a draft version of a document would be consumable for only a set period of time.

 Must be Connected to Consume. This ensures that recipients have connectivity to a licensing server
and are not using cached copies of a use license to consume content. This could be used in a case in
which a template is subject to change and you want the recipient to consume only the latest version. Also,
if a computer is lost or stolen, the RMS-protected content would not be accessible to the person who
found or stole it.

When AD RMS attempts to verify group membership, the results are cached. This can become an issue if a
document was protected by a template that assigned rights to a particular group. For example, Bob is a user and a
member of the Support group. Bob receives a document that only allows members of the support group to
consume it. Because Bob is already a member of the group, he would be able to consume it. However, if Alice were
then added to that group, she would not be granted access until the Active Directory Domain Services cache
expired. To disable cache settings on Windows Server 2008 there are two possible ways of accomplishing this.
 1. Under the DRMS_Config database access the DRMS_cluterpolicies table and change the value of
PolicyData cell to 0 for UseDirectoryServicesCacheDatabase and EnableNoRightsCaching. This will disable
all database caching.

2. EnableNoRightsCaching is new to AD RMS and is used to cache ‘No rights’ failures. For security purposes,
this allows you to determine who might be trying to access a piece of content that they do not have the
rights to.

To disable only Active Directory caching, under the DRMS_Config database access the DRMS_cluterpolicies
table and change the value of PolicyData cell to 0 for the following:

 DirectoryServicesMemoryPrincipalCacheMaxSize

 DirectoryServicesMemoryGroupIdCacheMaxSize

 DirectoryServicesMemoryGroupMembershipCacheMaxSize

 DirectoryServicesMemoryContactGroupMembershipCacheMaxSize

 DirectoryServicesMemoryPrincipalCacheExpirationMinutes

 DirectoryServicesMemoryGroupCacheExpirationMinutes

Caution

Prior to making any modifications to your AD RMS databases, these databases should be backed up.
To ease administration of the rights policy templates, AD RMS in Windows Server 2008 introduced a rights policy
template creation wizard. To ease distribution of rights policy templates, AD RMS has also introduced a new rights
policy template distribution pipeline. This new pipeline allows an AD RMS client to request rights policy templates
stored on the AD RMS cluster and store them locally on the client computer. This functionality is available with
AD RMS clients in Windows Vista with SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

For AD RMS clients that are not running on Windows Vista with SP1, Windows Server 2008, Windows 7, and
Windows Server 2008 R2, you must manually distribute the rights policy templates from a central location to the
client. Some distribution methods include using Systems Management Server, Group Policy, or manually copying
the templates to the client computer as described at the above section.

For more information on rights policy template configuration and deployment see AD RMS Policy Template
Considerations (http://go.microsoft.com/fwlink/?LinkId=154598).

For more information on setting up rights policy templates see AD RMS Rights Policy Templates Deployment Step-
by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=153712).

AD RMS and Secure Design

Organizations must identify the users who are trusted entities within its AD RMS. To do so, AD RMS issues RM
account certificates that associate user accounts with specific computers. There are two types of RM account
certificates:
  Standard - A standard account certificate enables the user to create, to view, and to use restricted
content on a specific computer. The user can access the restricted content only for the specific number of
days determined by the administrator of the AD RMS server.

 Temporary - A temporary account certificate enables the user to view restricted content on a specific
computer. The user can view the restricted content only for the specific number of minutes determined by
the administrator of the AD RMS server.

Each certificate must be assigned a specific expiration date. The expiration date affects the duration of the users’
ability to access content offline. If it is not specified some users would be able to read the content even though the
domain account had been removed from the Active Directory. The expiration date design is based on the corporate
policy, taking into account human resource and machine replacements, and temporary resource access policy in
the organization. It is recommended that this date be designed carefully.

AD RMS Server Private Key

Although hardware security module-based private key protection can be used within the AD RMS solution and in
most of the time is required for high-secure environments, the preferred method is the default software-based
private key protection. The software-based private key protection requires a strong password, which is used to
encrypt the cluster’s private key.

AD RMS User Authentication

AD RMS user authentication is required when the user reads an RMS-protected document. The AD RMS server
validates the user using Windows integrated authentication. The Windows integrated authentication takes place
when the user acquires the AD RMS account certificate and obtains the user license to read content from an AD
RMS server.

You can also use Smartcards when obtaining RACs and use licenses from the AD RMS server. To configure the AD
RMS server to require client authentication, you need to enable SSL for the Web site on which you provisioned AD
RMS and configure the authentication method in Internet Information Services (IIS).

AD RMS Database Security

The following recommendations are best practices and will increase the overall security of databases within the
network and server environment:

 Run the database server on a computer that is running Windows Server 2008 or Windows Server 2008 R2.

 Restrict access to the database server. Keep it in a location that is physically secure.

 Make sure that the database permissions and discretionary access control lists (DACL) that are on
database files restrict access to authorized personnel. The default permissions and DACLs that are
configured by AD RMS are secure. Use caution when changing any of the default settings.

 Do not run any unnecessary services on the database server, such as Microsoft Internet Information
Services (IIS), Message Queuing, or Terminal Services.

 Do not run any databases on the database server except for the AD RMS databases.

 Secure SQL Server databases by configuring either SSL or Internet Protocol security (IPsec) to provide
encrypted channels. Encrypting database communications helps prevent malicious users from capturing or
modifying logged data. For more information about configuring SSL or IPsec for SQL Server 2005 or SQL
2008, see Encrypting Connections to SQL Server (http://go.microsoft.com/fwlink/?LinkId=154599).