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. You can define trust policies as follows:

  • Trusted user domains. The addition of a trusted user domain allows the AD RMS root cluster to process requests for client licensor certificates or use licenses from users whose rights account certificates (RACs) were issued by a different AD RMS root cluster. You add a trusted user domain by importing the server licensor certificate of the AD RMS cluster to trust.

  • Trusted publishing domains. The addition of a trusted publishing domain allows 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.

  • Windows Live ID. Setting up a trust with Microsoft’s online RMS service allows an AD RMS user to send rights-protected content to a user with a Windows Live ID. The Windows Live ID user will be able to consume rights-protected content from the AD RMS cluster that has trusted Microsoft’s online RMS service, but the Windows Live ID user will not be able to create content that is rights-protected by the AD RMS cluster.

  • Federated trust. Establishing a federated trust between two forests is done by using Active Directory Federation Services. This is useful if one forest does not have AD RMS installed, but its users need to consume rights-protected content from another forest. For more information about setting up federation support in AD RMS, see Configure Federated Identity Support Settings.

  • Microsoft Federation Gateway. Establishing a trust through the Microsoft Federation Gateway enables an AD RMS cluster to accept certification and licensing requests from external organizations by accepting claims-based authentication tokens from the Microsoft Federation Gateway. In effect, the Microsoft Federation Gateway acts as a trusted broker between the two organizations by verifying the identity of the two organizations in the transaction. Unlike a federated trust, establishing a trust relationship through Microsoft Federation Gateway does not require a forest in one organization to explicitly federate with a forest in the other organization. Instead, you can use filter lists to determine which domains can receive certificates or licenses from the AD RMS cluster.

    For example, Microsoft© Exchange Server 2010 is designed to take advantage of this capability by enabling messages protected by AD RMS to be sent between organizations that do not share an Active Directory Domain Services infrastructure. Exchange Server 2010 incorporates a number of features to support secure messaging by using AD RMS. These features include the following that rely on the Microsoft Federation Gateway:

    • The ability to send AD RMS–protected e-mail messages to a recipient in an organization outside the sender’s organization. The recipient can then access the message by using Exchange Server 2010 Outlook Web Access (OWA) or by using Microsoft Outlook.

    • The ability of a sender to grant a recipient organization that uses Exchange Server 2010 permission to decrypt content for such purposes as journaling and malware scanning.

    Because these features require the ability of two organizations to establish a trust relationship, Microsoft Federation Gateway Support plays a crucial role in their deployment.

Table Of Contents