Understanding AD RMS Across Forests
Updated: December 30, 2007
Applies To: Windows Server 2008 R2, Windows Server 2012
If you are deploying AD RMS in an environment with multiple Active Directory Domain Services (AD DS) forests, you need to determine what support might be required for users or groups who are outside of the forest in which AD RMS is deployed. AD RMS uses AD DS to identify users and distribution groups. When an organization’s AD DS deployment includes multiple forests, AD RMS uses AD DS contact objects to obtain the identities of users and groups that are part of a different forest than the AD RMS cluster. The problem is that user or group objects from other forests do not typically have representative objects that are in the forest where AD RMS resides. If you intend to use AD RMS to restrict permissions to users or groups who are from other forests, you need to configure your Active Directory forest appropriately to allow group expansion to occur across forests.
You can implement group expansion support across forests for AD RMS in two ways:
Deploy an AD RMS cluster into the forest where the groups are defined, and where it will be used to expand the membership of these groups. AD DS Universal groups should be used so that the group membership is replicated to every global catalog server in the forest. Schema extensions must exist in forests that contain contact objects that allow the schema extensions to point back to the forests that contain the actual objects. If schema extensions are not used, client registry overrides are required.
Synchronize group definitions among forests to allow the local AD RMS installation to determine the complete group membership for any user. If the user who is requesting a use license has a Windows account in a separate forest, there also must be a contact object in the local forest to represent that user’s group membership.