What company doesn't dread the leak of confidential information, be it trade secrets or sales figures? Traditional access-control mechanisms such as discretionary access control (DAC), mandatory access control (MAC), and role-based access control can restrict users' access to files but can't prevent authorized users from printing sensitive documents or copying such documents to 3.5" disks or removable USB drives. Traditional mechanisms also are often ineffectual at securing email content.
Microsoft Windows Rights Management Services (RMS) for Windows Server 2003 offers a solution. RMS, which is based on Extensible Rights Markup Language (XrML) 1.2.1, consists of a client component and a server component that work in tandem with RMS-aware applications to let users protect document, email message, or Web site content. RMS lets users create usage policies to define who can access rights-protected content, what actions authorized users can perform (e.g., save, print, forward, edit, reply), and when these actions can take place (e.g., within a certain number of days). These policies reside in a publishing license, which also contains a key that uses 128-bit Advanced Encryption Standard (AES) encryption to protect the content and URLs for the RMS licensing server that can issue a use license for the content. Part of the publishing license is encrypted to protect the most sensitive information it contains. When a user opens rights-protected content in an RMS-aware application, the application contacts the RMS server that the publishing license specifies to obtain a use license, which the application then uses to access the content and enforce the usage rights for that particular user. To receive a use license, a user must first obtain a valid XrML Rights Management Account Certificate (RAC) from his or her RMS certification server (an RMS server can function as both a certification and licensing server). The RMS-aware application guides the user through the process of obtaining an RAC if the user doesn't already have one. Users without RMS-aware applications can download and install the Rights Management Add-on for Internet Explorer (RMA). This free add-on lets users use Microsoft Internet Explorer (IE) to view—but not modify—rights-protected content. As you can imagine, if your organization plans to implement RMS, you'll need to plan ahead for its installation, configuration, and use.
Planning for Installation
Microsoft designed RMS to be a forestwide technology, and most organizations implement only one RMS hierarchy per forest. (You can, however, build clusters of RMS servers for load balancing and fault tolerance, and you can build hierarchies to accommodate the needs of business units or geographically separated office locations. For more information about RMS clusters and hierarchies, see the sidebar "RMS Clusters and Hierarchies.")
The first step in planning your RMS infrastructure is to determine how your organization will use RMS: internally only, or both internally and externally. RMS lets you specify two contact URLs for each RMS server—an intranet URL for internal users and an extranet URL for external users. You set the intranet URL during RMS server configuration and can't change it easily. By default, RMS bases this URL on the RMS server's computer name, but I recommend not using physical server names in your RMS server URL; doing so can complicate the process of creating clusters and replacing failed systems. Instead, create a DNS A or CNAME record for the RMS server and specify this entry, in the form of a Fully Qualified Domain Name (FQDN), as the intranet URL. The extranet URL, which you set after RMS installation, is easy to change.
You also need to decide where to place your first RMS server, which will become an RMS certification server. The RMS server component, which runs as a Web-based service and uses the Windows .NET Framework, can run on any edition of Windows 2003 and requires you to install Microsoft IIS 6.0, ASP.NET, and Microsoft Message Queue Services (MSMQ) on the server. The RMS client software component, which can run on Windows 98 Second Edition (Win98SE) or later, uses standard Web protocols (i.e., HTTP or HTTP Secure—HTTPS) to communicate with RMS servers (communication is secure regardless of whether you use HTTP or HTTPS). Each RMS server requires an ADO-supported database such as Microsoft SQL Server 2000 (preferably Service Pack 3—SP3—or later) to store configuration and log information and to cache expanded distribution lists (DLs). The RMS and database servers should be in the same domain. Clients contact the RMS certification server during activation and when obtaining an RAC. The RMS certification server needs to communicate with a Global Catalog (GC) server when authenticating users; with the Microsoft Enrollment Service during enrollment and when renewing its licensor certificate; and with the Activation Service when activating RMS clients (the RMS server accesses both these services over the Internet). The RMS certification server also performs as a licensing server to issue publishing and use licenses, so the server must be secure to protect RMS license information. You need to place the RMS certification server in a central, physically secure location, close to a GC server and to your database server, with good communications links to your clients and to the Internet. As a best practice, Microsoft recommends that you install RMS on a dedicated server. Figure 1 shows a sample RMS topology design.