Here, we consider five different ways to securely collaborate with partners who have not installed AD RMS.        

Creating a separate account store for your partner users is the most conceptually basic solution.  In this scenario, create a separate Active Directory forest with an AD RMS cluster and set up accounts for your partner users.  Then configure a Trusted User Domain (TUD) or Trusted Publishing Domain (TPD) between the AD RMS installations.  TUDs and TPDs are described in the blog post Sharing Protected Documents when Partners have an AD RMS Installation in more detail, but essentially, by implementing this solution, users in your organization can use their standard applications and distribution channels to securely collaborate with partner users we have created accounts for.  An alternative to configuring a second AD RMS cluster is to use Active Directory Federation Services, discussed in more detail below, to create a trust between the two forests.

However, hosting accounts for partner users is usually not recommended in an enterprise environment because of the administrative overhead and security risks.  In this model, we must manage the provisioning, maintenance, and deprovisioning of users who are not part of our organization.  Also, creating additional accounts for users increases the risk of a security breach. 

Active Directory Federation Services is an identity federation service that allows users in one forest to access resources in another forest using their own credentials.  With AD FS in place we do not have to host separate accounts for partners.  Rather, users have one account with a single set of credentials, which are managed by their organization.  Partner users can then use single sign-on to access AD FS aware applications, such as AD RMS.

AD FS eliminates the administrative overhead and security issues that come with hosting partner users; however, there are some important considerations to using AD FS with AD RMS.  First, our partners will be unable to view protected content on their mobile devices.  Partner users will be able to consume, but not create, protected XPS documents.  Finally, for a protected document to be opened from Microsoft Office SharePoint Services, the library must be located in the same forest as the AD RMS cluster.

To learn more about using AD FS with AD RMS you can read the TechNet articles Using Active Directory Federations Services with AD RMS and AD RMS with AD FS Identity Federation Step-by-Step Guide.

If your organization's security protocols or the sheer number of partner organizations make a forest-wide trust, such as AD FS, impractical our partner GigaTrust has developed an external collaboration solution that is included in their Enterprise Plus product.  Like AD FS, with Enterprise Plus external accounts are managed by your partners and users can access protected content using single sign-on.  Unlike AD FS, this trust is established on a per user, rather than per company, basis.  This makes it feasible to support a scenario where partner users are spread across many different organizations, even if those organizations are using an LDAP directory other than Active Directory.  Enterprise Plus provides several additional benefits such as a central management point for all AD RMS reports and rights policy templates for both internal and partner users.  It also allows us to use AD RMS with additional file formats such as pdf.

Users in the partner organization must install a client application, which requires local administrative rights.  This solution is therefore best implemented between long-term partners, rather than for a single use scenario.  Also, Enterprise Plus is not included in an AD RMS installation or in Windows Server; it is a third party product.  To learn more about GigaTrust's Enterprise Plus visit http://www.gigatrust.com/enterprise-plus.shtml

Our partner Liquid Machines has also developed an external collaboration solution that is appropriate when partner users are spread across many different organizations.  Partner users must be hosted, usually in a separate Active Directory forest, linked to your forest by a TUD, TPD, or AD FS.  They then install either the full Liquid Machines client, which requires local administrative rights and offers full AD RMS functionality, or the LM Viewer, which does not require administrative rights but simply provides read-only capabilities, even if the user has been granted additional rights.  Both the full LM client and the LM Viewer can be used to protect or view content in over 400 different file formats and users can open protected content, even if they have not installed the application that created the content on their local machine.  Also, they both work with Enterprise Rights Management to provide advanced reporting capabilities.

This solution requires us to manage the lifecycle of accounts for users outside our organization, which results in additional administrative overhead.  The Full Client and the LM Viewer are produced by Liquid Machines and are not included in an AD RMS installation or in Windows Server.  For more information please visit http://www.liquidmachines.com/.

Perhaps our organization plans to share protected information in a more casual manner, and we would like to avoid any type of prolonged trust.  This scenario is common in a business to consumer relationship or when we simply want to share a single document with a partner.  We can configure our AD RMS cluster to trust the Windows Live ID service and then partner users can open protected content using WLID credentials.  While partner users will be able to open protected content, they are unable to create protected content that our users will be able to consume.  Furthermore, these users will not be able to open protected content on their Windows Mobile device or access our documents in a protected SharePoint library.  Finally, protection must be applied on an individual basis; WLID accounts cannot be added to an Active Directory group.

If you would like to read more about using WLID with AD RMS review the TechNet articles Sharing Documents with External Users and Use Windows Live ID to Establish RACs for Users.

 

See Also