Behind the Scenes with RMS

Traditionally, enterprises have relied on access control technologies to restrict access to sensitive data. Access control technologies have served enterprises well, but with today's threat landscape, many companies are discovering that these technologies are no longer adequate because there is no built-in feature that prevents a user with legitimate access from misusing that access. A user with read-only access can make copies of sensitive data and distribute the copies to people (such as industrial spies and competitors) who shouldn't see the data. The risk of unauthorized data distribution is forcing today's enterprise to look for persistent data protection. The concept of persistent data protection is simple: Data is protected wherever it's stored and when it's transmitted, and content owners control which users can access the data and how they can use it (e.g., whether it's read-only, or whether users can modify and print it, and how long users have access to the data). Microsoft's solution for persistent data protection for business information is Windows Rights Management Services (RMS).

RMS Overview
RMS offers protection mechanisms not found in traditional access control technologies. For example, you can use Discretionary Access Control Lists (DACLs), a traditional technology, to restrict access for users and groups and to grant or deny users permission to create, read, write, delete, and access files. But you can't use DACLs to prevent a user from printing a document or forwarding an email message. RMS lets an author of protected content, such as email or a document created with Microsoft 2003 applications (i.e., Word, Excel, and PowerPoint), grant application-specific rights to users and groups, including permission to reply to or forward an email, and to print, edit, and save files.

RMS is an infrastructure technology consisting of RMS servers, RMS clients, and RMS-aware applications that interact with the RMS Client. Microsoft's RMS-aware applications include Microsoft Office 2003 applications along with the Rights-Management Add-On (RMA) for Internet Explorer (IE). You can use RMA to view rights-protected Web sites, and Office 2003 documents and emails on desktops that have earlier versions of Microsoft Office installed. RMS-aware applications are also available from Microsoft partner companies and ISVs. To use RMS technology in your network, you need to install RMS Servers and deploy the RMS Client and RMS-aware applications to user's desktops.

Enrolling the RMS Certification Server
To use RMS in your enterprise, you must install and provision the RMS Server software and enroll the RMS Server with Microsoft as a Certification Server. An RMS Certification Server is the first RMS Server you install in your network. The primary role of a Certification Server is to issue Rights Account Certificates (RACs) to RMS users and to allow Licensing Servers to sub-enroll from it (as shown in Figure 1). As part of the provisioning process, you specify which database server RMS will use to store its configuration, logging, and group expansion cache information, and the Intranet Cluster URL it will listen on. RMS is a Web-based service, and RMS Clients use HTTP or HTTP Secure (HTTPS) protocols to communicate with an RMS Server.

During the enrollment process, the RMS Certification Server generates a public/ private key pair and sends the public key, along with other information, to Microsoft in a Server Licensor Certificate (SLC) request. RMS Service Pack 1 (SP1) lets you make a request for an SLC online or offline. If you enroll online, the RMS Certification Server issues an enrollment request to Microsoft, Microsoft verifies the information and returns a signed SLC, and the Certification Server retrieves and installs the signed SLC.

If you don't have an Internet connection (e.g., perhaps you're running RMS in a secure air-gapped network), or if you want to inspect the content in the request before submitting it, you can make an offline request by exporting the enrollment request to an XML file, "hand carrying" the request to an Internet-connected PC using a USB drive (or similar device), and submitting it using a browser to the Microsoft Web site identified on the RMS Certification Server when you export the request. The response from Microsoft is a signed SLC that you install on the RMS Certification Server. Microsoft doesn't store any information about the SLC request or the issued SLC (for privacy reasons).

When a valid SLC is installed on an RMS Certification Server, the server begins to function. You can add more RMS Servers to create an RMS Certification Cluster for fault-tolerance and scalability. Windows Network Load Balancing (NLB) cluster functionality (or a hardware device such as an F5 BIG-IP Load Balancer—http://www.f5.com/products/bigip/) load-balances requests to the servers in the RMS Certification Cluster. You should publish the Intranet Cluster URL in a serviceConnectionPoint in AD to make it easier for RMS Clients to find the RMS Certification Cluster using the RMS management Web site. You can access a link to the RMS management Web site from your Start menu. Without a serviceConnectionPoint in AD, you'll have to resort to Registry overrides on RMS Clients so that the clients can locate the RMS Certification Cluster. If you intend to expose your RMS Server to the Internet, you'll also need to set the Extranet Cluster URL in AD.

Configuring and Activating RMS Clients
Before RMS-aware applications can function on RMS Clients, you need to install Windows Rights Management Services (RMS) Client SP1 or later on users workstations. The first time an author uses an RMS function, Microsoft RMS-aware applications automatically activate the RMS Client. During the RMS Client activation process a Machine Certificate, which uniquely identifies the RMS Client, is created and stored in the user's machine-local profile along with an associated private key. (For more information about requesting a RAC, see the sidebar "Encryption in RMS," page 58.) Then the RMS Client obtains a RAC from the RMS Certification Server for the user, and when it's received the RMS Client stores the RAC in the user's machine-local profile on the RMS Client.

If an RMS-aware application doesn't detect a valid RAC when a user uses an RMS function, the RMS-aware application can request a RAC for a user through the RMS Client by looking up the RMS serviceConnectionPoint entry in AD or Registry entries on the RMS Client to find the Intranet Cluster URL of the RMS Certification Server. Then the RMS Client prompts a user to enter their credentials (in the form of username and password) or a Client Authentication certificate (e.g., the one stored on a Smart Card and used for secure logon). However, the RMS Client doesn't prompt a user for credentials if the Intranet Cluster URL is in IE's Local intranet or Trusted site's Web content zone, and the zone is configured to automatically send credentials.

RMS requires a user's email address to be recorded in a user's AD account using the mail attribute because RMS-aware applications use the email address to uniquely identify a user. If you are using Microsoft Exchange 2000 or 2003 then the mail attribute is automatically populated for every user who has an Exchange mailbox. However, RMS doesn't require users to have Exchange Inboxes, and you can manually populate the attribute for users who do not have Inboxes. If a user changes his or her email address, or has multiple email addresses, you can use the AD multi-valued proxyAddress attribute to record an old and alternate email address so a user can continue to use RMS and access rights-protected content.

A RAC is valid for one year. Under certain circumstances, such as when a user wants to access protected content from a public terminal, a special type of RAC, called a Temporary RAC, might be issued for 15 minutes—you can change this default time interval by using the RMS Management Web site on the RMS Certification Server.

   Previous  [1]  2  3  Next