In today's environments, organizations need to find ways to protect information as it passes through many hands. Windows AD Rights Management Service (RMS) is one method to implement that protection. RMS can help protect against careless mishandling as well as intentional unauthorized access to data. To help meet regulatory and legal requirements, the service will also assist with accountability and tracking.
Rights Management Service is based on the premise that authors will create information and want to control access to it. With RMS, "publishing" is the act of specifying the rights on specific information: "who" can access the information, including specific users or groups of users, and "how" they can access it -- whether they can print, edit, read or email a document, for example.
The process of validating a user's identity and the rights that user has to the information is known as "using." For example, I can create a Word document, then assign the right to read the document to all the users in my domain. Then I can assign printing rights only to users in the managers group. Then, when a user tries to access the information, his or her identity is validated, rights are assigned, and the local application enforces those rights.
Some of those that have tried to implement the technology have run into problems, however, and are wondering how to proceed. In this two-part tip, we'll focus on answering some of the more common questions security professionals have run into while implementing RMS:
- How do I allow access to my users when they are remote?
- If I have 2 Active Directory domains, say internal and DMZ, and set up the RMS in the DMZ, can I make my internal AD users "trusted entities" in the DMZ RMS? What is the best method to do this?
- How do I set default permissions for the RMS?
We'll take the questions on individually, but first, we need to set a couple baselines for practical use of Windows RMS.
More on RMS basics
Phil Cox offers up a primer on Windows RMS and access rights.
Read our Active Directory security guide.
Using Windows AD Rights Management Service: Key understandings
It is important to understand the following points:
- If you have consistent connectivity to the RMS, the service will work very well. When you are offline, not so much. In my experience, connectivity to the RMS mother ship makes your life much easier.
- If you do not have connectivity to the RMS system, you can still protect and "publish" your information, but it is significantly more difficult. You will need to have explicit knowledge of people and groups that need access to the information.
- You must have connectivity to the RMS system to "use" rights-protected information. Note that you can "use" rights-protected info offline after you gain initial access. This will create a "use" license for that specific data. You need a "use" license for every rights-protected piece of information you want to access.
- Rights are granted to a user/computer pair. From a positive standpoint, you can restrict access to a user based on the computer they are accessing the information from --very cool! On the negative side, you need to make sure you have initially accessed the information from the specific user/computer pair (i.e., received a set of cached credentials for that specific piece of information) while connected to the RMS, before you go offline.
How do I allow access to my users when they are remote?
RMS uses Web Services to provide the underlying authentication and authorization for the environment. The RMS uses IIS as the front-end mechanism to support the Web Services it provides. Given that, there are really two situations here:
- Accessing the RMS Web Service URL over the Internet
- No access to the RMS at all (a.k.a. offline)
In scenario 1, you need to ensure the following has been completed:
Publish the URL of the RMS server externally. Basically you are ensuring users can get to the URL from the Internet. If they have that access, using RMS is effectively the same as being on the corporate network.
The best way to do this securely is to use ISA server or another Web application firewall type appliance to protect the URL against attacks. If the RMS server is on your internal network, which is highly likely, you do not want to just open the firewall to that URL; you want to protect it in some manner. Using the reverse proxy feature of ISA server is a good method. Also, make sure you use SSL!
In scenario 2, you have to do a couple things differently. Before you disconnect from the internal network that has access to the RMS environment, you must:
- Activate your computer.
- Create your Rights Account Certificate.
- Enroll your client.
- Copy Administrative Templates to the local system.
The easiest way to do all of these is to open a Microsoft Office application, say Word, then open the following option:
Office Button->Prepare->Restrict Permissions->Manage Credentials.
Once you set up your credentials (note that you need to use your domain email address), all three of the above steps will be completed for you.
Second, still in scenario 2, you will need to get each document that you will want to access while disconnected, and open them while connected. This process will obtain, and cache, a "use license" for each file that you open, thus allowing you the access when offline. If you do not obtain the "use license," you will get an error about the RMS client not being able to contact the RMS server when you try to open the document.
After that, you should be able to use RMS protected documents while "remote."
Next week, we'll look at another AD Rights Management Services question I've come across: "If I have 2 Active Directory domains, an internal and DMZ, how would I set up RMS?"
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).