How RMS Works??

  • Article

This post is going to talk about components of RMS technology and How it works.

 

Components of RMS:

RMS has following components -

 

  • RMS Server
  • RMS Client
  • RMS Aware applications

RMS Server -

  • Is the heart of RMS Solution. RMS Server has set of web services that run on top of IIS (internet information services) and perform three major functions
    • Certification: RMS Server validates the user and provides RMS user credential called “RAC”.  User is able to access the rights protected information using this RAC. More about RAC later.
    • Publishing: RMS server uses RAC and protects information using the “publishing” service i.e. encrypts the information and attaches a “publishing license” containing the information protection policy (i.e. who can view, edit, copy, etc)
    • Licensing: RMS server provides “Use License” to the recipient to access the protected information (document, email, etc) using Licensing service. The “use license” permits access to rights protected information based on the policy that was applied during the Publishing stage.
  • The RMS server provides administrative console based on MMC-snap in, which allows administrators to configure the RMS Server for policies, templates, Certificate validity, Trusts etc.
  • The Backend Database, which can be SQL Server or Windows Internal Database (in case of windows 2008 or MSDE in case of Windows 2003) is used for storing all the policies, certificates, keys etc. MSDE or Windows Internal Database is not recommended for Production environment. They are meant for test environment only.

RMS client -

  • The RMS client runs on the client machine fall into 2 major categories: the RMS client api’s and “lockbox”
    • The RMS client API’s are invoked by the applications to protect information: for example to create publishing licenses or request use licenses
    • The lockbox performs the low-level encryption operations on behalf of the user and application, so that things like encryption keys are always protected and RMS policies cannot be breached
  • Additionally, a set of credentials are stored on the client machine. These credentials establish the trust model
    • The machine certificate ensures that the RMS client running on the client machine is the true and legitimate RMS software from Microsoft, and not some rogue application
    • The user certificate, also called a “RAC” or rights account certificate, establishes to the RMS server and client that the user is who they say they are i.e. non-repudiation
    • The client licensor certificate (CLC) allows an RMS user to protect information without a live connection to an RMS server (i.e. “offline”)
    • Each of these credentials has an associated public/private key pair, the private keys are protected in the system using DPAPI or data protection API, a standard set of Microsoft interfaces

RMS Aware applications

The RMS aware applications calls RMS client APIs to enable information protection features such as the “do not forward” email or the “company confidential” document etc.

RMS client uses credential called an “application manifest” from any application that calls it to ensure that the calling application is a trusted RMS enabled application, and not a rogue app. The application manifest attests that the calling app is the same application (based on a hash of executables) for which Microsoft signed a rights management license agreement, based upon the developer of that application following certain security and tamper resistance requirements required by RMS. The purpose of the application manifest is to ensure that rogue applications do not surface and degrade the value of RMS protection.

 

A very good component diagram of RMS, which I generally refer to in my presentations for easy understanding is as follows -

image

 

How RMS Works????

 

Again a very easy to understand pictorial representation of how RMS works -

 

 

image

 

In order to rights protect a document, or use a rights protected document, the user must talk to the RMS server. The above diagram talks about flow of information exchange in RMS environment.

 

  1. An Author wants to rights protect the document. The first time author rights protects the information, he/she receives the  RAC (“rights account certificate”) and “client licensor certificate” (machine cert).
  2. The author would apply a RMS policy to their file or define the rights protection. The application works with the RMS client to create a “publishing license”, encrypt the file, and appends the publishing license to it.
  3. Now the author would share or distribute the document with other users.
  4. The receipt tries to open the rights protected document. The appropriate application would send the recipient’s credentials and the publish license to the RMS server, which validates the user and issues a “use license”. The RMS Server will check the user’s privileges and if he/she is allowed the access, it would send back a use license to the user to allow them to work with the document.
  5. The recipient’s application would render the file and enforce the rights defined in the publishing license. Now the user can decrypt and work with the document.

Authorized Users can access the rights protected information within the organization & outside the organization.

RMS provide facility of defining 2 URLs. Internal URL – for internal access, and Extranet URL – for internet based clients (users accessing remotely or external users etc).

The internal name is the url or NetBIOS name that intranet clients will use to connect to the RMS server. The external name is an internet-resolvable name that external recipients or home/traveling users will use to connect to the RMS server. At publishing time, the RMS client places both names into the publishing license of content it protects. The recipient’s RMS client reads the internal and external names out of the publishing license of content it tries to consume. It attempts to connect to an RMS server via the internal name first, and if this does not work it tries the external name second.

Tip –

  • Always specify FQDN for both Internal and Extranet URL.
  • Even if you don’t intend to publish Extranet URL, its advisable to populate the URL as RMS Client would try to connect to RMS server on Extranet URL in case it is not able to connect on Internal URL.

In my next post, I am going to provide some step-by-step guide in deploying RMS on Windows 2008. This would enable you to deploy and start using RMS.