Trusted User Domain

Applies To: Windows Server 2008, Windows Server 2008 R2

By default, Active Directory Rights Management Services does not service requests from users whose RACs were issued by a different AD RMS cluster. However, you can add AD RMS domains to a list of trusted user domains in an AD RMS cluster. This allows Active Directory Rights Management Services to process such requests.

A trusted user domain, often referred as a TUD, is a trust between AD RMS clusters that instructs a licensing server to accept rights account certificates (the certificates identifying users) from another AD RMS server in a different Active Directory forest. An AD RMS trust is not the same as an Active Directory trust, but it is similar in that it refers to the ability of one environment to accept identities from another environment as valid subjects.

As a TUD is a trust between AD RMS infrastructures, it requires that each forest (whether in the same company or in different companies) has its own AD RMS infrastructure.

Using trusted user domains, AD RMS can process requests for use licenses from users whose rights account certificates were issued by an AD RMS installation in a different Active Directory forest; in other words, from a different certification cluster. Trusted user domains are added by importing the server licensor certificate, of the AD RMS installation to trust, to the trusting AD RMS installation.

For each trusted user domain, you must specify which e-mail domains are trusted. It is an important security step to configure e-mail domains, otherwise it may be possible for a user from a trusted user domain to impersonate an internal user.

To add an AD RMS installation to the list of trusted user domains, the server licensor certificate (SLC) for the trusted AD RMS cluster must be imported. The administrator for the trusted domain must first export the SLC from the server or cluster to trust and send the certificate file to the administrator of the trusting AD RMS installation. The certificate can then be imported by specifying the file location. The private key information is not transferred when you set up a trusted user domain.

Trusted user domains are unidirectional, so if it is necessary that users in each forest access documents protected inside the other forest, it is necessary to establish a bi-directional trust by performing the aforementioned process twice, once for each forest.

It must be highlighted that the process of establishing a trust is performed offline, and no direct connection is required between the AD RMS clusters, or their AD forests. However, in order to access protected content in the other forest, a user must have access to the licensing cluster that issued the publishing license, so the AD RMS infrastructure of the trusting side (the one publishing the content) must be accessible from the Internet (or through a private network). This can be achieved through any of the solutions detailed in the corresponding section.

While a TUD can be established in environments where an Active Directory forest trust is not implemented between domains, in the case where both forests are part of the same organization it can be advantageous to establish an AD forest trust, in addition to an AD RMS trust. By establishing a forest trust, you can authenticate remote users with their own credentials, rather than enabling anonymous access to the corresponding pipeline URL in the trusting AD RMS server.

A forest trust enables group expansion capability, which makes applying rights to documents targeted at large audiences much easier. Without a forest trust in place, enabling group expansion requires significant additional work for synchronizing group membership between forests.

To enable group expansion across forests through a Trusted User Domain, some extra work is needed. First, the Service Account of the trusting AD RMS cluster needs to be granted rights on the Group Expansion pages on the trusted RMS cluster (groupexpansion/groupexpansion.asmx in IIS).

Additionally, in order for AD RMS to know where to go to perform group expansion for a certain group not in the local forest, it needs to be able to locate the corresponding forest and the AD RMS cluster in that forest. Creating a group contact in the forest containing the trusting AD RMS cluster for each destination group in the other forest can provide a pointer to the correct location for each group. The groups need to have two attributes set. The email attribute in the group contact must match the email attribute of the corresponding group in the target forest, and the msExchOriginatingForest attribute must be set to the fully qualified domain name of the destination forest. With these two values set, the trusting AD RMS cluster will know that there’s a group with that email address defined in the destination forest, and will know where to find it. No other properties need to be set in the contact.

Once AD RMS has located the right forest for the desired group, it will query the Service Connection Point in that forest and obtain the location for the AD RMS certification cluster in that forest, and ask that cluster to perform remote group expansion for the group.

In the case of a multiple-forest environment in a single organization, you can synchronize the global address lists between forests to enable easier identification of recipients by content creators. Microsoft Identity Lifecycle Manager 2007 or the Identity Integration Feature Pack (IIFP) can be used to provide GAL synchronization between forests.