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 ComponentsThis 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 ConsiderationsAD 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 ConsiderationsIt 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 SecurityIt 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 FirewallThe 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 AccountsTo 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 ConsiderationsAD 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 ADFSIncreasingly, 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 EnvironmentsThis 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 DiscoveryAD 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: defaultValue: < 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: defaultValue: <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\ActivationREG_SZ: defaultValue: <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\EnterprisePublishingREG_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 InternetExtranet 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 AvailabilitySQL Server provides two different high availability technologies that can be used in conjunction with AD RMS:

Failover Clustering

Log Shipping

Failover ClusteringFailover 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 ShippingLog 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 ConsiderationsThe 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 ResourcesUnderstanding the AD RMS Databases AD RMS Performance and Logging Best Practices AD RMS SQL Server Requirements

AD RMS and Client DesignThe 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 TemplatesRights 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 KeyAlthough 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 AuthenticationAD 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 SecurityThe 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).