Understanding Business-to-Business Scenarios

Applies To: Windows Server 2008, Windows Server 2008 R2

Very few organizations can conduct their business by themselves. In an increasingly interconnected economy, companies and other organizations find themselves involved in partnerships and in commercial relationships with suppliers, customers, and vendors. These relationships often involve the sharing of confidential information, such as project plans and sensitive intellectual property, in the form of email and digital documents. By their very nature, these forms of communication can easily slip out of the control of the partner organizations, exposing the information to anyone who has access to the message or file. This kind of disclosure of confidential information can be embarrassing at best, and catastrophic at worst.

Complicating this problem is the fact that the organizations in these relationships rarely have a common identity and security infrastructure. This makes it difficult to guarantee that confidential information can be shared securely between individuals in the partner organizations. Active Directory Rights Management Services (AD RMS) supports several alternatives that enable partner organizations to share confidential information while still maintaining independent infrastructures. Each of these alternatives involves a tradeoff between ease of deployment and ease of administration, plus exposure to risk. The following sections explain each of these alternatives and the benefits and tradeoffs involved with each of them.

• Using AD RMS trust

• Using Active Directory Federation Services

• Using Exchange 2010 SP1 and Microsoft Federation Gateway

Using AD RMS trust

It is not necessary to create trust or federation relationships between the Active Directory forests of organizations to be able to share rights-protected information between separate organizations. AD RMS provides two types of trust relationships that provide this kind of rights-protected information exchange. A trusted user domain (TUD) 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. A trusted publishing domain (TPD) enables 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. For this reason, using a TPD is not recommended for exchanging protected content between separate organizations

By far, the built-in trust relationships of AD RMS are the easiest to deploy when the number of trust relationships between AD RMS clusters are few. Forest trust relationships or federation are not required to implement these trust relationships. However, because the trust relationships are one-to-one, the number of trust relationships multiplies with each additional organization that is added to the matrix of relationships. For example, if two AD RMS clusters establish a trust relationship with each other, two trusts are created. If three organizations establish trust relationships with each other, a total of six relationships are required, as shown in the following table.

As you have probably noticed, the growth of trust relationships is exponential, based on this formula: n2–n, where n is the number of AD RMS clusters.

Using trusted user domains

As noted earlier, a trusted user domain allows users who have RACs that were issued by one AD RMS domain to acquire use licenses from a partner AD RMS domain. This is possible because the trusted AD RMS root cluster receives the server licensor certificate (SLC) from the trusting AD RMS root cluster. The trusted AD RMS cluster can then add this SLC of the trusting AD RMS cluster to the RACs that it issues to its users. This enables those users to successfully obtain use licenses (ULs) from the trusting AD RMS cluster.

The following diagram illustrates the flow of data between two AD RMS clusters that have exchanged a trusted user domain.

For each trusted user domain, you must specify which email domains are trusted. This is an important security step because if it is not taken, for a user from a trusted user domain could impersonate an internal user.

For more information, see Deploying trusted user domains.

When you consider whether using trusted user domains is the most effective way to exchange rights-protected information with another organization, you want to consider the advantages and disadvantages of this approach.

Considerations for using trusted user domains

Using trusted user domains has the following advantages:

• Simplicity of deployment Of all the methods available to exchange rights-protected information, trusted user domains are the easiest to deploy, at least when only a few trust relationships are involved among organizations that have deployed AD RMS. All that is required is to exchange SLCs between the AD RMS root clusters, to specify trusted email domains, enable remote client access to the AD RMS root clusters, and to provide for remote group expansion. (For more information, see Deploying trusted publishing domains).

• No forest trust or federation required Because the relationship between AD RMS clusters created by a trusted user domain is directly between the two clusters, you do not have to create a forest trust or federation relationship between the host forests.

• Scaling difficulties As noted earlier, because exporting a trusted user domain by one AD RMS cluster and importing it into another cluster creates a one-way, one-to-one trust relationship, using trusted user domains to share rights-protected content across organizations does not scale well. As a result, trusted user domains work best when the only a few organizations are involved.

  One way to avoid a proliferation of trust relations is to have one partner host an AD RMS root cluster that would be available to the Internet and that could be used by other partners to obtain licenses for published content. In that case, the partners would only have to establish trusted user domain relationships with the extranet AD RMS cluster instead of between all the partner AD RMS clusters.

• AD RMS required in all partner-organization forests Using trusted user domains to share rights-protected content between organizations necessarily requires that all of the organizations involved to deploy AD RMS. If any one of the organizations is not able to do this, then another method for sharing AD RMS–protected content with that organization must be used.

• Securing the licensing pipeline When you use trusted user domains to share rights-protected content with users outside your organization, you must make sure that your AD RMS root cluster is available to those users, usually by making it available on the Internet; see Appendix A: Making AD RMS Available on the Internet for more information. You must then configure the permissions that protect the cluster’s licensing pipeline (license.asmx on the host Web site) to enable access by external users. Typically, for cross-organization collaboration this means enabling anonymous authentication, which might be considered a security vulnerability in some organizations by making it more open to a denial-of-service attack. AD RMS always uses the rights account certificate (RAC) for authentication, however, so enabling anonymous authentication does not put information secured by AD RMS at risk.

• Remote group expansion consideration If being able to use groups to protect content is important, extra steps must be taken to provide for remote group expansion, such as creating Windows forest trusts, replicating group contacts between forests, or enabling anonymous access to the group expansion pipeline (groupexpansion.asmx), each of which introduces their own administrative complexity or security issues or both.

Using trusted publishing domains

By default, servers in an AD RMS cluster can issue use licenses that correspond only with publishing licenses that the cluster itself issued. A trusted publishing domain enables 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, private key, and rights policy templates of the server to trust. Because exporting a trusted publishing domain involves sharing private security information that most organizations consider very important, this approach is rarely used between organizations that do not have strong and permanent ties, such as divisions in a larger organization. The most typical scenario for using trusted publishing domains is to retire an existing AD RMS cluster. For example, one company that has deployed AD RMS acquires another company that has an AD RMS cluster in place, and so one of the clusters must be deprovisioned. It is not recommended for supporting collaboration between two separate organizations or even in a multidivision organization that might be split up in the future.

The following diagram illustrates the flow of data between two AD RMS clusters that have exchanged a trusted publishing domain.

When the administrator of an AD RMS cluster wants to establish a trusted publishing domain relationship with another AD RMS cluster, the administrator exports the cluster’s server licensor certificate, private key, and rights policy templates are stored into a password-protected XML file. This file is then imported by the administrator of the trusted AD RMS cluster to establish the trusted publishing domain relationship between the two clusters.

For more information, see Deploying trusted publishing domains.

When you consider whether using trusted publishing domains is the most effective way to exchange rights-protected information with another organization, you want to consider the advantages and disadvantages of this approach.

Considerations for using trusted publishing domains

• Support for group expansion Group expansion is performed on the server that hosts the clients that receive the use licenses, and so it is not necessary to create forest trusts between forests hosting the AD RMS clusters in the trusted publishing domain relationship. As a result, implementing a TPD relationship requires less administrative and bandwidth overhead than is required by a trusted user domain relationship. On the other hand, implementing a forest trust might still be best because the global address list (GAL) synchronization that a forest trust provides can make it easier for users in one forest who publish content to locate users in the other forest.

• Requires a very high level of trust Because the trusted publishing domain involves the exchange of the private key of the AD RMS cluster, it requires a very high degree of trust by the administrator of the trusting cluster in the administrators of the trusted cluster. For this reason, trusted publishing domains are usually not an appropriate method for supporting true cross-organization collaboration.

• Clients must be redirected Under ordinary circumstances, clients use the URL in the publishing license to determine the AD RMS cluster from which they should request a use license for decrypting AD RMS–protected content. However, clients in the trusted publishing domain cannot use the trusting AD RMS cluster for this purpose. Instead, they must be configured by using application-specific registry overrides that map the URL of the trusted cluster to the URL of the cluster that originally rights-protected the content, or their DNS servers must be configured to have aliases that redirect IP address requests for the originating AD RMS cluster URL to the IP address of the trusted cluster.

• Templates must be kept synchronized Rights policy templates are included in the data that’s exchanged when you are creating a trusted publishing domain relationship. If the AD RMS cluster that exported the TPD remains active, and if any rights policy templates on that cluster change, you must re-export and re-import the TPD to keep the rights policy templates synchronized between the two AD RMS clusters.

Using Active Directory Federation Services

Federation is becoming increasingly common as a method that is used by organizations to collaborate with partners and customers beyond their enterprise boundaries. AD RMS can assign rights to users in forests that are federated by using Active Directory Federation Services (AD FS). This gives organizations the ability to share rights-protected content without establishing another trust or by building a separate AD RMS infrastructure.

AD FS is a standards-based services that provides identity federation through claims-based authentication across forests. Claims-based authentication is the method of authenticating a user based on a set of claims that is contained in a trusted token issued and signed by a trusted entity.

AD FS establishes identity federation between two organizations by creating a trust relationship between two Active Directory Domain Services (AD DS) forests. An AD FS server on one side of the trust (the account forest) authenticates the user through AD DS and issues a token that contains a series of claims about the user that include the user’s identity. This process enables an organization to provide controlled access to its resources or services to a user who belongs to another forest. Users are not required to authenticate directly to the federated environment, nor is it necessary for organizations to share user credentials.

To take advantage of identity federation, a service must be able to accept federated identities. AD RMS can accept requests for licenses from remote users through a single–sign on agent or web-based single sign-on and then redirect the requests to the local federation server in the resource forest. The local federation server requires the user to authenticate to the AD FS server in the account forest, which authenticates the user through Active Directory and issues the user’s security token. This token, in turn, is presented to the single–sign on agent, which validates the token and provides the identity to the AD RMS server. Finally, the AD RMS server issues the requested licenses.

The following diagram illustrates the flow of data between a remote user and an AD RMS cluster that is federated to the remote user’s forest.

For more information, see Deploying AD RMS with AD FS.

When you consider whether using identity federation is the most effective way to exchange rights-protected information with another organization, you have to consider the advantages and disadvantages of this approach.

Considerations for using identity federation

• Single AD RMS infrastructure Only one AD RMS infrastructure is needed, so that external partners do not have to establish their own AD RMS infrastructure to exchange rights-protected content.

• No identity management overhead The AD DS administrators of each forest need only to manage the users in their own forests. There is no requirement to provision or synchronize users from other forests when identity federation is deployed.

• Standards-based protocols AD FS uses standards-based protocols to maintain federated identity relationships. This means that partners are not even required to deploy AD FS or even AD DS, as long as their federation and identity infrastructures use the same protocols.

• Interoperability with MOSS Combining AD RMS identity federation with Microsoft Office SharePoint Server provides a very powerful way to share rights-protected documents between organizations without incurring the overhead of managing the identities of remote users.

• Local group expansion Active Directory Rights Management Services (AD RMS) running on Windows Server® 2008 R2 supports local (that is, resource forest) group expansion when groups are synchronized with the account forest.

• Federation deployment required by all partners While only one partner must have an AD RMS infrastructure to provide rights protection for all partners, all partners must have deployed AD DS and AD FS, or equivalent services. However, this federation can be useful for other aspects of collaboration (such sharing calendars through Exchange or MOSS, for example).

• Some loss of functionality Applications must be designed to be able to process AD FS claims to be able to work with federation through AD FS. Consequently, the following platforms and applications cannot work with AD RMS when users are in a federated forest:

  • Windows Mobile

  • Mac Office

  • Many third-party applications

  In addition, versions of Microsoft Office earlier than Microsoft Office 2010 support federation with only one partner organization.

Using Exchange 2010 SP1 and Microsoft Federation Gateway

The Microsoft Federation Gateway is an identity service that runs over the Internet and mediates between an organization or business and the external services that the organization wants to use. The gateway acts as a hub for many of the connections the organization wants to make with applications built on Windows Azure or to a Microsoft application that is running on the Internet. The gateway connects users and other identities to the services that it works with, so that an organization only has to manage a single identity-federation relationship to enable its identities to access all Microsoft and Microsoft-based services that they want to use.

The Microsoft Federation Gateway provides to applications a simple, standards-based method of establishing trust between separate organizations that uses SSL certificates to prove domain ownership. Because the organizations federate with the gateway instead of with each other, it is much easier for an organization to establish trust relationships with multiple partners than is possible when it uses conventional one-on-one federation or other trust relationships. The scope of the federation can be easily controlled by creating allow or deny lists of users and domains for licensing and by specifying the domains that can receive publishing licenses. This guarantees that only appropriate organization are given access to protected information.

When two organizations establish a federated-identity relationship, one partner (the identity provider) controls its own user accounts and the other partner (the resource provider) grants access to its resources by relying on the authentication performed by the identity provider. A user’s identity is defined as a set of claims, that is, statements that a server makes about a user. Examples of such claims are the user’s name, groups, or permissions. Identity federation enables the sharing of these identity claims.

Microsoft Federation Gateway Support in Service Pack 1 (SP1) for Windows Server® 2008 R2 enables AD RMS to accept tokens from the Microsoft Federation Gateway to authenticate users for certification and licensing. For example, Microsoft Exchange Server 2010 with SP1 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 infrastructure. When the Exchange Server 2010 infrastructure is configured to take advantage of these features, users can send AD RMS–protected e-mail messages to recipients outside the sender’s organization. These recipients can then view the messages by using Exchange Server 2010 Outlook Web App (OWA). Also, recipient organizations that use Exchange Server 2010 with SP1 can decrypt content for such purposes as journaling and malware scanning.

For more information, see Deploying Exchange 2010 and AD RMS with Microsoft Federation Gateway.

When you consider whether federating through the Microsoft Federation Gateway is the most effective way to exchange rights-protected information with another organization, you must consider the advantages and disadvantages of this approach.

Considerations for federating through the Microsoft Federation Gateway

Federating through the Microsoft Federation Gateway has the following advantages:

• Simplified deployment External partners do not have to deploy AD RMS themselves, nor is it necessary for the parties to establish a 1:1 federation, as is required with AD FS.

• Enables remote Exchange Server integration Federating through the Microsoft Federation Gateway provides a similar degree of integration between Exchange Server 2010 in the remote organization as is possible when Exchange Server 2010 is deployed in the same forest as the AD RMS cluster. That is, it enables IRM in OWA in addition to transport decryption and journal decryption.

• OWA only End users in the remote organization can access IRM-protected messages only through OWA; client-side IRM protection and consumption is not supported.

• Deployment requirements Support for federating through the Microsoft Federation Gateway is available only in AD RMS running on Windows Server 2008 R2 with SP1 and in Exchange Server 2010 with SP1. Other applications (such a Microsoft Office or SharePoint Server) cannot use AD RMS by federating through Microsoft Federation Gateway.