Problem solve Get help with specific problems with your technologies, process and projects.

RMS setup tips for multiple Active Directory domains

Phil Cox reviews how to offer rights-protected documents when you have more than one Active Directory domain, including a DMZ.

In my previous tip, we tackled a common Windows AD Rights Management Services question: How do you allow access...

to remote users? Now, let's review another RMS setup task: how to set up RMS and offer rights-protected documents when you have multiple Active Directory domains, including an internal one and a DMZ.

The first concept to understand is that an RMS can only provide services to users in its Active Directory domain, not for users in other AD domains. If you want to provide rights management to both domains, you will have to install RMS in each domain. At that point, you have two options:

  • Create users in each domain, and have them use an account and RMS as appropriate.
  • Establish trust between the RMS environments.

Remember that users can have multiple account certificates configured. Each account certificate is associated with a user/computer pair. During the access process, the RMS is contacted, an individual's credentials are validated, and an account certificate for the user/system pair is created. The RMS client on the system then enforces the rights as defined in the document. To access the same document, a user can move to another system and create a separate account certificate as well.

In the first scenario, creating users in each domain, an employee would use the specific account (i.e., email address) to authenticate to RMS and create the account certificate, and use it when assigning permissions.

In the second scenario, there are two options:

  • Trusted User Domain (TUD) (most common): The Trusted User Domain allows the licensing servers in one RMS to accept "use" license requests from users in the other RMS. The option allows users to share protected content across the domains. The main consideration is that the user will need connectivity to an RMS server in the "other" environment. If you want to use groups for permission assignment, you will need trust between the Active Directory forests, from a practical standpoint.

    Establishing trust can be done easily using the Active Directory Domains and Trusts Microsoft Management Console snap-in and Trusts tab. You will need to consider the security implications of trusting the other domain, as well as ensure that DNS resolution works between the two domains."If you just want to assign permissions to individual users, then Active Directory trust is not needed.

  • Trusted Publishing Domain (TPD): The Trusted Publishing Domain allows the RMS servers on one environment to issue "use" licenses for information that was originally published in another RMS environment. The main difference between TPD and TUD is that a Trusted Publishing Domain doesn't require a connection to the RMS of the trusted RMS. The downside of the option is that you need to exchange the private keys of the Rights Management Services. You will also have to set registry entries to force your client to go only to the one RMS.

Think of it this way: A TPD allows an RMS to decrypt content it did not publish, whereas a TUD requires the client to connect to the RMS that published it.

You will also have to open firewall ports for AD trust and access to the Web Service on the RMS servers.

First, let me say that RMS can be used very successfully, and if deployed correctly, could help many organizations provide access control and accountability that they only dream of currently. With that said, RMS works best when connectivity to the RMS and associated components (i.e., the share where Templates are located) is consistent. While you can use some features of RMS offline, my experience suggests that it is not practical.

About the author:
Phil Cox is a principal consultant of SystemExperts Corporation, a consulting firm that specializes in system security and management. He is a well-known authority in the areas of system integration and security.

His experience includes Windows, UNIX, and IP-based networks integration, firewall design and implementation and ISO 17799 and PCI compliance. Phil frequently writes and lectures on issues dealing with heterogeneous system integration and compliance with PCI-DSS. He is the lead author of Windows 2000 Security Handbook Second Edition (Osborne McGraw-Hill) and contributing author for Windows NT/2000 Network Security (Macmillan Technical Publishing).

Send comments on this technical tip: [email protected].

Join our IT Knowledge Exchange discussion forum; please use the midmarket security tag.

Join our LinkedIn group, and share your expertise with your peers.

Dig Deeper on Microsoft identity and access management