The Official RMS Team Blog

Your official source for all the latest news and tech tips for Microsoft AD RMS and Azure RMS.

Sharing Protected Documents when Partners have an AD RMS Installation

Sharing Protected Documents when Partners have an AD RMS Installation

  • Comments 1
  • Likes

(This post was published on the original RMS team blog in February 2010. This is part 1 of a two-part series.)

Typically, Active Directory Rights Management Services helps users to protect documents and securely share them with other users within a single Active Directory forest.  However, it is increasingly common that users need to share sensitive documents with people outside their organization.  AD RMS has several options available to you to configure secure external collaboration. 

In this two part series we explore the different options available and highlight some common scenarios where they are appropriate.  In this post, we discuss how to share protected content with a partner who has an AD RMS infrastructure.  In a subsequent post, we will look at the different ways to collaborate with a partner who does not have an AD RMS infrastructure.

If you would like to share protected documents with partner users who are in an organization that has installed AD RMS you can configure either a Trusted User Domain (TUD) or a Trusted Publishing Domain (TPD).  Let's look at these two options in more detail.

A Trusted User Domain is the most common method of sharing protected information between two forests that each have AD RMS clusters.  A TUD allows your licensing servers to accept end-use license requests made by users who have been issued a Rights Account Certificate from a partner organization.  When you configure a TUD, users can share protected content across forests using the same tools and processes they would within their organization.  Each user can create protected content with Microsoft Office and other AD RMS-enabled applications and then distribute it through e-mail, Microsoft Office SharePoint Services, Windows Mobile devices, and other distribution channels.    

There are a couple of factors to consider before implementing a Trusted User Domain.  First, when a user opens content protected by the AD RMS partner cluster, the user receives an end-use license directly from that cluster.  Therefore, to open protected content, a user must have connectivity to an AD RMS server in the partner's cluster.  Also to protect information for groups that contain users from your partner's organization you must either create an Active Directory forest trust or perform significant additional work to synchronize group membership between the forests.  If these options cannot be implemented, you must individually grant access to partner users.  Finally, assuming there is no forest trust between the organizations, this scenario requires anonymous authentication to be allowed on the license pipeline.  You should be sure to enable anonymous authentication on only the license.asmx page, not the virtual directory root itself.

To learn more about Trusted User Domains you can read Trusted User Domains and AD RMS Deployment in a Multi-Forest Environment Step-by-Step Guide on TechNet.

Trusted Publishing Domains allow an AD RMS cluster to issue end-use licenses for content that was originally published by a different AD RMS cluster.  Similar to a TUD, a TPD does not restrict the applications and distribution channels that clients use to protect and consume content.  It also presents two advantages.  First, configuring a TPD requires less administrative effort to enable users to protect documents for groups that contain partner users.  Second, you do not need to connect to your partner's AD RMS cluster to consume content, reducing network overhead. 

However, a TPD is established by exchanging AD RMS private keys, in addition to the server licensor certificates.  This can be a security risk.  Although the benefits to configuring a TPD are significant, sharing your private key with another organization may violate your organization's security policy.  Also, in this scenario, you must set registry overrides that will force clients to get use licenses through your AD RMS cluster.  For more information about these registry keys for Microsoft Office, please see the TechNet article Office Registry Settings.

Because of security policies, TPDs are usually configured between forests within the same organization or in a scenario where one of the clusters will be decommissioned.   A TPD allows a cluster to decrypt content it did not publish.  Therefore the original cluster does not have to be accessible in order for partner users to consume content.  By configuring a TPD, users can still access all documents published by the partner cluster, even after that cluster has been decommissioned.

If you would like to learn more about Trusted Publishing Domains you can read the TechNet article Trusted Publishing Domains.

Comments
  • Dear Dan

    I have decided to implement AD RMS in our environment and I looking for information about a specific
    configuration.

    Our internal domain names after: ad.irm
    Our external domain names after: irm.uzh.ch (same for smtp)

    Now I am a little bit confused by the urls and names to configure on ADMRS Cluster and its certificate. The solution must give access to external Users by using AD federation Services.

    Do I need to configure both internal and external URLs or only the external URL of ADFS must be available from the internet as the users outside of company and another organization will use the public URL of the federation services?

    Do I need a public certificate for AD RMS when authorizing external users to access out internal resources by using RMS or only the ADFS external Url must have public certificate?
    this is some kind the same configuration described on https://technet.microsoft.com/en-us/library/dn758110.aspx but with public pkis

    On the public certificate do I need only CN=rms.irm.uzh.ch and SAN DNS=rms.uzh.ch, or do I need the URL=rms.irm.uzh.ch as a SAN as well or something more?

    Unfortunately I have not found enough information in the Technet documentation particularly about the internal / external URLs scenario and the certificate requirements covering this configuration.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment