Active Directory Rights Management Services Secure Collaboration

Cloud computing increases data mobility and exposure. Corporate data is at risk when it travels the private and public parts of a cloud and data owners ignore the exact cloud location where corporate data is stored or processed. To properly deal with these challenges, organizations need flexible data security tools that let them enforce granular access control to ensure that only authorized users, business partners, cloud service providers, and customers can access their information.

In this context, it’s worthwhile to consider enterprise rights management (ERM) solutions such as Microsoft Windows Rights Management Services (RMS). To prevent unauthorized access, RMS encrypts information and enforces a granular access-control mechanism that decides whether and how it releases information to a user. The protection RMS provides is persistent and travels with the information no matter where it goes on your network or in the cloud.

Microsoft bundles RMS with Windows Server 2008, Windows 7, and Windows Vista. This is RMS version 2—officially called Active Directory Rights Management Services (AD RMS). Microsoft provided RMS version 1 as a free add-on to Windows Server 2003, Windows XP, and Windows 2000 Workstation. RMS protection can be added to Microsoft Office 2010, 2007, and 2003 documents; Microsoft Outlook email messages; and Microsoft PowerPoint, Excel, Word, and InfoPath documents. RMS can also secure XPS-formatted files. RMS support for other document formats (e.g., Adobe Acrobat PDF, Microsoft Office 2000, Microsoft Visio) can be added through special plug-ins that are available from third-party software vendors such as GigaTrust.

You can use RMS to secure information exchanges between different organizations and cloud entities. To do so, you can consider several architectural options.

Overview

RMS provides the following four options for the exchange of RMS-protected documents between organizations:

To configure RMS for external collaboration, you must use the Trust Policies container in the Microsoft Management Console (MMC) Active Directory Rights Management Services snap-in, which Figure 1 shows. By default, this container has two subcontainers: Trusted User Domains and Trusted Publishing Domains. If you select the Identity Federation Support role service during installation of the RMS server, the Trust Policies will have a third subcontainer called Federated Identity Support. Finally, if your RMS server runs on Windows Server 2008 R2 SP1, a fourth container called Microsoft Federation Gateway Support will show up in the Trust Policies container. You can also use Windows PowerShell commands to configure all RMS trust policy settings, as described in the Microsoft TechNet article “Establishing Trust Policies.”



Figure 1: Configuring RMS for external collaboration

Single RMS Infrastructure

Using a single RMS infrastructure saves your partner the effort and cost of setting up an RMS infrastructure but requires you to create external accounts for your partner in your AD infrastructure, thus adding provisioning and de-provisioning complexity and account management overhead. Because each user will get another account and associated credentials to remember and maintain, this approach also isn’t the most user-friendly integration option.

To enable partner users to access and create RMS-protected content, your organization must also publish RMS externally, either to the Internet or an extranet. The Microsoft TechNet article “Internet Access Considerations,” which is a chapter in the RMS documentation at technet.microsoft.com/en-us/library/dd996655(WS.10).aspx, provides good guidance for publishing RMS externally.

Your partner organizations must also make sure their users install the AD RMS client software and use RMS-enabled Office applications. If your partners only want to access protected content (and not create new protected content), they can also use the Rights Management Add-On for Internet Explorer (RMA). In this case, your partner doesn’t need to install the RMS client and RMS-enabled applications on its client computers. When you plan to deploy RMA in your organization, I advise you to read the Microsoft article “Introducing Rights-Managed HTML.”

RMS Trust Relationships

An RMS trust relationship is an RMS-specific trust that’s different from an AD trust and that’s created between two RMS installations. A key condition for an RMS trust is that your partner has deployed an RMS infrastructure—which is a rather heavy infrastructure requirement that you can’t impose on every partner.

You can define an RMS trust from the Active Directory Rights Management Services snap-in. In the Trust Policies container, you’ll see two options for setting up an RMS trust: You can either use a trusted user domain (TUD) or a trusted publishing domain (TPD).

Both TUD-based and TPD-based RMS trust relationships are unidirectional. The creation of an RMS trust requires no direct connection between the AD RMS clusters or the AD forests—it can be done out-of-band by exchanging the required certificates and/or keys.

However, when you use a TUD, for the external user to obtain an RMS use license from your RMS cluster, your RMS server must be accessible from the Internet or from the extranet. Again, “Internet Access Considerations,”  provides good setup guidance. This external access isn’t a requirement for a TPD-based RMS trust relationship. In that case, external users can get an RMS use license for your protected RMS content from their organization’s RMS servers.

For a TUD-based RMS trust relationship, you can optionally exclude certain email subdomains and their users from obtaining RMS use licenses from your RMS cluster. You can do so from the properties of the TUD certificate that shows up in the middle pane of the Active Directory Rights Management Services snap-in, as Figure 2 shows.

Figure 2: Configuring trusted email domains

Windows Live ID

Windows Live ID is an Internet-based authentication infrastructure that’s run by Microsoft. To leverage Windows Live ID credentials for authenticating external users to your RMS servers, the partner accounts that want to read RMS-protected content must have a registered Windows Live ID account. Some organizations are reluctant to use Windows Live ID credentials for authentication when the credentials are used for accessing internal (possibly very confidential) data. Windows Live ID performs only a very basic identity assurance check (based on the use of a valid email address) when a user requests a Windows Live ID account.

To enable Windows Live ID authentication in RMS, you must set up a trust with Microsoft’s online RMS service—which is basically a service that can provide an RMS authentication certificate (or rights account certificate—RAC—in RMS terms) to Windows Live ID–authenticated users. Setting up this trust will enable Windows Live ID recipients to read your protected content but not create RMS-protected content.

To enable users with a Windows Live ID RAC to obtain RMS use licenses from your internal RMS cluster, you must set up a TUD for Windows Live ID in your RMS configuration. You can do this from the Trust PoliciesTrusted User Domains container in the Active Directory Rights Management Services snap-in. In the Actions pane, select Trust Windows Live ID. If the trust creation is successful, the Windows Live ID certificate will appear in the Trusted User Domain list in the middle pane, as Figure 3 shows.

Figure 3: Setting up a TUD for Windows Live ID in RMS

As for any other RMS TUD, you can exclude certain Windows Live ID domains and their users from obtaining RMS use licenses from your RMS cluster. You do so from the properties of the Windows Live ID certificate that appears in the middle pane.

To make Windows Live ID authentication to RMS work, you must also make a configuration change on your RMS IIS web server to give external Windows Live ID users access to the AD RMS licensing web service. You do so by allowing anonymous access on the licensing web service. By default, the licensing service is configured to use Windows Integrated Authentication.

Identity Federation

Microsoft provides two identity federation–based technologies to enable the exchange of RMS-protected content between organizations: The first is based on ADFS, whereas the second leverages the Microsoft Federation Gateway. At press time, the second solution could only be used to exchange RMS-protected mail content between Microsoft Exchange Server and Outlook users in different organizations.

ADFS is the identity federation solution that Microsoft introduced in Windows Server 2003 R2. ADFS provides services to create trust relationships between organizations and to allow for easy resource access between them. For example, you can use ADFS to provide a web single sign-on (SSO) experience to external partners that access documents on your web portal. Thanks to ADFS, partners can authenticate to their AD infrastructure using their internal accounts and then transparently access the documents on your portal. ADFS can translate the partners’ authentication tokens into a format that can be understood by your organization’s ADFS servers, which can then give the partners transparent access

RMS can also leverage ADFS to give external users access to internal RMS-protected data. ADFS integration is possible only with RMS version 2 (the version that Microsoft ships with Server 2008 and later); only this version is an ADFS claims-aware application. On the ADFS side, the RMS integration can work with both ADFS version 1 and version 2.

The ADFS support in RMS allows organizations to securely share their RMS-protected content with other organizations even if these organizations don’t have an internal RMS infrastructure. However, this scenario requires a complete ADFS infrastructure, as follows:

It’s also worth pointing out that some Microsoft applications can’t use ADFS (yet) and thus can’t be used for creating or accessing RMS-protected content based on ADFS authentication. These applications include Microsoft Office SharePoint Server, Windows Mobile, and the XPS viewer. SharePoint and Windows Mobile have the same problem with Windows Live ID authentication.

In addition, ADFS and Windows Live ID can’t use groups—only individual user accounts—to protect or access RMS content. This relates to the ability of performing group expansion when these authentication methods are used. Microsoft made some changes to ADFS in Server 2008 R2 that do enable RMS group expansion from this platform on. For more information about these two problems, see the Microsoft TechNet article “Assessing the Alternatives for Sharing Protected Documents Between Organizations” at technet.microsoft.com/en-us/library/dd983942(WS.10).aspx.

Microsoft provides detailed guidance on how to set up RMS-ADFS integration. See the TechNet article “AD RMS with AD FS Identity Federation Step-by-Step Guide.”

The second identity federation–based solution—the Microsoft Federation Gateway—is an identity broker that Microsoft makes available in the cloud. The advantage of a gateway solution is that organizations must manage only a single identity federation trust relationship (with the Microsoft Federation Gateway) to enable their identities to access all other services that are federated with the gateway. The scope of the federation can be further controlled from the RMS management interface by creating allow or deny lists of users and domains for licensing and by specifying the domains that can receive publishing licenses.

Microsoft Federation Gateway support for RMS requires Server 2008 R2 SP1 on your RMS servers. Remember that (at press time) the only application that can take advantage of the Microsoft Federation Gateway for the exchange of RMS-protected data between organizations is Exchange Server 2010. You can find more information about installing and configuring Microsoft Federation Gateway support in the Microsoft TechNet article “AD RMS Microsoft Federation Gateway Support Installation and Configuration Guide.”

Diff’rent Strokes for Diff’rent Folks

Microsoft RMS provides different options to securely exchange documents between organizations. An important consideration for selecting the correct RMS collaboration setup is the availability of an RMS and ADFS infrastructure in yours and your partners’ organizations.

The collaboration approach that offers the most complete feature set is an RMS trust (TUD or TPD). Federation is a good approach if you can live with the restricted application support. For a limited number of external users, Windows Live ID is the simplest option. If the number of external users is larger, creating user accounts in your local Active Directory (AD) can be the best option. However, in such a scenario you must take into account the overhead of provisioning and managing these accounts.