Any RMS protected content can only be consumed or created within the trust boundaries of the domain. It is sometimes desirable to be able to share protected content with other external parties (Partners etc) so what do you do then? Well there are a number of options available, of which the main three used are:
TUD – or Trusted User Domain is primarily used when a company with an RMS infrastructure wants to share protected content with another organization with their own RMS infrastructure. In order to do this a traditional Active Directory trust must first be in place, we can then export the SLC public key of the RMS cluster from the domain wanting to consume content and import it on the RMS cluster in the domain wanting to share content. This of course can be replicated both ways so that both sides can open RMS protected content from the other.
TPD – or Trusted Publishing Domain is usually used in one of two scenarios, one where an AD RMS cluster is being decommissioned and replaced. An example might be where forests are being merged and one cluster is taking over the functions of the others. The other scenario might be when a cluster has to issue licenses for content protected by clusters in another forest (can be used for cross forest RMS protected content exchange) To implement this trust you must export the private key of the cluster you are wanting to consolidate and import it into the TPD section of the remaining AD RMS cluster, this is so use licenses can still be acquired for content protected by the decommissioned cluster.
AD FS support for AD RMS – This is an extremely good feature for collaboration with multiple forests where partners do not have their own AD RMS infrastructure or even don’t have directories based on AD. To implement this solution AD FS must be configured and a federation trust must be in place. You then in AD FS usually create a new claims aware application entry for AD RMS certification URL, you can then define which claims to accept (for AD RMS this is UPN then email) you then do the same for the licensing URL. You must also make sure to add the server role for AD RMS Identity Federation Support and enable federated identity support in the AD RMS console. There are some registry key changes that have to be made on the trusted domain machines (the side without AD RMS) so that the home realm discover works correctly but this can be done via GPO’s*. You will then be able to send and receive RMS protected content from this entity even though they do not have AD RMS implemented!
- *Registry Key – HKLM/Software/Microsoft/
- Create registry key: MSDRM
- Under this create another registry key: Federation
- Under this add a string value named: FederationHomeRealm
- with a value of: urn:federation:YourDomain.com
So as you can see there are many options for expanding your RMS protection outside the boundaries of your domain or forest. Hope you find this useful! 🙂