Partager via

AD RMS Trusted Publishing Domain Considerations

  • Article

Applies To: Windows Server 2008, Windows Server 2008 R2

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. One such policy is a trusted publishing domain (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 discontinued, 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-discontinued server as a trusted publishing domain.

  • One company acquires another company.

A trusted publishing domain allows for 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.

In order to specify a cluster that can 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 licensing 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 TPD on your AD RMS cluster. By adding a TPD, 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. The following diagram shows the steps involved in using a TPD, followed by an explanation of the interactions.

The following example describes how a trusted publishing domain works:

  1. Fabrikam exports and sends an SLC file and password to Contoso.

  2. Contoso provides the password and imports the SLC 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.

Trusted Publishing Domain Requirements

The following table presents the requirements to implement a solution to allow a trusted publishing domain between Company A and Company B.

Solution Component Detail Description Detail Options

Active Directory Rights Management Services Server Components

RMS Domain in each Forest
  • AD RMS Root Certification Cluster or Licensing Server(s)

  • SQL Server 2008 or 2005 for AD RMS configuration, logging, and directory services databases
  • AD RMS that users will use to acquire AD RMS RACs (GICs), CLCs, PLs, and EULs

AD RMS Client Components

Users protecting and consuming AD RMS documents
  • External and internal Windows Clients used to accessing rights-protected information
  • Microsoft RMS v1.0 SP2

  • Microsoft Rights Management Add-on for Internet Explorer 6 (and Internet Explorer 7)

  • Windows Vista

  • Windows 7

  • IRM Applications

Active Directory Components

Active Directory Forest
  • RMS Usage Restrictions
  • Provides authentication, Service Location, and group membership

ISA Server 2006 (Optional)

Integrated Edge Security Gateway
  • ISA Server Firewall Web Publication and SSL Bridging capabilities
  • Provides Application Layer Filtering and Content Inspection protecting from threats the Published AD RMS architecture

Hardware Security Module (HSM) (Optional)

HSM for AD RMS Key Storage
  • HSM for AD RMS Key Storage
  • Protects AD RMS keys in tamper-proof resistant hardware

Windows Trusts between Forests

Allow authentication and group lookup queries between forests.
  • Allow user and group authentication.
  • Required for this scenario.

DNS Configuration for intranet and extranet pipelines

Define extranet or intranet server or cluster URLs and create DNS records
  • Create DNS configuration entries for Internet or intranet server or cluster URLs. For scalability reasons, this record should be a Cluster ALIAS instead of the physical server name.
  • Use FQDN instead NetBIOS names for both Publication pipelines.

DNS Configuration for Revocation pipelines (optional)

Define revocation pipelines and create DNS records
  • Create DNS configuration entries for revocation. For scalability reasons, this record should be a Cluster ALIAS instead of the physical server name.
  • Use FQDN instead NetBIOS names for this pipeline.

SSL Certificates (optional – highly recommended)

SSL Certificates are not required but are highly recommended for each AD RMS Pipeline. They are required when you deploy with AD FS.
  • In order to prevent spoofing and password capture threats, SSL is used to encrypt the channel. This is not required but is highly recommended for Internet (Extranet) Pipelines in which user credentials are sent using Clear Text.
  • Configure one SSL Certificate for the AD RMS Web site.

Configuration of Trusted User Domain Trust

Required to allow information exchange between companies.
  • This must be configured in both AD RMS installations if rights-protected information will be exchanged both ways. Required to allow for CLC, EUL, and PL issuance.
  • Best practice to consolidate licensing services in the enterprise.

High Availability (recommended)

Because AD RMS is a service that will protect critical information, you should provide high availability in all components.
  • Multiple servers or resources on AD RMS clusters.

  • Multiple servers or resources for SQL server

  • Multiple servers or resources for Active Directory Authentication (domain controllers)

  • Multiple HSM (if used) for root certification cluster availability.
  • Non-single point of failure architecture design.