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.
Authoring Rights-protected Content
Most users protect content offline, but you can use RMS to protect content online as well. The RMS Licensing Server protects content online, and the author's Client Licensor Certificate (CLC) is used to protect content offline. Offline protection is useful when you want to author rights-protected content and you're disconnected from a corporate network (e.g., when you're on an airplane or in a coffee shop). Office 2003 applications always protect content offline with a CLC. The first time a user uses RMS to protect content, an RMS-aware application requests a CLC from the configured RMS Licensing Server for the user if the application doesn't detect a valid CLC on the RMS Client. The RMS Client stores the CLC in the user's machine-local profile.
Content that is protected online or offline will be assigned an associated Publish License (PL), which contains the rights granted by the author to users. RMS uses encryption to protect content. The content and the portion of the PL that defines the rights assigned to the content and which users have rights to the content is encrypted. Without encryption, applications that are not RMS-aware and don't enforce rights (such as Microsoft Notepad) could access protected content.
Consuming Rights-protected Content
Before a consuming user can access Rights-protected content, the RMS-aware application sends a request through the consuming user's RMS Client to the RMS Licensing Server that originally protected the content (or issued the CLC to the author for the content protected offline) to obtain an End-User License (EUL). The RMS Client sends the consuming user's RAC and the content's PL in the EUL request. The RMS Licensing Server verifies that the consuming user named in the RAC is named in the PL, or is a member of a group named in the PL. If the consuming user is named, or is a member of a named group, the server issues an EUL which grants access rights to the consuming user.
When an RMS-aware application detects that a user needs a new certificate or license, or is required to renew one, it works with the RMS Client to obtain the certificate or license automatically for the user. This means that users can safely send Rights-protected content to a recipient without worrying if they haven't used RMS before.
Enforcing Protections in RMS
Only RMS-aware applications can open rights-protected content. RMS-aware applications are responsible for enforcing the rights granted to users by content authors. As a result, developers must include code in RMS-aware applications to use the RMS Client API, and for protecting data at all times. For example, if an application uses a temporary file to format a document before sending it to a printer, the application must make sure that the temporary file is encrypted to prevent the user or a hacker from accessing it to circumvent the protections RMS affords. However, relying on applications to enforce the rights granted to a user poses a problem: How do you trust an application? What is to prevent a hacker from writing an application that uses the RMS Client API to access rights-protected content and then not enforce the rights, allowing the hacker to access content without restrictions? The answer lies in the RMS Client.
Before an RMS-aware application can access content, the RMS Client checks the application's manifest. Every RMS-aware application ships with a manifest (an XML-style file) that lists the components of the application, including each DLL and executable (EXE) file. Application developers request a manifest-signing certificate from Microsoft. The application developer uses the certificate to sign the manifest. The RMS Client checks the signature to make sure the application manifest is valid and also checks the running process to make sure that each DLL and EXE file hasn't been tampered with, and that a rogue DLL hasn't been injected into the process. If the process doesn't conform to the manifest, the RMS Client returns an error and denies access to rights-protected content. In the event that a vendor ships an application that contains a vulnerability that can be exploited to strip protection from rights-protected content, the RMS Administrator can exclude the application by naming it and its version number(s) on RMS Licensing Servers. Excluded applications are written to the EUL, which the RMS Client checks. Applications themselves can exclude earlier versions of themselves when they generate a PL, and these exclusions are copied to the EUL. The RMS Client checks the exclusion list in the EUL against the application manifest, and if there is a match, the RMS Client prevents the RMS-aware application from accessing the content. For more information about enforcing central policy governing document right-protecting, see the Web-exclusive sidebar "Implementing Policy Through Templates," http://www.windowsitpro.com, InstantDoc ID 49005.
Storing EULs
EULs for content authored with Microsoft Office applications are valid for 7 years by default. Microsoft Office applications store EULs within the rights-protected content. As long as a user has a valid EUL, he or she can access the same content continuously online or offline. To store an EUL in protected content the author must have write permission to the binary file on a disk drive. Because rights are application-specific, write access to a file doesn't necessarily confer write or edit access to rights-protected content stored in the file. Due to an RMS quirk, if a user is denied write access to a file through the NTFS DACL, the RMS Client discards the user's EUL, and the user will have to access content online and obtain a new EUL every time he or she wants to access the content. However, if the FAT-style read-only attribute bit is set, the RMS Client stores the EUL in the user's machine-local profile (%USERPROFILE%\LocalSettings\ApplicationData\Microsoft\DRM), and the RMS Client can reuse the EUL. Microsoft Outlook 2003 always stores EULs for rights-protected email access in the user's machine-local profile. If several users have binary-write access to a rights-protected file (e.g., a file stored on a shared folder) and each user accesses it, the file will grow substantially in size as the EUL for each user is stored in the file.
RMS in B2B Scenarios
Although RMS is designed to protect content for enterprises, you can also use it in business-to-business (B2B) interactions by establishing Use Trusts between RMS installations. You can establish a Use Trust by exporting the SLC from a trusted RMS server and importing it to a trusting RMS Server in another organization. You're not required to establish a trust relationship between AD infrastructures. A user in the organization using the trusting RMS Server can send rights-protected email and documents to a user in the organization with the trusted RMS Server. The recipient of the rights-protected content will launch his or her RMS-aware applications, which will make an EUL request not to the recipient's RMS Server but to the trusting RMS Server. The EUL request contains the RAC issued by the trusted RMS infrastructure and the PL. The trusting RMS Server uses the imported SLC to validate the RAC before checking to make sure the recipient is permitted to access the content, then issues an EUL.
Enterprises that want to communicate with business partners who don't use the RMS technology, can take advantage of the Passport-based RMS Certification Service. This service allows one-way communication from a user with RMS to a user using the Passport-based service. The non-RMS user is required to obtain a Microsoft Passport. With a Passport-issued RAC, the recipient will be able to make an EUL request of the sender's RMS Server. If the RMS Server receiving the request was configured to trust RACs issued by the Passport-based service and the Extranet Cluster URL was configured on the server, it will issue an EUL.
RMS?Trust It
RMS's method of operation has several benefits over other information protection systems, such as pretty good privacy (PGP) and Secure MIME (S/MIME). First, PGP and S/MIME can only guarantee data confidentiality until the data is received by the recipient, who is then free to modify and redistribute it. Second, with systems such as PGP and S/MIME, it's necessary to obtain the recipient's public key or X.509v3 certificate before you can protect content you wish to send them. Last, protecting content for large groups of users using PGP or S/MIME can be impractical because you need to protect the content for each member of the group and send it individually. RMS overcomes all these problems through its unique architecture.
For more information about RMS, visit the Microsoft Web site dedicated to the product, at http://www.microsoft.com/rms. There, you can download the RMS Server and Client software and find tips to help you install and troubleshoot RMS, as well as links to partners who provide complementary services and who have developed their own RMS-aware applications.
John Howie ([email protected]) is Director of the World Wide Services and IT Technical Community for Security at Microsoft. He has more than 15 years of experience in information security and is a CISA, a CISM, and a CISSP.