Leverage the Mobile Device Extension for ad rms

Reviewing the supported topologies for the Mobile Device Extension

Whilst IT professionals can deploy AD RMS in a myriad of possible topologies - combining multiple clusters of different types with different trusts – to accommodate requirements that vary significantly from one organization to another, the Mobile Device Extension is designed to operate in the most common topologies used by organizations. While it may be possible for AD RMS to work in other topologies it is not the scope of this paper, and the Mobile Device Extension may not support some specific configurations.

These supported topologies for the Mobile Device Extension can be grouped and listed as follows:

• 
  Single forest with a single cluster.
  
• 
  Multiple forests with multiple certification clusters and a single licensing point.
  
• 
  Multiple forests with multiple certification clusters used for licensing.
  
• 
  Single or multiple forest with licensing-only clusters.
  
• 
  Cross-organization with federated trusts.
  
• 
  Trusted Publishing Domain (TPD) key imported from existing or deprecated AD RMS server.
  

While other topologies may be possible with AD RMS, they are NOT supported with the Mobile Device Extension for AD RMS at the time of publishing.

The next sections provide a short depiction of the considered topologies along with the considerations that apply to each.

Single forest with as single cluster

In this topology, an organization has only a single forest in which AD RMS can be used. All users and servers that interact with RMS are hosted in that forest. This topology is the most commonly one deployed. Consequently, the deployment of the Mobile Device Extension for AD RMS will be illustrated later in this document using this topology.

One AD RMS cluster is installed in that forest and typically the aforementioned service connection point (SCP) is configured in Active Directory. Since all licensing and certification URLs point to the same cluster, and all users in the organization, regardless of their email domain or sub-domain, use the same cluster, the DNS SRV records for the discovery service mechanism point to that cluster’s URL as follows:

• 
  Service discovery record for email domain suffix  RMS service FQDN
  
• 
  Service discovery record for AD RMS cluster licensing URL  RMS service FQDN
  

No additional redirection is needed at the AD RMS cluster.

Multiple forests with multiple certification clusters, all using the same cluster for licensing

In multi-forest organizations where users are scattered around domains in multiple forests, AD RMS architectural design requires that one AD RMS cluster is deployed in each forest to enable certification of the different users.

To simplify logging, troubleshooting, configuration and deployment most organizations configure the licensing ULRs in all the different certification clusters to point to the licensing location of one of the clusters, in essence making this cluster the only cluster that will be utilized to protect content. (This cluster may be either the certification cluster in one of the forests or a licensing-only cluster installed in one of the forests in addition to that forest’s certification cluster). This so-called "centralized licensing" cluster is populated with trusted user domains (TUD) from all other clusters, and domain or forest trusts between the different forests are usually configured to enable cross-forest authentication and group expansion.

Note For information on Trusted User Domains (TUD), see the eponym Microsoft TechNet article Trusted User Domain²⁹.

As a consequence, while Rights Account Certificates containing different certification URLS and signed by different clusters are issued to rich clients in different forests, all clients receive a Client Licensor Certificate from the same cluster, and all Publishing Licenses will be encrypted with the same key pair and will be stamped with the same URL.

Important Note Since in mobile devices working with the Mobile Device Extension for AD RMS all transactions are atomic and there’s no use for Rights Account Certificates, clients only interact with the RMS cluster used for licensing. The existence of an RMS cluster in a forest that is only used for certification is of no consequence to the mobile clients, and as a results Trusted User Domains are not used for mobile devices. This, in turn, means that only cluster actively used for licensing need to have the Mobile Device Extension installed, and clusters only used for certification in their respective forests don’t need to be configured for mobile devices directly.

In this environment, users may have email addresses under the same or different domains. All publishing licenses contain the same URL.

Protecting content in this topology

When a user tries to protect content with a mobile device, the service discovery records for the user’s email address domain or, recursively, a parent domain of that domain will point the user to the single licensing cluster. Authentication will be triggered when trying to acquire a Publishing License to protect content and the federation flow will involve authentication in the user’s source forest as needed.

Authentication for users in a forest different from the one used for licensing may be achieved through a federated trust between AD FS servers in the different forests, or via a single AD FS server in the forest where licensing is being performed by using AD trusts established between the forests to authenticate users in their respective forests.

Aside from the underlying requirements of setting up such a federation topology, the details of the authentication flow between the different forests are abstracted by the federation server platform, and all that matters to the Mobile Device Extension is that, once authenticated in its own forest, the user will be granted a valid access token with the necessary claims to connect to the service endpoints in the RMS cluster. One that happens, the user trying to protect content will be issued a Publishing License as required.

When the RMS client tries to protect content, the service discovery mechanism has to return to the client the licensing URL in the organization which is the same for all users. Once the user has entered their email the licensing URL of the organization is returned and the user starts the authentication process against that URL which will be performed using AD FS and the multiple directories involved, but ultimately will lead to the user being connected to the Publishing URL in MDE in the cluster used for licensing.

Consuming content in this topology

Likewise, when a user tries to consume protected content with a mobile device, the service discovery records for the URL in the Publishing License in the document will point the client to the URL of the cluster used to protect the content. Authentication will be triggered when trying to acquire a EUL and there the federation flow will proceed just as for the authoring scenario and involve authentication in the user’s source forest as needed. Once authenticated, the user is able to acquire a EUL from the cluster that protected the content.

If the PL indicates groups as recipients of rights that are defined in any other forest, AD RMS will perform remote group expansion by utilizing the remote clusters group expansion services, but this will be completely transparent to the mobile device client and the REST related implementation.

Multiples forests with multiple licensing and certification clusters

Sometimes, organizations deploy multiple certification clusters with different licensing URLs in their multi-forest environment. In this case, MDE needs to be installed in each cluster utilized for licensing, and each of them needs to be configured to use AD FS in a way that supports authenticating all users that will be using that cluster to protect or consume content.

Protecting content in this topology

When a user tries to protect content with a mobile device, the email domain of the user will be used to find the corresponding server and the service discovery mechanism will direct the user to the right cluster. As in the previous topology authentication might involve Federation across the different forests depending on the forest to which the user belongs.

If all users in the organization use email domains specific to the forest to which each user belongs, then different records for each domain will point the user directly to the RMS cluster in the right forest. In this case the user will be authenticated via AD FS locally in the same forest.

If all users and organization share the same email domain or there isn’t a one to one mapping between email domains and forests, the user will be directed to the RMS cluster in one of the forests by the service discovery record corresponding to the email domain, and the post-authentication service discovery process will be used to direct the user to the RMS cluster that the user should use to protect content. This process uses information in a table associating Active Directory groups to the corresponding RMS FQDN to direct the user to the right cluster. As in the previous topology, authentication might involve federation across the different forests depending on the forest to which the user belongs. A properly configured federation environment will be then required to authenticate the user against their source forest.

Consuming content in this topology

In this configuration there will be content protected with different URLs depending on where the author was located.

This means that the service discovery records for consumption will include entries for each of the clusters in the organization that are used for licensing as indicated before.

When content is consumed by a mobile device user, the RMS client will use the service discovery record for the URL indicated in the PL in the protected document which typically will lead the user to the cluster that was used by the author to protect the content. The client authentication will be triggered by access to the URLs in the authors cluster. As in the previous topology authentication might involve federation across the different forests depending on the forest to which the user belongs.

A properly configured federation environment will be then required to authenticate the user against their source forest. If the federation setup can identify the user’s source forest and authenticate it accordingly (which is possible at least if there are forest trusts in place) the user should be authenticated properly and the necessary claims extracted. Once the necessary tokens are obtained including the claims for the user’s email address the user may be redirected to a different RMS cluster for obtaining an End User License. This is done in cases in which it is desired that the user consume content using a different cluster with an Imported Trusted Publishing domain from the source cluster. In most cases, the cluster used to consume content is the same used to protect it.

After the user reaches the licensing URL in the right cluster, an End Use License will be issued by the cluster in the document author’s forest.

Single or multiple forest with a licensing-only cluster

Sometimes, organizations deploy multiple licensing-only clusters in their environment. A Licensing-Only cluster is a cluster deployed in the same forest as a certification cluster. The Licensing-Only cluster is subordinated to the certification cluster, which will handle all certification requirements in the forest.

In these organizations some individual users need to be pointed to different service URL to protect content than other users with the same or different email domain. For example a group of high-level executives might need to use a special AD RMS cluster, which is different from the one used by all the other users at the company. In most environments where this is the case, different licensing clusters are thus assigned to different users via registry overrides. This will not be possible with the mobile RMS clients since mobile devices do not support registry overrides or any other kind of manageable persistent application configuration.

Protecting content in this topology

When content is protected in this topology, the DNS-based service discovery will point the user to the default cluster for the user’s email domain. If the users assigned to a licensing only cluster share the same email domain with users assigned to different cluster then after authentication group membership-based redirection based on a table in the RMS configuration database associating Active Directory groups with RMS clusters will point the user to the licensing only cluster that corresponds to them.

Consuming content in this topology

Conversely, when content is consumed in this topology, the DNS-based service discovery will point the user to the cluster that was used to protect the content. Authentication at this cluster might involve federation between forests or it might be performed within a single forest.

Once the user is authenticated a EUL will be issued by the licensing only cluster just as in the single cluster case.

Cross-organization with federated trust

Some organizations collaborate with other organizations via federated trusts. In these cases, rich clients are activated, obtain CLC’s, and consume content with the same AD RMS cluster.

Since authentication is performed on the mobile device clients through a federation flow, the fact that these partners are external users should be opaque to the clients and to the service, and this topology looks exactly like the single cluster, single forest scenario topology for implementation purposes.

As long as the federation platform is correctly configured and is able to authenticate the external users they will receive the right artifacts and be able to acquire licenses from the organization’s AD RMS cluster. If an organization wants their federated partners to be able to protect content against their cluster, the organization will need to configure the DNS-based service discovery for their email domains to point to the controlling organization’s AD RMS cluster.

TPD Imported from existing or deprecated AD RMS server

In some organizations with special requirements, multiple clusters are deployed (possibly at different times) and trusted publishing domains (TPD) are exchanged between them. Clients are then configured to consume content from one cluster even though it has been protected with another cluster. The typical reasons for such environments are related to network topologies, isolated environments, and decommissioned clusters in migrations or merger scenarios.

Note For information on trusted publishing domains (TPD), see the eponym Microsoft TechNet article Trusted Publishing Domain³⁰.

This redirection is typically implemented via registry overrides on rich clients. As already noticed, the mobile device clients do not support registry overrides.

Protecting content in this topology

A user is directed to whatever URL is registered for the user’s email domain name in DNS in accordance to the service discovery record(s). The user may or may not be redirected to a different cluster for acquiring a PL based on the group-cluster mapping table in the configuration database, just as in the regular multi-forest environment.

Consuming content in this topology

For consumption, the RMS client would look up in DNS the service discovery record for the domain in the PL. This may point the user to the same cluster that was used to protect the content (the default single-forest behavior) if that cluster is still available, or to a cluster with an imported TPD if that cluster is not available or not intended to be used by this user.

In either case, the user may be redirected based on group membership to a different cluster (the original one or another one with a TPD) for a variety of reasons (e.g. geographical affinity). Once the client reaches the right cluster successfully, the server can use the imported Trusted Publishing Domain to issue an End User License for the content.