Deploying RMS Across Forests
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
If your organization includes multiple Active Directory forests and you want to enable the use of RMS throughout your organization, make sure that you have configured your network in such a way that RMS will be able to identify and authenticate user accounts and distribution groups that reside in different forests.
RMS uses Active Directory to identify users and distribution groups. When an organization’s Active Directory deployment includes multiple forests, RMS uses contact objects to obtain the identities of users and groups that are part of a different forest than the RMS server. Three things are necessary to accomplish this:
A RMS root cluster must exist in the other forest, and contact objects must be defined for each remote group.
Schema extensions must exist in forests that contain contact objects that allow them to point back to the forests that contain the actual objects.
Attributes in the contact objects must be synchronized to point back to the forests that contain the actual object.
For example, suppose that groups are defined and managed in one forest and users are defined and managed in another forest. A user wants to rights-protect content based on membership in a certain group. In this scenario, RMS_Server_U is the server in the forest that contains the user accounts and RMS_Server_G is the server in the forest that contains the group accounts. A trusted user domain has been established between these two RMS servers. For RMS_Server_U to successfully expand the group membership that is specified in the publishing license across forest boundaries, a contact object must exist in the local Active Directory forest that represents the group that is in the remote forest. RMS can query the attributes of the contact object and discover that this object represents a group that is in a different forest, it can then look for an RMS root cluster in that forest and determine if a trust relationship exists between itself and the other RMS server. When RMS_Server_U queries Active Directory for the group specified in the publishing license, the contact object will identify that the group belongs in another forest. When RMS_Server_U forwards the request to the RMS server listed in the service connection point (SCP) for that domain. The SCP identifies RMS_Server_G as the RMS root cluster for the domain. RMS_Server_U will then query RMS_Server_G to obtain the membership for the group.
The attribute that RMS queries for this information is msExchOriginatingForest. This attribute is installed by default in the Active Directory schema if you have Microsoft Exchange Server 2003 or later installed in the forest. You must have this attribute in the forest of each Active Directory schema that will be participating in RMS. If you are not using Exchange Server 2003 or later, you can add these schema extensions by downloading the RMS Administration Toolkit. The toolkit contains a schema file and instructions about how to add it to Active Directory.
These attributes must be synchronized so the contact object points to the actual object in the other forests. After the attribute is added to your Active Directory schema, you must configure its value to be the fully qualified domain name (FQDN) of the forest in which the group resides, for example, corp.fabrikam.com.
You can accomplish this by using Microsoft Identity Integration Server (MIIS) 2003 or Identity Integration Feature Pack (IIFP) and the management agent for Active Directory global address list (GAL).
You must enable the local RMS servers in the root cluster (and licensing-only cluster if appropriate) to have sufficient privileges to search the remote Active Directory and call the group expansion pipeline on the remote RMS installation.
Note
The group expansion pipeline is new in RMS with Service Pack 2. In eariler versions of RMS, .NET Remoting calls were used to expand group membership across forests.
To support group expansion across forests, the account used for the RMS service account in each forest must also have read and execute permissions on Active Directory objects. RMS automatically grants read access for Active Directory to all authenticated users who have domain credentials. To increase security, you can remove this access from the discretionary access control list (DACL) and replace it with individual service accounts from the different forests.
Depending on whether Active Directory trust relationships exist between the local and remote forests, the permissions required for the RMS service account may be different. The following list identifies the trust models and the permissions that are required:
Two-way trust exists. The local RMS forest trusts and is trusted by the forest where the group originated. The RMS service account for the RMS server in each forest can be any valid domain account in the forest. Make sure that you add the local RMS service account to the DACL of the \Inetpub\wwwroot\_wmcs\drmRemote folder on all RMS servers that are in the forest from which the group originated.
One-way trust exists. The local RMS forest trusts the forest where the group originated, but is not trusted by that forest. The RMS service account for all the RMS servers that are in the organization should be from a valid domain account that is in the trusted forest. Add this account to the DACL of the \Inetpub\wwwroot\_wmcs\drmRemote folder on all RMS servers that are in the forest from which the group originated.
No trust exists. The forests that are in the organization cannot authenticate users and groups from other forests. It is recommended that you not use group expansion across forests if the forests involved do not have a trust relationship. However, if it is an operational requirement that you do so, you can enable this scenario by configuring the RMS service account as a valid domain account in both forests, using the same user name and password for each. In addition, a local machine account must be created on each RMS server that has the same user name and password as the domain accounts used for the RMS service account in both forests. This will grant the local service sufficient permissions to authenticate to both the remote Active Directory and the remote RMS server.
Using RMS Trust Policies
When RMS is deployed in an organization with multiple forests, an RMS certification server must be deployed in each forest that hosts user accounts participating in the RMS system. If you want users in different forests to be able to share rights-protected content, you need to configure the RMS trust policies so that the certificates and licenses generated by the other RMS cluster can be trusted. There are two trust policies that can be used with RMS, trusted user domains and trusted publishing domains. Trusted user domains enable an RMS root cluster to trust the rights account certificates (RACs) generated by another RMS root cluster and issues use licenses to users with RACs from the other server. Trusted publishing domains enable an RMS server to generate use licenses based on publishing licenses that specify the other RMS cluster.
Some options for how you could use trust policies to support multiple forests are as follows:
An RMS root cluster in each forest with a single licensing-only cluster shared by all users. The RMS licensing-only cluster would be configured with a trusted user domain that included all of the RMS root clusters. The RMS clients would be configured using a registry key to connect to the licensing-only cluster to obtain use licenses.
An RMS root cluster within each forest with a trusted user domain configured on each cluster to trust the RMS root clusters in the other forests. Each user would use the RMS root cluster in their forest to obtain use licenses and could discover their root cluster through the service connection point in Active Directory.
If the consumers of rights-protected content are part of a forest that does not have access to the forest from which the content was published, a trusted publishing domain can be established to enable the content to be licensed and consumed. Trusted publishing domains require that the private key of the RMS root cluster used to publish the content be imported into the root clusters in the other forests.
For more information about configuring trust policy, see “Managing Trust and Trust Policy” in the “RMS: Operations” section of this documentation collection.