Technical White Paper

Published: June 2009

Executive Summary

Introduction

Active Directory Rights Management Services

AD RMS Technology

Business Benefits of Deploying AD RMS

Deployment of RMS and AD RMS at Microsoft

Lessons Learned and Best Practices

Conclusion

For More Information

Executive Summary

With the continuing advancements and ubiquity of electronic communications in business, in addition to the growing reliance on technology for conducting day-to-day operations, companies have become vulnerable to the mismanagement and theft of intellectual property and sensitive business information. Microsoft employees rely very heavily on e-mail through the Microsoft® Office Outlook® 2007 messaging and collaboration client for both internal and external business communications. Microsoft employees also rely on Microsoft Office 2007 applications—such as Microsoft Office Word 2007, Microsoft Office Excel® 2007 spreadsheet software, the Microsoft Office PowerPoint® 2007 presentation graphics program, and the Microsoft Office InfoPath® 2007 information gathering program—to document and work with corporate ideas and other business-sensitive information. To remain a flexible and agile business, Microsoft needed a solution that could help protect the data of its business e-mail messages and documents without interfering with its users' ability to be productive.

The Microsoft information Technology (Microsoft IT) organization implemented Active Directory® Rights Management Services (AD RMS), which is the protection server role available in the Windows Server® 2008 operating system. It is the successor to Right Management Services (RMS) available for Windows Server 2003. AD RMS combined with Microsoft Office Professional Edition 2003, Microsoft Office Professional Plus 2007, Microsoft Office Ultimate 2007, or Microsoft Office Enterprise 2007 enables Microsoft staff to add usage restrictions to their e-mail messages and documents. The rights can specify who can open the document, what they can do with it, and how long they can open it. The rights are applied directly to the object being protected, whether an e-mail message or a document file, so the protections applied stay with the object regardless of whether it is sent in e-mail or stored as a file. Each protected message or document is encrypted and requires a use license from the AD RMS server to decrypt protected content and to apply the usage restrictions assigned to the consumer of that content.

Although the introduction of such a far reaching solution is always complex, Microsoft IT found that the actual design and implementation process was relatively straightforward. After Microsoft IT identified the appropriate information protection policies, mapping them to actual rights to be used and deploying the necessary technology did not involve any major environmental changes. Microsoft IT deployed both the server and client components without major impact to the users or to operational areas at Microsoft IT.

Since the worldwide implementation of AD RMS at Microsoft, each day, an average of approximately 5,000 documents and e-mail messages are protected to be consumed by 80,000 unique users. These numbers continually grow as an increasing number of users adopt AD RMS technologies as their preferred means of helping to protect their confidential e-mail and documents.

This paper discusses the need that Microsoft IT had for protecting confidential business data, the reasons for deploying RMS over other possible solutions, and how AD RMS works. This paper also offers detailed lessons learned and best practices derived from the RMS server and client deployment and usage experience of Microsoft IT. It assumes that readers are technical decision makers and are already familiar with the fundamentals of both public key cryptography and symmetric key security systems, the benefits that such systems offer, and the components required to implement the systems.

This paper uses the term "publisher" to denote someone who creates rights-protected content, such as an e-mail message or a document created in Office Enterprise 2007. The term "consumer" denotes someone who needs to retrieve a use license to open rights-protected content.

This paper is based on Microsoft IT's experience and recommendations as an early adopter. It is not intended to serve as a procedural guide. Each enterprise environment has unique circumstances; therefore, each organization should adapt the plans and lessons learned described in this paper to meet its specific needs.

Introduction

The privacy and security of confidential data and intellectual property are vital to a business. If a corporate e-mail system or a business productivity application does not allow an organization to control who can see e-mail messages and/or documents after they are sent to consumers, that system or application is limiting the organization's ability to conduct private business with agility and efficiency. Many businesses today may be unnecessarily restricting the use of e-mail systems or intranet Web sites for the dissemination of their confidential data because they lack knowledge of the technologies available to help safeguard that data. Conversely, other businesses simply may not comprehend the magnitude of the issue relating to electronic data privacy and security. They unintentionally and unnecessarily expose their confidential data to people or organizations that were never intended to have access.

Microsoft, like any other business that creates valuable intellectual property in a highly competitive marketplace, needed the ability to better secure and safeguard the privacy of its confidential data. Microsoft IT recognized that it needed technology to control how sensitive business e-mail messages and business productivity documents could be shared and used, without risking losses in productivity. More specifically, Microsoft IT needed to implement technology that offered the end-user publisher of confidential e-mail messages and business productivity documents the ability to manage who could consume their content, and limit usage of their content on a document-by-document basis. Without such technology, intellectual property, trade secrets, or incident management data belonging to Microsoft or its business partners might have been inadvertently or even maliciously exposed to the public, the media, or business competitors.

Active Directory Rights Management Services

Microsoft IT considered various technology tools that could help protect the confidentiality of sensitive data in business documents. However, in many cases, a viable solution for protecting one type of document placed unreasonable or technologically unfeasible demands on another type of document. Most of the solutions considered were simply incomplete or too easily bypassed by individuals with malicious intent.

The tool that Microsoft IT selected was AD RMS, a Microsoft .NET–connected Web service provided by Windows Server 2008.

AD RMS works with AD RMS—enabled applications, such as Office Enterprise 2007, to provide a means for publishers of confidential e-mail messages and documents to control who can view their content by attaching a usage rights policy directly to an object (such as an e-mail message or a document file). The rights can restrict how the content is used and who is allowed to use it. An organization can set different rights for various individuals and/or groups, based on user accounts in the Active Directory directory service (in Microsoft Windows® 2000 Server or Windows Server 2003) and Active Directory Domain Services (AD DS, in Windows Server 2008), users in trusted AD RMS environments, users in other directories integrated with Active Directory Federation Services, and users of the Windows Live™ ID–based AD RMS service. User rights for consumers can also be set to expire after a finite period.

Usage rights policies are associated directly with the protected content, not the container in which it is stored. Unlike access control list (ACL) permissions from a file system such as the NTFS file system, e-mail messages and documents protected with AD RMS technologies remain protected whether they are forwarded to an e-mail account outside the corporate firewall; sent as an e-mail attachment; or stored on a Microsoft SharePoint® Web site, a shared folder on a file server, a CD-ROM, a universal serial bus (USB) drive, or a floppy disk. Microsoft Office e-mail messages and documents that are rights-protected employ 128-bit encryption to help prevent unauthorized viewing and usage of content.

AD RMS serves as the platform for this technology. However, Microsoft also needed a client application that applied the technology of RMS. Microsoft IT found the solution with its enterprise-wide deployment of Office Professional Edition 2003, the first major end-user set of applications to support the RMS platform. Office Professional Edition 2003 introduced a feature called Information Rights Management (IRM), which enables policy rights definitions to be applied to both e-mail messages and documents created in the Office Professional Edition 2003 applications Microsoft Office Word 2003, Microsoft Office Excel 2003, Microsoft Office Outlook 2003, and Microsoft Office PowerPoint 2003. IRM-enabled editions of the Microsoft Office 2007 suites, such as Office Professional Plus 2007, Office Enterprise 2007, and Office Ultimate 2007, enhance these capabilities, adding support for protected InfoPath documents as well. Office Professional Edition 2003 and Microsoft Office Professional 2007 employ the technologies of the AD RMS platform to apply and enforce those policies.

To enable users running older versions of Microsoft Office to read rights-protected messages and documents, Microsoft IT also deployed the Rights Management Add-on for Internet Explorer® (RMA), a downloadable AD RMS–enabled client viewer plug-in. This plug-in is also useful to Microsoft employees who access their work e-mail on their home computers by using Microsoft Office Outlook Web Access. RMA enables rights-protected e-mail and attached Microsoft Office document files to be read through a Web browser.

At this time, there are no AD RMS–enabled applications to specifically help protect content within databases or within development environments for software source code. However, those environments are typically locked down by other means to help protect their valuable data from unauthorized access. AD RMS helps protect the forms of data that are almost always left unprotected—business documents, the vehicles in which confidential ideas, proposals, incident reports, and financial data are stored and used on a daily basis. AD RMS complements existing data safeguards within the enterprise organization, which enhances the organization's overall ability to protect its internal, private information.

Comparison with Other Technologies

AD RMS is not the only technology that can help safeguard the contents of e-mail messages and business productivity documents. Other technologies include Secure/Multipurpose Internet Mail Extensions (S/MIME), ACLs, Encrypting File System (EFS), and Windows BitLocker™ Drive Encryption. Each of these technologies serves a valuable purpose, and all are used within Microsoft. However, with regard to protecting the confidentiality of data, each of these technologies is applicable only in a specific set of circumstances. This section briefly describes the technologies and compares them with AD RMS in order to provide background on why Microsoft IT chose to deploy RMS.

S/MIME

S/MIME is a security-oriented superset of Multipurpose Internet Mail Extensions (MIME), an industry-standard protocol widely used on the Internet for e-mail. S/MIME adds public key encryption and support for digital signatures to MIME. Support for S/MIME technology has been available for several versions of Microsoft messaging products. However, S/MIME does not help protect confidential documents outside the realm of e-mail; nor does it control usage rights, such as the ability to restrict copying or printing protected information. Furthermore, after a recipient opens S/MIME-protected content, that recipient can forward the content to other recipients with the original protection removed.

ACLs

Security in Windows Server controls the use of objects through the interrelated mechanisms of authentication and authorization. After a user is authenticated, Windows Server uses authorization and access control technologies to determine whether an authenticated user has the correct authorization to access an object protected through access control lists.

ACLs for file and folder permissions require the use of NTFS. Any permission restrictions assigned to a document through ACLs are eliminated when the file is moved from the container where the permissions were set to another container that does not use NTFS. For example, an ACL that restricts all access to a document to a particular set of users will no longer be applied after that file is sent via e-mail or is copied by an authorized user to a disk medium not using NTFS (such as a floppy disk, a CD-ROM, or a hard disk formatted with any variety of the FAT file system). The document is then available to all users with access to that medium.

Also, ACLs allow any user who can read a document to copy, edit, or print the contents, so users allowed to access the document must be trusted not to redistribute the content inappropriately.

EFS

EFS helps protect sensitive data in all types of files that are stored on disk via NTFS. It uses symmetric key encryption in conjunction with public key technology to provide confidentiality for files. In EFS, unlike most other external encryption services, file encryption does not require the file owner to decrypt and re-encrypt the file on each use. Decryption and encryption of the file occur transparently as it is read from and written to the disk. EFS runs as an integrated system service, which makes it easy to manage, difficult to attack, and transparent to the file owner and to applications.

EFS encryption survives moves and renames, if all files stay on NTFS volumes. Copying or moving the encrypted file or folder to a disk medium formatted with any file system other than NTFS removes the encryption and returns the file to its normal format.

Additionally, only the person who applied EFS encryption to a file or users who are specifically assigned the right to decrypt files can decrypt the file and work with it. Other users—even a file owner—cannot open an EFS-encrypted file unless a decryption key has been generated and encrypted with their public key.

BitLocker Drive Encryption

BitLocker, a full volume encryption technology in the Windows Vista® Enterprise and Windows Vista Ultimate operating systems and in all editions of Windows Server 2008, allows for the encryption of complete disk volumes, including all the data that they contain. This enables the protection of operating system files, data files, and metadata, providing integral protection against offline unauthorized access. Because data decryption occurs automatically when the system is running, BitLocker does not protect data against authorized users of the system, but offline attacks (such as those typically performed on stolen laptops) are effectively blocked by strong drive encryption. BitLocker can store the drive encryption keys in a Trusted Platform Module (TPM), a hardware device incorporated in many computer systems that allows for the secure storage of security keys, among other functions. The TPM also assists in the validation of the boot sequence to detect unauthorized modification in order to guarantee that the boot environment is a valid one before the user is allowed to log on.

The encryption keys can also be stored in an USB key that is then necessary for the computer to start. Alternately, the encryption key can be stored in the system protected with a personal identification number (PIN) that the user must manually enter every time the computer starts.

BitLocker provides strong protection against unauthorized computer access. However, it does not differentiate between users, so it is not a tool to provide protection between different authorized users of a system. Also, because BitLocker Drive Encryption applies to the storage medium directly and not the data files, data is only protected as it is stored in the original disk. Copying of the data by an authorized user to another system or to another unprotected storage medium removes all protection provided by BitLocker from the data.

Comparing the Technologies

Table 1 compares IRM in Microsoft Office with S/MIME digital signing, S/MIME encryption, ACLs, EFS, and BitLocker.

Table 1. Comparison of Technologies Used to Help Safeguard Confidential Data

1 AD RMS relies on operating system user authentication to validate the users identity. Although AD RMS does not perform user identity attestation, its document signing operations, together with proper user authentication at the operating system level, can be considered to provide source identity guarantees to the extent that operating system authentication can be trusted in each specific environment.

2 ACLs can be set to modify, write, or read-only but only apply to the original container of the document.

3 EFS encryption is maintained with a copied or moved file only if the destination folder is also on an NTFS-formatted volume and, when copying, the destination folder is marked for encryption.

4 IRM technologies cannot be considered "hacker proof" because they rely on the integrity of the client computer's lockbox. Thus, a skilled attacker with direct control of the files where a document is stored might be able to perform unauthorized operations with the document. Also, if an attacker is able to obtain credentials for a user with rights to perform operations on a document, either through technical means or social engineering, the attacker will be able to perform any operation on the document that the legitimate user had rights to perform.

5 These protection systems rely on operating system user authentication to provide access to the protected content. Although these technologies do not support storing the encryption key in a smart card directly, they support storing it under a protected store that can be accessed only after the user is authenticated. This process can require a smart card if the corresponding policies are enabled.

After analyzing the various alternative technologies for safeguarding confidential data and comparing them with IRM and RMS, Microsoft IT determined that RMS met most of its requirements. Although Microsoft IT determined that no single solution would cover all potential risks to unauthorized data disclosure, RMS offered an excellent complement to other technologies being used to help protect systems and data, providing key protection to documents independently of their location and applying usage policies to documents that limit their unauthorized distribution. The ease of use for both generation and consumption of protected documents also helped to keep support costs low, something that always has to be considered when introducing new technology with end-user impact.

AD RMS Technology

When someone attempts to open a rights-protected document or e-mail message, AD RMS identifies the consumer through the Simple Mail Transfer Protocol (SMTP) e-mail address assigned to the consumer's Active Directory logon account. AD RMS then compares this identification with the list of rights associated with the protected content. If the specified consumer has been granted user rights, either individually or through inclusion in a distribution group, the AD RMS server issues a use license to the consumer.

Licenses

To open documents protected by AD RMS–enabled applications, a consumer needs a digital license from the AD RMS server. There are two types of licenses: publishing and use.

Publishing License

A publishing license is created when a document (including an e-mail message) is originally protected. Every document protected gets its own publishing license. AD RMS provides for the creation of publishing licenses in two ways: online and offline. Online publishing requires connectivity with the AD RMS server, whereas offline publishing does not. IRM in Microsoft Office always publishes its content offline. To do so, the AD RMS client computer generates a publishing license without contacting the AD RMS server. However, for the publishing license to be generated, the offline client must have already been activated and received its publishing certificate. The publishing certificate is generated by the AD RMS server and downloaded to the client computer when its first piece of rights-protected content is published, requiring online access to the AD RMS server.

End Use License

An end use license (also called use license, UL, or EUL) is required to consume the protected content. An AD RMS–enabled application uses the EUL to decrypt the content, and then enforces the specific usage restrictions assigned to the consumer. Each protected piece of content requires its own use license.

The AD RMS server generates use licenses in response to a valid license request, which is typically made when a consumer who has rights to a protected e-mail message or document opens that item for the first time. Use licenses can be cached and reused to open a protected document, depending on the rights policy. In cases with Microsoft Office documents, if the consumer has write access to the file, the use license is appended to the protected document file. The user can then open the protected content again on any computer that has been activated with that user's account without requiring network access to the AD RMS server until the use license expires.

With Office Outlook e-mail messages, the end user's computer stores the use license locally after the computer obtains it from the AD RMS server. Because Microsoft IT uses Office Outlook with cached mode enabled, it configured Office Outlook to automatically obtain use licenses for rights-protected e-mail messages during the synchronization process with a Microsoft Exchange server. Microsoft IT specifically enables this by setting a registry key during installation. If Microsoft IT had left the default setting in place, at the first time the end user attempted to open a rights-protected e-mail message or document, a dialog box would have appeared, asking whether the user wanted to permanently enable this behavior. If enabled, this option would have set the same registry key that Microsoft IT preset during installation.

Some policies can be set to expire use licenses after each time a user accesses protected content. In these cases, the user must have online access to the AD RMS server to receive another use license before that content can be reopened.

Types of Rights Available

By using AD RMS–enabled applications, such as Office Word 2007, Office Excel 2007, and Office PowerPoint 2007 from Office Enterprise 2007, a document owner can apply rights to a document file through one of three methods:

• Read or Change)
• Customized combinations of rights assigned to each specified individual or group of consumers
• Templates that the AD RMS administrator creates to apply a predefined set of rights to a predefined set of individuals or groups of consumers

Alternatively, e-mail senders can use Office Outlook to apply rights to the message and any unprotected Office Word, Office Excel, or Office PowerPoint document attachments that might be included. By default, the only rights setting that Office Outlook 2007 offers is a read-only rights for e-mail messages and any attached document files from applications that support AD RMS. However, a customized rights policies template for Office Outlook can be used to expand the number of rights offered.

Each of the rights available in IRM-enabled editions of Microsoft Office 2007 offers or limits certain activities that a consumer can perform with the protected content. The rights that IRM makes available can grant or deny consumers permission to read, save, copy, modify, print, and forward protected objects. User rights can also be set to expire on a preset date. Table 2 discusses the details of what each of these rights does to help protect content.

Table 2. IRM Rights and Their Definitions

* Document expiration does not destroy the document. Only the right to open the document expires.

By default, not all document types in Office Professional Edition 2003 offer the ability to set all of the rights available in IRM. Table 3 lists the policy restrictions available in the AD RMS–enabled applications within Office Professional Edition 2003 and IRM-enabled editions of Microsoft Office 2007.

Table 3. Applicable Policy Restrictions

* In Office InfoPath, these capabilities are available only for forms, not for form templates.

In Microsoft Office 2007, rights are applied to objects hierarchically. For example, consider an Office Word 2007 document that is attached to an Office Outlook 2007 e-mail message. If rights are not applied to the document before it is attached but are subsequently applied to the e-mail message, the attached document inherits the rights applied to the e-mail message. If rights are applied to the document before it is attached, e-mail rights do not affect the document's rights.

In Office Outlook 2003 and Office Outlook 2007, a message can be expired at a certain date through the Expiration setting under Options. If the Do Not Forward (the read-only setting) option is selected and message expiration is set, IRM enforces the expiration setting.

Customized AD RMS Templates Available from Microsoft IT

The IRM-enabled applications in the corresponding editions of Microsoft Office support the use of preconfigured, default, rights-setting policy templates to help enterprises define the most commonly needed standardized sets of rights for safeguarding documents.

For example, with Office Outlook e-mail, the only default assignable IRM setting is read-only. Through an AD RMS template, customizable rights beyond the default can be applied. All of the AD RMS–enabled applications in Office support the same policy templates.

Microsoft IT offers users at Microsoft five AD RMS templates to help protect Microsoft Office e-mail messages and documents. All of these templates define the intended audience, based on the use of specific company distribution groups and the specific rights provided to that audience. The templates are identified as follows:

1. Microsoft Confidential
2. Microsoft Confidential Read Only
3. Microsoft FTE Confidential
4. Microsoft FTE Confidential Read Only
5. Do Not Reply All

With the first two templates, the distribution group used is the Microsoft All Staff distribution group. This group includes all Microsoft full-time employees (FTEs), contractors, and vendor staff. Any person not included in this distribution group, such as people outside the company, cannot open content protected through this template. The second template modifies the first template with the application of restrictive read-only rights.

The third and fourth templates use the Microsoft FTE-only distribution group. Any person not included in this distribution group—such as contractor and vendor staff, along with anyone outside the company—cannot open any content protected through this template. The fourth template applies the restrictive read-only rights to the FTE distribution group.

Finally, when the Do Not Reply All template is applied to a message, its recipients cannot use the Reply All function, preventing large volumes of response traffic to messages sent to many recipients.

The master version of a rights policy template resides in the AD RMS database and is always used when a use license is created so that the most recent policy set by the AD RMS administrator is enforced. Each template created must be exported to each AD RMS client computer that needs to use the template. These local versions of the templates do not need to be updated every time the AD RMS administrator updates the template, because the AD RMS server uses its own copy when evaluating the rights specified in the template. However, templates still need to be available locally for a user to select them when performing offline publishing, as in the case of Microsoft Office applications.

If the feature that requires a new use license with every access is used with a template, rights policies can be dynamically changed after the document has been published or sent in e-mail. This way, the company retains the option to further restrict or loosen control on one or more users at any time.

Encryption Used with AD RMS

When content is published through AD RMS, it can be encrypted with Advanced Encryption Standard (AES) 128-bit encryption, though the system supports Data Encryption Standard (DES) 56-bit encryption for backward compatibility. The publishing application determines the strength of encryption used. Microsoft Office 2007 always uses AES 128-bit encryption to help protect its content.

Symmetric key encryption—the type of encryption used by AD RMS–enabled applications—uses the same key to encrypt and decrypt content. All AD RMS servers, client computers, and user accounts also have a public and private pair of 1,024-bit Rivest-Shamir-Adleman (RSA)–based encryption keys. AD RMS uses the public and private keys to encrypt the content encryption symmetric key along with the rights policy data in the publishing license and the use license. AD RMS also uses the public keys to digitally sign AD RMS certificates and licenses, helping to ensure that certificates are not tampered with when users use them to open protected information.

Process That IRM Uses to Generate and Retrieve Licenses

To publish data with AD RMS technologies enabled, document publishers follow the same logical and fundamentally interlinked workflow that they already use for their information, such as sending an e-mail message or posting to a SharePoint Web site.

Figure 1 summarizes how AD RMS works when users publish and consume rights-protected content to a file folder, as with Office Enterprise 2007 applications and IRM policies.

Figure 1. Process of generating and retrieving licenses for rights-protected content

This process includes the following steps:

1. An author creates a document that contains confidential content by using an Office Professional Edition 2003 or an IRM-enabled Office Professional 2007 application, such as Office Word, Office Excel, Office PowerPoint, or Office InfoPath. To customize the usage rights of the document, the author clicks the Permission toolbar button, which displays the Permission dialog box. On the first page of the Permission dialog box, the author can assign either Read-only or Change rights to all consumers or to specific individuals and/or distribution groups. If the author needs greater control, he or she can click More Options to assign Full Control to individuals and/or distribution groups, or further modify the Read-only or Change rights. From this dialog box, the author can further customize the settings by using all of the rights listed earlier in Table 2.
2. Office always publishes content offline. However, to enable that function, a publishing license, also known as the Client Licensor Certificate (CLC), must first be installed on the publishing computer. The CLC, generated by the AD RMS server, is encrypted with the rights account certificate (RAC) public key and the public key of the AD RMS server, and is therefore unique to each publishing computer. After the computer obtains the CLC, the publisher does not need online access to the AD RMS server to publish content. The publisher uses one CLC to publish all offline content generated from the publishing computer.

   Note: If the publisher has never before published rights-protected content, a CLC has not yet been installed. The publishing computer requests a CLC from the AD RMS server upon the first instance of publishing rights-protected content. The AD RMS server generates the unique CLC and sends it to the publishing computer, thereby enabling Microsoft Office to publish rights-protected content offline.

3. The Microsoft Office application uses the installed CLC to generate and sign the document's publishing license. Then, the AD RMS client application programming interface (API) encrypts the document file with the random symmetric key and binds the publishing license to the document file. The random symmetric key used to encrypt the protected file is joined with the rights policy assigned to the encrypted object and encrypted with the public key of the AD RMS server. Only the AD RMS server that issued the CLC to the publisher can issue licenses to decrypt and open the symmetric key–encrypted content. The publishing license contains the URL of the AD RMS server.

   Note: If the author is using an AD RMS–enabled application that performs online file publishing, a CLC is never created; nor is one used as part of the publication process. Instead, the application contacts the AD RMS server to obtain its Server Licensor Certificate (SLC). It then generates a symmetric key (the content key) and encrypts it by using the public key from the SLC. The encrypted content key is then put in a publishing license along with the usage policy, also encrypted with the SLC public key. The encrypted content key includes a URL pointing to a server that can issue use licenses for the document based on this publishing license. The completed publishing license is then sent to the server to be signed.

4. The author distributes the protected document.
5. A consumer receives the rights-protected Microsoft Office document through a regular distribution channel, such as e-mail or removable disk storage media. The consumer opens the document by using either an AD RMS–enabled Microsoft Office 2003 or Microsoft Office 2007 application, or Internet Explorer via the RMA.
6. The Microsoft Office application sends a request for a use license to the AD RMS server that issued the CLC used to help protect the content. The request includes the consumer's RAC with the consumer's public key, the publishing license with the encrypted copy of the symmetric key that was used to encrypt the contents, and the rights policy information.
7. The AD RMS server validates that the consumer is authorized, checks that the consumer is a named user, and creates a use license. During this process, the server decrypts the symmetric key by using the private key of the server, re-encrypts it by using the public key of the consumer, and adds it to the use license, which contains the rights specified in the rights policy information of the use license request. This information includes any relevant conditions to the use license, such as the expiration, an application, or an operating system exclusion. This step helps ensure that only the intended consumer can decrypt the symmetric key and thus decrypt the protected file.
8. When the validation is complete, the AD RMS server returns the use license to the consumer's client computer.
9. After receiving the use license, the AD RMS client software component examines both the use license and the consumer's RAC to determine whether any certificate in either chain of trust requires a cross-check against a certificate revocation list (CRL). If so, the AD RMS client software retrieves a current copy of the CRL from the location specified in the use license. The AD RMS client then applies any revocation conditions that are relevant in the current context. If no revocation condition blocks access to the protected document file, the Microsoft Office application renders the data, and the consumer can exercise the rights that he or she has been assigned.

Alternatively, when using Office Outlook 2007 or Microsoft Office Outlook Mobile on Windows Mobile® 6.0 software with AD RMS, an optional Microsoft Exchange Server 2007 component called the Exchange Prelicensing agent can perform the user validation and authorization at the Exchange Hub Transport server, and issue the use license before the message is delivered to the user. This means that when the user receives the message, the use license is also received and stored together with the content, preventing the need for the user to connect to the AD RMS server when the message is open.

The Exchange Prelicensing agent is part of Exchange Server 2007 with Service Pack (SP) 1, and is installed automatically on all Hub Transport servers installed with this version. For Exchange Prelicensing agent to work reliably, it must be installed in all Hub Transport servers in the infrastructure. All those servers must be running Exchange Server 2007 with SP1 or later. Additionally, the Windows RMS Client 1.0 SP2 or AD RMS client on the 64-bit editions of Windows Server 2008 must be installed on the computers that perform the Hub Transport server role.

Secure Sockets Layer Connections Used for All AD RMS Communications

Microsoft IT configured AD RMS such that all communications between clients and the AD RMS servers are conducted through Secure Sockets Layer (SSL) tunnels, regardless of whether the connection passes through the corporate firewall or not. This extra precaution helps ensure the security of the data transmitted.

AD RMS Licensing Outside the Firewall

The AD RMS licensing process functions essentially the same way whether the content consumer is within the publisher's network boundary or outside it. For content consumers at Microsoft attempting to open internally licensed rights-protected content outside the corporate network boundary, Microsoft IT considered two options:

• Placing an AD RMS server in a perimeter network (also known as a DMZ, demilitarized zone, and screened subnet) between its firewalls, enabling its users with Internet connections to receive the use licenses needed to open protected content.
• Publishing the internal AD RMS servers through Microsoft Internet Security and Acceleration (ISA) Server reverse proxying capabilities.

Because installing AD RMS servers in the perimeter network implied significant communication needs between the external AD RMS servers and the internal database servers (which must be shared with the internal AD RMS servers), Microsoft IT chose to publish the internal servers through ISA Server.

Microsoft IT required its external users to successfully enter their Windows authentication credentials to connect to the AD RMS servers before a use license was provided based on the user's RAC.

For valid consumers of rights-protected content to be able to open that content when they are outside the Microsoft corporate firewall, a pair of URLs (one internal, one external) for the server that created the document's publishing license (or in the case of the use of a CLC, the server that issued the CLC) was embedded within the publishing license of every protected document. If the content is not prelicensed through the Exchange Prelicensing agent, which is the case for all Office Outlook 2007 and Office Outlook Mobile messages on Windows Mobile 6.0 and Windows Mobile 6.1, the Microsoft Office application first attempts to connect to that AD RMS server with the intranet URL to get the use license. If the internal URL fails to resolve, the application then attempts to use the external URL. As long as the client computer is connected to the Internet, the AD RMS server can be accessed. However, because the user is not authenticated on the Microsoft corporate network, the consumer will first be prompted for valid user name and password credentials. After the credentials have been validated, the use license (and, if necessary, a temporary RAC) can be issued, enabling the client to open the protected content. If the content is prelicensed, the use license is already in the client, so no connection or authentication request is performed.

Caveats for Semi-Trusted Computers

Microsoft IT classifies employee-owned home computers running Windows XP or Windows Vista that are not managed by Microsoft IT, but are used to access corporate e-mail via Office Outlook Web Access, as semi-trusted computers. Employee-owned mobile devices that are used to read corporate e-mail are also classified as semi-trusted computers.

The ability of the content consumer to open rights-protected e-mail messages and documents depends on the ability of the consumer's computer to acquire and use digital licenses. Because of the wide variety of hardware computing platforms and possible operating system and software configurations, and because Microsoft IT does not manage these computers, properly configuring semi-trusted computers to open rights-protected e-mail messages and documents can be challenging for the end user.

Use of RMA to Open Rights-Protected Content

Consumers not using Microsoft Office 2003 or Microsoft Office 2007 can view rights-protected Office Outlook e-mail messages and attached protected Microsoft Office documents after they install the RMA for Internet Explorer. Because RMA is a viewer that runs within Internet Explorer, it enforces the rights set by the publisher but cannot enable the consumer to edit protected content, even when that right was assigned to the consumer. RMA requires the client computer to have online access to the AD RMS server for receiving a use license.

Consumers can always use RMA to view Office Outlook messages, but other rights-protected document types created in Microsoft Office applications must explicitly specify that RMA can be used when the publisher applies the IRM policies. The publisher enables the RMA viewing policy in documents by selecting the Allow users with earlier versions of Office to read with browsers supporting Information Rights Management check box in the More Options section of the Permissions dialog box in Office Word, Office Excel, Office InfoPath, and Office PowerPoint. This option can be set in an AD RMS policy template for easier application.

To install RMA on a semi-trusted computer, the logged-on user account must have sufficient permissions (such as administrator permissions on computers running Windows XP Professional, or the ability to enter Administrator credentials when prompted on Windows Vista). Any semi-trusted computer on which the consumer has permissions to install software can be enabled to view rights-protected e-mail messages and attached documents through RMA.

Limits on Creating Rights-Protected Content

Although consumers can view rights-protected content through RMA, the only way to publish rights-protected content is from rights management–enabled applications. Any program that produces, stores, manages, displays, transports, or consumes data can be written to take advantage of AD RMS services. Office Professional Edition 2003 and IRM-enabled editions of Microsoft Office 2007 applications such as Office Word, Office Excel, Office PowerPoint, Office InfoPath, and Office Outlook are joined by third-party software in their support for AD RMS–protected documents.

For applications that do not support the creation of AD RMS–protected documents directly and that cannot export documents in a format that is compatible with IRM-enabled Microsoft Office applications but that can send content to a printer, rights-protected content can be produced because of the XML Paper Specification (XPS) writer introduced with AD RMS.

XPS is a device-independent and resolution-independent page description language developed by Microsoft that allows for document interchange. Any application that can print documents running on Windows XP, Windows Vista, Windows Server 2003, or Windows Server 2008 can create XPS documents. Users of those operating systems who have installed the Microsoft .NET Framework 3.0 or later, or the stand-alone XPS viewer (which comes preinstalled in Windows Vista), can view XPS documents. By printing a document to the Microsoft XPS Document Writer virtual printer, a user creates a document in the XPS format that is visually identical to a printed copy of the document, and that can be shared with any user who has a computer that can display XPS documents or that has the RMA installed.

Normally, XPS documents generated this way can also be edited by its recipients through a third-party XPS editor, and they can be printed and forwarded to third parties. To prevent or control this, the user who created the XPS document can open it in the XPS viewer and apply rights protection to it just as he or she would with IRM-enabled Microsoft Office applications. In this way, a user of any application that can print documents and that has the XPS writer installed can create documents that can be rights protected and shared with third parties in a controlled fashion without requiring that the same applications are installed on the recipient's computer.

Limits on Mobile Devices

Windows Mobile 6.0 and Windows Mobile 6.1 support AD RMS in Microsoft Office Mobile and Outlook Mobile. Outlook Mobile does not use the same templates that Microsoft Office uses on the desktop; the available protection options are restricted to the ability to send messages marked as Do Not Forward. Office Mobile allows for reading documents protected with IRM in the desktop version of Microsoft Office, but it does not allow for the creation or addition of protected messages on the mobile device, regardless of the rights assigned to the user.

Business Benefits of Deploying AD RMS

Microsoft realized several benefits after Microsoft IT deployed RMS combined with the IRM feature in Microsoft Office. AD RMS fills a technology gap that no other product serves, both in the e-mail space and with other business productivity documents, in helping users manage who can open their content and how their content can be used or shared.

The benefits that AD RMS technologies provide can be classified into three categories: enterprise, end user, and IT.

Enterprise Benefits

The following benefits are most applicable to enterprises.

Data/Information Leakage Prevention

The ability to protect intellectual property within Office e-mail messages and documents helps safeguard Microsoft corporate assets against accidental or intentional leakage. Only authorized consumers can decrypt and open rights-protected messages and documents. Unauthorized consumers cannot open encrypted content at all, whereas the document usage abilities of authorized consumers are limited to the rights settings assigned by the publisher.

By helping to protect confidential business data, Microsoft and its business partners can feel more assured that the sensitive information they create, along with related written reports and e-mail discussions, will remain confidential.

Greater Sharing of Sensitive Information

The content protection of IRM reduces the risk of unintentional exposure of confidential materials. The data publishers' confidence, derived from that reduction of risk, enables them to take greater advantage of Office Outlook and SharePoint Web sites for disseminating sensitive business information. Because this information is available, recipients can make better, faster decisions, thereby improving business agility.

This confidence enables Microsoft and its business partners to use business-efficient means of transmitting confidential information between one another, such as e-mail and secured intranet Web sites, to remain highly flexible and agile to respond to changing business and market conditions.

Application Support

AD RMS is a platform that can be incorporated into both commercial applications and internally developed line-of-business (LOB) applications to help protect information. This solution makes it possible to incorporate protection across the entire range of corporate information. Microsoft IT, the team deeply involved in the design and implementation of more than 1,500 internal LOB applications at Microsoft, is busy designing next-generation LOB applications that are AD RMS enabled to better safeguard confidential data. For more information about the AD RMS software development kits (SDKs), go to http://msdn.microsoft.com/en-us/library/cc530379(VS.85).aspx

Common AD RMS Language

AD RMS technology uses Extensible Rights Markup Language (XrML) version 1.2.1 as the common language for expressing rights, which enables organizations to minimize the investment required to take advantage of AD RMS technology. XrML is a flexible, extensible, and interoperable standard equipped to meet any organization's needs, regardless of industry, platform, format, media type, business model, or delivery architecture. XrML is a standard that defines a language for expressing rights and conditions for the consumption of content in a way that is independent of the individual implementation. Although different types of content might have somewhat different interpretations of the exact actions that a specific right expressed in XrML should allow, the general meaning of the restrictions and the way to express them are not platform or product specific.

Using a standard certificate format enables AD RMS to be extended and to interoperate with third-party products, while helping to ensure compatibility as future versions of the platform and third-party solutions evolve.

End-User Benefits

The following benefits of offering AD RMS in the enterprise apply to end users.

Simple Tools for Users

Document publishers can assign usage policies to their content by using any application that is AD RMS enabled, such as Office Enterprise 2007 or any internally developed LOB application written to support AD RMS. Usage policies specify who can open the information, the specific rights assigned to each of the consumers, and how long those consumers can view or use the protected content. Specified users can open the rights-protected content with a simple click of a mouse, as they would any other file. Verification of usage policies is transparent to users.

Powerful Document Protection Features

AD RMS technology enables persistent file-level protection, extending and enhancing existing network security efforts. Content owners can specify usage policies for their data, such as print, copy, and expire, giving them more features and options for protecting that information on the company intranet and in some extranet scenarios.

Ubiquitous Access

Rights-protected documents can be accessed from inside the network and from the Internet. Protected documents can also be created and consumed while offline, and can be stored in a mobile device's disk or in removable media with less danger of unauthorized access. Protected content can be accessed and created from Windows Mobile devices such as mobile phones, and can be consumed from any computer, even unmanaged computers, that can run Microsoft Internet Explorer 6 or Windows Internet Explorer 7 and the RMA.

This gives authorized content creators and consumers the freedom to keep accessing, creating, and managing documents from all their normal locations, while helping to keep information safe from unauthorized users.

IT Benefits

The use of AD RMS as the solution to help safeguard confidential data offers the following benefits to the enterprise IT department.

Ease of Implementation

With the release of AD RMS, Microsoft has focused on minimizing the effort required by enterprises to implement an IRM solution. Installing the AD RMS role is as easy as enabling other Windows Server 2008 roles, and administrators can then connect it to other enterprise-critical servers such as those running Exchange Server or to external services, build and enforce usage policies, and establish trusted entities outside the organization. AD RMS provides several possible ways to deploy either single-cluster configurations or a global, distributed AD RMS system topology. Although the complexities of information protection make this a job that requires careful planning and design, the actual implementation process is relatively simple.

As a stateless Web service, AD RMS can also be scaled up or out through standard and well-known technologies to meet enterprise growth needs.

Ease of Administration

Administrative features of AD RMS, such as revocation lists and exclusion policies, provide a new level of control for sensitive and proprietary content at Microsoft. In addition, comprehensive logging enables Microsoft IT to monitor licensing activity, including granted and denied requests.

The general use of rights policy templates enables an enterprise to define and roll out communication policies that are consistent across the organization and digitally enforced. AD RMS administrators design and control the content of the templates, and store them on the AD RMS servers for the enterprise publishing community to use. AD RMS administrators can easily modify the template definitions of approved consumers and the rights they are assigned within a rights-protected document. Templates offload the effort of determining who should be assigned user rights and what types of rights the intended consumer should receive from the publisher, simplifying the process that the publisher needs to follow. Furthermore, when modifications to a template occur, all past, present, and future content based on that template will inherit the new rights when a use license is issued.

Deployment of RMS and AD RMS at Microsoft

Microsoft IT differs from the IT organizations of other large enterprises in one significant way: Microsoft IT plays a significant role in the software development process as the "first and best customer" of Microsoft. In that role, it deploys Microsoft products into a production environment well before they are available to any other Microsoft enterprise partners and customers. In addition, Microsoft IT strives to be the model enterprise for deployment of those products. However, Microsoft IT does not deploy every Microsoft product. Rather, it focuses only on those products that are targeted toward large enterprise organizations and for which a clear and compelling business case exists for deploying the products within Microsoft.

Microsoft IT initially deployed Rights Management Services on top of Windows Server 2003 in the year 2003. When AD RMS became available with Windows Server 2008, Microsoft IT updated the infrastructure to the new platform.

Approach and Strategy

As with any major deployment in Microsoft IT, the key to success for the RMS deployment was careful planning. Microsoft IT obtained topology diagrams, product specifications, hardware and scalability estimates, and other product documentation published by the RMS product group that could help plan the deployment and identify the hardware needs. The performance goals that Microsoft IT had for RMS included less than 5 percent impact on network domain controllers and a completion rate of at least 95 percent of all licensing requests within five seconds.

Microsoft IT studied the projected network traffic that RMS would add to its infrastructure, based on deployment information that the RMS product group provided in the Deploy.chm file (a component of the RMS installation). The product group established a benchmark measurement of RMS by using a 1-gigahertz (GHz) Intel Pentium 4 server that had four processors and 1 gigabyte (GB) of random access memory (RAM). In this configuration, the RMS server delivered approximately 100 licenses per second.

the RMS product group provided the capacity planning figures in Table 4 for estimating the usage requirements for an RMS system.

Table 4. Estimated Usage Requirements for RMS

Microsoft IT also recognized that the Active Directory query traffic generated by RMS might potentially affect network throughput. However, Microsoft IT determined this would not be a major factor if RMS servers were deployed in close proximity to the global catalogs. The exception would be if a failure of all global catalogs at a site caused a failover to another site over a connection that did not support the same capacity throughput.

Table 5 provides baseline data on the bandwidth usage of AD RMS transactions that can be used to assess the effect of Active Directory query traffic on a network.

Table 5. Baseline Data for Active Directory Traffic Bandwidth Usage

Analysis of the projected usage of RMS within Microsoft IT's network infrastructure showed the impact to be negligible. Table 6 illustrates the specific effects that RMS has had on the Microsoft corporate network.

Table 6. RMS Network Load Metrics within Microsoft IT

By using the information gathered during the planning phase, Microsoft IT decided on the deployment topology, the number and class of servers to order, and the service availability requirements.

In January 2003, Microsoft IT began preparations for its initial RMS deployment. Based on the RMS product group projections and the results of Microsoft IT lab testing, Microsoft IT predicted that approximately 2 percent of all e-mail messages and attached business productivity documents sent within Microsoft would use IRM to enforce policy. Microsoft IT based this figure on its knowledge of its user base, the likelihood of the general population to adopt new technologies, and to what degree the new technology would be used within the company.

Scalability test data provided by the RMS product development group revealed that in the case of Microsoft IT, two standard-configuration servers would handle the load for all users within the company. This configuration included dual Intel Pentium 4 2.4-GHz computers with a 512-kilobyte (KB) Level-2 (L2) memory cache and 512 megabytes (MB) of RAM, set up as a load-balanced cluster pair.

To accommodate unanticipated usage growth, in addition to future expansion of RMS to LOB applications and other Microsoft and partner applications, Microsoft IT upgraded the RMS server specification to a four-processor, 2.4-GHz computer with 1 GB of RAM.

The corporate Active Directory infrastructure largely dictated the number of RMS server clusters that Microsoft IT needed to deploy. RMS, by design, initially looks in the account logon forest for issuing RACs and licenses. To offer all user accounts access to RMS technologies, Microsoft IT deployed a load-balanced RMS cluster in all corporate network forests that contain user logon accounts. Besides the main corporate forest, three other forests are used with logon accounts at Microsoft, primarily for testing of cross-forest functionality of enterprise software and to isolate other developmental testing efforts.

To simplify administration and troubleshooting issues with RMS, Microsoft IT chose to route all document publishing licensing requests to the main corporate forest RMS cluster, which contains more than 90 percent of all Microsoft logon accounts. Routing publishing license requests to the main corporate forest resulted in higher availability and scalability requirements than those of the other three logon forests. To meet the higher overall workload, Microsoft IT added a third, identically configured RMS server to the primary corporate logon load-balanced cluster for failover support in cases of hardware failure. To accommodate future load, Microsoft IT expanded this configuration to four servers for the production forest as part of the migration to AD RMS in 2008.

Additionally, to meet its internal security requirements for protection of the RMS server's private key, Microsoft IT elected to include nCipher nShield hardware security modules (HSMs) on its RMS server specification.

Microsoft IT originally used Microsoft SQL Server® 2000 database software for the required RMS transaction log database in each forest, though Microsoft IT later migrated this to Microsoft SQL Server 2005 when it implemented AD RMS. SQL Server provides the ability to use transaction log shipping as a means to maintain a warm standby secondary server, as well as the option of using failover clusters for immediate failure resolution of hardware or system problems.

The final step in determining the deployment topology was identifying the connectivity methods for which Microsoft IT wanted to support RMS licensing. In particular, Microsoft IT determined that users need to have the ability to obtain licenses while not logged on to the corporate network. Microsoft IT decided to place RMS behind servers running ISA Server, so that it could use externally accessible URLs for RMS servers.

Figure 2 illustrates the AD RMS topology for the main corporate forest.

Figure 2. AD RMS topology for the main corporate forest

Microsoft IT concluded that it would need a four-processor, 2.4-GHz computer with 1 GB of RAM and configured with 10 GB of available data storage space for the RMS and system database servers. In total, Microsoft IT purchased 13 servers for deploying RMS to all four forests with logon user accounts.

During the migration to Windows Server 2008 AD RMS, Microsoft IT replaced the servers with systems that had 3 GB of RAM and two 3.2-GHz processors. This replacement was part of the normal hardware refresh cycle; the new platform did not require the updated hardware to support the existing load.

The actual deployment of RMS, including installation and provisioning, was straightforward. The majority of time spent during the installation consisted of preparatory steps not directly tied to the RMS product itself. Work included the following:

• Pre-deployment planning. The following planning steps were required prior to the deployment of software:
  1. Develop end-user usage scenarios
  2. Determine extranet usage needs
  3. Prepare database backup and disaster recovery plan
  4. Design template definitions with the legal department
  5. Create RMS client deployment plans
  6. Create end-user computer settings for distribution
  7. Create RMS service accounts with appropriate permissions
  8. Create service URLs
  9. Acquire SSL certificates
  10. Establish required cross-forest trust policies
  11. Create data retention and recovery policy
  12. Establish Super User group membership policy
  13. Perform cluster size planning
  14. Acquire computer hardware
• Preparing servers. Microsoft IT set up and configured the server hardware for both RMS and SQL Server as necessary.
• Installing and configuring HSMs. Besides the hardware setup and operating system and database server installations, installing and configuring the nCipher nShield hardware security modules consumed most of the setup time—approximately one hour per RMS server. Microsoft IT provisioned the first server in the root cluster, and then copied the private key of the first server to the local HSM for each additional server in the cluster. Microsoft IT also copied the SSL certificate of the first server to each additional server in the cluster.
• Setting up RMS on root servers. The end-to-end setup of RMS on the root server in each load-balanced cluster took approximately 20 minutes. Each additional RMS server took no more than five minutes to install and join to the existing cluster.
• Setting up databases. At the completion of the RMS setup, database administrators configured the recovery model for the RMS databases. Database administrators also set up database maintenance plans to perform database and log backups, database consistency checks, and log shipping, as appropriate. Microsoft IT implemented a simple recovery model for the directory services and logging databases, with a full recovery model and transaction log shipping on the configuration database.

It took approximately one month for Microsoft IT to order, configure, and deploy the RMS servers. The expenditure on hardware to initially implement RMS within Microsoft totaled approximately U.S. $56,000.

After the initial implementation in 2003, Microsoft continued to evolve the RMS technology, with Windows Server 2008 providing AD RMS as the next major release. During the development phase of Windows Server 2008, Microsoft IT decided to implement this technology as part of its early adoption practices.

Because AD RMS does not depart significantly from RMS in Windows Server 2003 from an architectural point of view, it did not require significant changes to the infrastructure design. Microsoft IT performed the upgrade side by side by upgrading one RMS server to AD RMS, and installing new Windows Server 2008–based servers while the original RMS servers were being decommissioned. Because the database format differs between RMS and AD RMS, the existing servers would stop working after the first upgrade. Microsoft IT upgraded database server hardware afterward, but it maintained the same SQL Server version during the upgrade.

Although upgrading to Windows Server 2008 did not impose additional demand in the infrastructure and the original servers could have supported the existing load with the new version of the platform, Microsoft IT implemented AD RMS on top of new server hardware as part of its hardware refresh process.

The biggest difference in the server implementation process with Windows Server 2008 was that the AD RMS services ship as an integral part of the new operating system, and AD RMS is available as a server role with the installation of Windows Server 2008 Standard, Windows Server 2008 Enterprise, and Windows Server 2008 Datacenter editions. Obtaining a functional AD RMS server required only adding the role to the servers through the wizard and configuring the database.

Additionally, AD RMS in Windows Server 2008 does not require contacting a Microsoft Enrollment Service to become active, and an AD RMS server is automatically enrolled when the role is installed without contacting any external service. This simplifies the installation process significantly because the AD RMS root cluster computers do not necessarily have Internet access.

As with the server infrastructure, upgrading to Windows Server 2008 AD RMS did not require any changes in the client infrastructure. Existing clients continued to operate on the migrated servers without change, and the upgrade did not have any visible impact on the users. Because the workstation environment was being upgraded to Windows Vista during the same period of the upgrade to AD RMS, users who had already been migrated to the new client operating system gained some functionality with the infrastructure upgrade, especially in the area of Rights Template distribution. But for the most part, the change was transparent to users.

The only significant impacts to other elements of the IT environment were related to new functionality available in Exchange Server 2007 and Microsoft Office SharePoint Server 2007, which were also being deployed during that period.

Exchange Prelicensing Deployment

No changes were necessary in the Microsoft Exchange infrastructure to enable basic RMS functionality. However, upgrading the Hub Transport Exchange servers to Microsoft Exchange Server 2007 with SP1 and installing the AD RMS client on those servers when the infrastructure was upgraded to AD RMS permitted enabling Exchange Prelicensing. This functionality enabled customers to automatically download licenses with protected content when using Office Outlook 2007 or Office Outlook Mobile in Windows Mobile 6.0 or Windows Mobile 6.1. This functionality implies that the users do not have to acquire licenses or enter credentials at the moment of opening protected content they received through e-mail. Although this change was visible to the users in the form of enhanced functionality, it required no user training and was implemented independently of the upgrade of the RMS servers to Windows Server 2008 AD RMS. Because this functionality is enabled on a per-user basis (with the user's approval of the new functionality the first time it is available or via a registry setting changed during Microsoft Office deployment) Microsoft IT gradually enabled the functionality to properly test it before full-scale deployment and reduce the support burden.

Integration with Office SharePoint Server

One of the most important new capabilities in AD RMS is the integration with Office SharePoint Server 2007. SharePoint technologies have always been able to store RMS-protected documents, because the protection capabilities are embedded in the document and not in the storage media. However, using IRM-protected documents with SharePoint technologies used to imply a loss of functionality in the SharePoint server, because the contents of the protected documents were encrypted and obscure to the service, and the documents could not be tagged or indexed. With AD RMS in Windows Server 2008 and Office SharePoint Server 2007, this is no longer the case. The products include explicit support for this combination through the inclusion of the Office Protector component in Office SharePoint Server 2007 that allows for the automatic application of IRM policies to documents stored in libraries.

With Office SharePoint Server, IRM is available for files that are located in document libraries and stored as attachments to list items. Site administrators can elect to help protect downloads from a document library with IRM. When a user attempts to download a file from the library, Office SharePoint Server verifies that the user has permissions to the file, and it issues an IRM license to the user that enables access to the file at the appropriate permissions level. Office SharePoint Server then downloads the file to the user's computer in an encrypted, rights-managed file format.

IRM is enabled at the SharePoint document-library level by an administrator, and protection includes the following options:

• Whether users can print documents that are rights managed.
• Whether the user can run Microsoft Visual Basic for Applications (VBA) and other custom code in the file.
• The number of days for which the license is valid. After the specified number of days has passed, the license expires, and the user must download the file again from the document library.
• Whether to allow users to upload file types that do not support IRM.
• Optionally, the date to stop restricting permissions to the document library. After the specified date passes, Office SharePoint Server removes all rights-management restrictions from the documents in the library.

Office SharePoint Server determines the user rights to assign based on the ACL entry of a user. If a user has access to the library, documents are delivered to the user with rights management applied. It allows access to the user according on the options set for the library and the according to the access level the user has to the library.

Figure 3 illustrates a typical document flow in Office SharePoint Server with AD RMS protection.

Figure 3. SharePoint protected document flow

The steps of the document flow are as follows:

1. A content author posts a Microsoft Office document to a SharePoint document library that has AD RMS protection enabled.
2. The document is stored in the SharePoint database unencrypted and unprotected. If the document as uploaded by the user was originally downloaded from the same library and is thus protected with IRM, existing protection is stripped before storage.
3. A different user with read access to the documents in the library requests the document to the SharePoint server.
4. The server retrieves the document from the database.
5. The server uses the user's Rights Account Certificate and Client Licensor Certificate to assign rights to the user to the document requested, depending on the user's rights on the documents in the library, with additional restrictions according to the policies established in the library. The server applies the rights to the document.
6. The user receives the protected document. The requesting Microsoft Office application opens the document with the help of the AD RMS Client with the rights defined by the policy.

The whole process is transparent to both users and does not require special operations from them. The platform provides assurance that the documents will always be protected according to the policies defined for the library.

File Storage in Office SharePoint Server

Because companies often have restrictions that require their files to be stored in unencrypted formats, Office SharePoint Server does not store files in encrypted, rights-managed file formats. However, Office SharePoint Server calls an IRM protector to convert stored Microsoft Office documents to an encrypted format each time a user downloads the file. The model is extensible, and protectors for other document types can be installed to automate the protection of different file formats. Similarly, when a user uploads a copy of a file that had been rights protected by the same library before, Office SharePoint Server calls the appropriate IRM protector to convert that copy to an unencrypted format before it is stored.

As a result, it is not necessary to create custom solutions to enable searching or archiving of document libraries where IRM is enabled. Storing the files in unencrypted format ensures that the current Search indexing service can crawl content stored on the servers.

Microsoft uses extensively the search capabilities of Office SharePoint Server, and combining this discoverability with the ability for the platform to keep the documents protected after delivery to the users is an excellent solution to deliver flexible access to information without compromising confidentiality or privacy. With Office SharePoint Server, search results are scoped to user permissions, so users never see search results that include content to which they do not have some level of access.

Deployment of the integration between AD RMS and Office SharePoint Server was straightforward. The owners of each SharePoint Site implemented the deployment on top of Office SharePoint Server 2007. Implementation involved enabling AD RMS in each library to be protected and setting the AD RMS cluster properties for the SharePoint server. Administrators of the SharePoint sites can make these changes as they see the need for additional document protection.

Client Deployment Pilots

Deploying Microsoft Office 2003 to clients—which was the minimum requirement to support RMS in Windows Server 2003—though still relatively straightforward, required more effort. It is standard operating procedure for Microsoft IT to make some configuration changes to client installation packages prior to making them available to clients. Specifically for IRM, Microsoft IT chose to chain the installations of both the RMS client and RMA to the Office Professional Edition 2003 installations to provide a seamless experience for its users. Later, when Windows Vista was deployed together with Microsoft Office 2007 inside Microsoft, the RMS and RMA client did not need to be chained to the installation because these components are part of the operating system.

After the RMS server infrastructure was in place, Microsoft IT prepared for its initial IRM pilot deployments during the company-wide deployment of a beta version of Office Professional Edition 2003.

Microsoft IT typically performs client deployments in staged rollouts to provide the best chance for success. Microsoft IT controlled access to the RMS pilots by disabling IRM in the beta versions of Office Professional Edition 2003 by default. Microsoft IT began with a small deployment to 50 selected clients for a one-week pilot. A week later, Microsoft IT expanded the pilot to members of the messaging team in Microsoft IT, the Rights Management Services product group, the Exchange product group, and the Microsoft Office product group.

Approximately 5,000 Office Professional Edition 2003 beta users participated in the second pilot for a two-week period. Microsoft IT provided each of these eligible pilot participants with a special RMS client installation script that enabled IRM functionality in their beta Office Professional Edition 2003 installation. However, usage of the service during the second pilot was quite light (likely because both the publisher and the consumer needed to have IRM capabilities, and not many users were fully aware of how to use IRM), so despite the large number of eligible participants, the pilot was small enough to be easily managed.

During the pilot, Microsoft IT ran many varied usage scenarios to test the functionality of the features and determine the load they placed on the infrastructure. As of the Office Professional Edition 2003 beta refresh release several months later, Microsoft IT enabled IRM functionality for all user installations company wide.

Because there is complete backward and forward compatibility between RMS/AD RMS and IRM in Microsoft Office 2003 and Microsoft Office 2007, Microsoft IT did not require any special process to coordinate the deployment of Windows Vista and Microsoft Office 2007 inside Microsoft, other than including IRM functionality in the deployment pilots. When Windows Vista and Microsoft Office 2007 began their early deployment in 2006, RMS in Windows Server 2003 supported their IRM capabilities. When Microsoft IT migrated the RMS server infrastructure to AD RMS in Windows Server 2008, the change was transparent to both Microsoft Office 2003 and Microsoft Office 2007 users.

Microsoft IT enabled IRM on Windows Mobile phones and portable devices by deploying Windows Mobile 6–based phones. Because the IRM client is part of the Windows Mobile client, no special deployment process was necessary and users could immediately consume protected documents and e-mail on their devices.

Computer Activation and User Certification

Before an AD RMS client can be used on a client computer, a series of activation and certification processes must be completed. The computer activation and user certification process starts automatically when the RMS client is deployed through GPO or SMS, or when the AD RMS client is first used on a client computer if not activated during installation. Three new certificates are installed on each client computer that uses the AD RMS client.

In the original RMS client used during the initial deployment of RMS at Microsoft, the client activation process was a complex one that required several interactions with the RMS server and with public Microsoft services. After the Service Pack 1 version of the RMS client, this process was greatly simplified.

The AD RMS client begins the activation process by activating the client computer itself. To activate the client computer, the AD RMS client initializes a highly secure dynamic-link library (DLL file) known as the lockbox. The lockbox, a repository loaded into the client computer's memory, is where all of the encryption and decryption of rights-protected content occurs.

The activation process for the client in Windows Vista includes the following steps:

1. Computer activation:
   1. The AD RMS client generates locally a 1,024-bit RSA private/public key pair.
   2. The private key is stored securely on the local computer through Data Protection API (DPAPI) and RSAVault.
   3. The public key generated is stored in a security processor certificate (SPC) together with values derived from the hardware ID to help ensure that the certificate is valid and usable only by the AD RMS client on the computer that generated it.
   4. The client signs the SPC.

   Note: During the complete Machine Activation process the client does not contact the AD RMS Server infrastructure, so the process is performed completely offline.

2. Account certification:
   1. The client computer polls AD DS for the location of the AD RMS Certification servers in that forest, which is stored in a ServiceConnectionPoint object. Alternatively, the client computer can employ registry settings.
   2. The client computer obtains the URL for the certification service on the AD RMS servers from AD DS.
   3. The certification process on the client computer presents the active Windows logon credentials to the AD RMS Certification server to receive an RAC.
   4. The RAC, which includes the user's public and private key pair and all valid SMTP e-mail addresses associated with that user account, is built from information contained in AD DS and installed on the client computer. Both of these activities use the AD RMS Certification servers located in the same forest as the user account.
   5. The RAC private key is encrypted with the public key of the SPC, and the RAC is then sent to the client and stored along with the SPC.

      With all subsequent publishing requests and all licensing requests, the RAC is sent along with the request. The RAC is used to identify the user to the AD RMS server, thereby enabling the AD RMS server to grant the request.

      A final step, obtaining the Client Licensor Certificate, enables an author to publish content with rights protection without needing an active connection to the AD RMS server. The CLC, unique to each user's Rights Account Certificate, contains the public key of the AD RMS server. The same CLC is used to publish all content originating from the activated user on the activated computer. The CLC is, by default, obtained from the AD RMS Certification server. If the organization deploys sub-enrolled AD RMS Licensing servers, the CLC can be obtained from them through registry overrides.

3. Acquiring a Client Licensor Certificate:
   1. The AD RMS client contacts the AD RMS server for client enrollment, and sends the Rights Account Certificate for the currently logged-on user.
   2. The AD RMS server validates the RAC.
   3. The AD RMS server generates a 1,024-bit RSA key pair for the CLC.
   4. The CLC private key is encrypted with an RAC public key so that it can be decrypted only by the user who sent the request from the computer that sent it.
   5. The Client Licensor Certificate is generated, assigning the user the right to publish protected documents.
   6. Server information, such as the URL for the AD RMS Certification service and server public key, is also added to the CLC.
   7. The server signs the CLC.
   8. The CLC is returned to the client with the corresponding encrypted private key.
   9. The client decrypts the private key and stores it securely by using DPAPI and RSAVault.
   10. The client is now ready for both publishing and consumption of protected content.

   Note: Microsoft Office uses the CLC because the product supports only offline publishing. Applications that perform online publishing do not use a CLC.

When Microsoft IT originally deployed the RMS client to Windows XP–based clients, the complete activation process was integrated to the installation of Microsoft Office so that the users would not have to do anything to be able to create or consume protected content. Similar scripts can be deployed with the AD RMS client or in a stand-alone form in environments that have the AD RMS client and the desired version of Microsoft Office already deployed (such as clients using Windows Vista and Microsoft Office 2007).

Service and Support

The additional support requirements for Microsoft IT for implementing RMS and IRM at Microsoft were minimal. The reasons for the minimal support requirements were as follows:

• The Microsoft IT end-user support teams absorbed RMS end-user support duties. No additional support personnel were needed.
• The Exchange Server Support (ESS) team in Microsoft IT absorbed RMS server administration duties. No additional administrator personnel were needed.
• The RMS SQL Server databases were backed up through existing SQL Server support infrastructure. No additional infrastructure was needed.
• The RMS server infrastructure used Microsoft Operations Manager and later Microsoft System Center Operations Manager for server monitoring by using Microsoft IT's existing Microsoft Operations Manager monitoring infrastructure. No changes were needed there, other than the installation of an RMS-specific Operations Manager management pack (which is bundled with the RMS download). The RMS development team created the new management pack specifically for monitoring the status of RMS servers and activity on those servers.

In terms of people resources, Microsoft IT wanted to confirm its assumptions on how the RMS and IRM deployment would affect call volume to its internal Helpdesk (Tier 1 in the support system at Microsoft), as well as service requests escalated to Tier 2 end-user and server support teams. The number of support calls specifically related to RMS and IRM on turned out, as expected, to be quite small. In the last four months of 2003, Microsoft IT received an average of 50 calls per month related to RMS and IRM. Helpdesk handled and closed approximately 80 percent of those calls. The number of calls related to RMS and IRM is insignificant, considering that Helpdesk receives an average of approximately 11,000 calls per week. Approximately two-thirds of the calls that Microsoft IT received were resolved as either issues related to user training or issues not specifically related to RMS.

Because Microsoft IT estimated that the majority of IRM usage would come from Office Outlook, it assigned administration of RMS servers at Microsoft to the ESS team, a 24-hour, seven-days-a-week support organization consisting of three shift leads and 15 front-line operations analysts. ESS monitors the entire Microsoft worldwide Exchange infrastructure in addition to all issues associated with Unified Messaging, fax services, and Terminal Services. ESS uses System Center Operations Manager for event monitoring and alerting of the RMS servers. System Center Operations Manager is the standard tool for monitoring all applications and tools for which ESS is responsible. Alerts raised through System Center Operations Manager immediately notify this group of potential issues and automatically generate service requests in the event tracking system. The total impact of RMS on the ESS team was an additional two alerts per day for Tier 2 server support, and only 5 percent of those alerts related to a server issue that the team needed to address. One support manager takes an estimated two hours per week to provide ongoing management of the RMS infrastructure.

One important feature of RMS and AD RMS is the support for Super Users. Super Users are users who belong to a group that can access all the rights-protected documents regardless of their policy. Super Users can be used to recover information when employees leave behind important protected documents, or when legal document discovery requirements mandate the recovery of information that users might have protected.

Super User functionality was an important consideration for Microsoft. However, membership of the Super Users group was defined after extensive analysis and is carefully safeguarded in order to guarantee that this capability is used only under the appropriate circumstances and with the proper authorization by the corresponding parties.

Training

To educate the Helpdesk and other support staff for the deployment of RMS and IRM, Microsoft IT used deployment guides and product help available from the Microsoft Office and RMS product groups. These materials consisted mainly of the publicly available Microsoft Office and RMS deployment guides. Microsoft IT presented these materials to the Helpdesk staff in the United States and Dublin in a single, one-hour-long session for each shift. Additionally, Microsoft IT subject matter experts wrote several knowledge base articles for use by the Helpdesk and the Tier 2 end-user support teams. Microsoft IT did not conduct any further support-team training specific to RMS and IRM, in part to validate the ease with which RMS and IRM can be deployed in an enterprise.

Microsoft IT also produced and published user training—in the form of an informational e-mail message and online content—prior to the deployment of RMS. As with the training materials used for the support teams, Microsoft IT produced this content primarily from materials that the Microsoft Office and RMS product groups made available.

Employing Super Users for Document Recovery

Document recovery is a key area of support in the Microsoft IT environment. AD RMS enables Microsoft IT to have a person or team of people assigned membership in an AD RMS Super User distribution group for efficient document recovery. If AD RMS rights are applied to a key document and the publisher subsequently becomes incapacitated or leaves the company before the policies can be removed, the Super User group can enable the editing or complete removal of the policies that the original publisher set. Microsoft IT has limited membership in the Super User group to a small number of highly trusted individuals. In addition, only in specifically defined business cases can a member of the Super User group intervene to annul the policies of a rights-protected document.

Having a means to remove publisher-assigned policies is sound corporate policy. Like most businesses and organizations, Microsoft considers all intellectual material that employees create at work by using its corporate network and computing resources to be Microsoft property. Microsoft needs to retain the ability to recover its property if, for example, a malicious user intentionally protects a document with IRM policies. Additionally, the ability to recover rights-protected documents is necessary for legal reasons in cases of discoverability in a court of law.

A member of a Super User distribution group on an AD RMS server is automatically assigned full control rights to any rights-protected content published by that server. To ensure that this trust is not abused, Microsoft IT has specific business processes in place for when Super User permissions are used to open any rights-protected e-mail messages and documents.

Microsoft IT assigned the ESS team administrator rights on all RMS servers. The corporate security team within Microsoft IT is responsible for the Super User distribution group and manages the membership of that group. Both groups are notified anytime someone with rights assigned by membership in the Super User group attempts to open rights-protected content.

AD RMS first generates an event code in the AD RMS server's event log anytime a license has been granted to a Super User member. The Operations Manager RMS management pack captures this event and generates an alert message on the Operations Manager console for the ESS team administrators who monitor AD RMS server activity. System Center Operations Manager also automatically sends e-mail messages to the corporate security team and key members of the ESS team. This Super User accountability feature is built into AD RMS.

Lessons Learned and Best Practices

By thoroughly evaluating and deploying an RMS server infrastructure and using the IRM client technology in Office Enterprise 2007, Microsoft IT learned several valuable lessons that can be applied as best practices in most other AD RMS/IRM deployment plans. Microsoft IT learned some of these lessons and best practices during deployment, and some as outcomes of the deployment. They can be divided into three general categories: deployment, security, and administration.

Deployment

Microsoft IT derived the following lessons and best practices from its experience in deploying AD RMS and IRM.

Educate Users

To take full advantage of the technology, users must be told that the service exists and taught how to properly use it. An organization can educate users by creating self-help training content and knowledge base articles, developing a dedicated intranet Web site for posting training materials and frequently asked questions (FAQ), and regularly advertising and discussing the service addition with employees during the deployment. Success in informing the user base on where to find the information needed to properly use the service will minimize the effect on the organization's help desk.

Run a Pilot

An organization should introduce AD RMS to the enterprise in a pilot deployment project with a limited set of users in a small, controlled area. During the pilot, the organization should test all of the desired enterprise-usage scenarios, including any planned templates.

After successful completion of the first pilot, if the organization expects the size of the eventual rollout to include a very large number of users, it should conduct a second pilot to a larger (but still closely monitored) group of users. After identifying and considering scaling issues, the organization should begin the rollout to the rest of the organization, as resources and time permit. Employees running versions of Microsoft Office older than Office Professional Edition 2003 or editions of Microsoft Office that do not support IRM directly can use RMA as needed to read rights-protected e-mail and documents prior to their own upgrade to IRM-enabled versions of Microsoft Office. This capability must be specifically enabled in the Rights Management policies applied to the documents, so the organization should set it up in the policy templates at least during the deployment period.

At Microsoft, Microsoft IT sent rights-protected e-mail to successively larger groups of consumers simultaneously, to stress test the RMS licensing infrastructure. Microsoft IT considered the deployment of RMS and IRM officially complete when it successfully sent a rights-protected e-mail message to the company All Staff distribution group, and all valid consumers were able to read it.

Consider Network Bandwidth

An organization should carefully consider network bandwidth constraints before adding new services to the existing core IT services. It is likely that the network was designed with different assumptions, necessitating the careful management of the risk of business disruption. Microsoft IT's experience in deploying RMS technology with a new server infrastructure and license distribution demonstrated that the Microsoft corporate network bandwidth was not significantly affected.

Deploy All RMS Servers with a Failover Option

All servers supporting AD RMS in a forest should be deployed with at least two servers to support server failover in case of catastrophic hardware failure. This advice also includes the AD RMS transaction logging servers, which are used with every AD RMS transaction.

Choose the Best Client Deployment Model

Enterprises need to determine whether they want to deploy AD RMS clients by using a software deployment tool such as System Center Configuration Manager 2007, by using GPO, or by chaining the AD RMS client to another deployment. This is what Microsoft IT did with the Office Professional Edition 2003 deployment. Or you can deploy it when deploying Windows Vista clients that already include the AD RMS client. Microsoft IT knew that only about 75 percent of the computers in the enterprise were connected to the System Center Configuration Manager platform (the rest consisted of test computers, secondary portable computers, and computer labs used within the company), so deploying the AD RMS client as an independent package would not cover the remaining computers. Microsoft IT does not use GPO to deploy software bits to clients; the use of GPO is reserved for distributing policies. Instead, Microsoft IT uses System Center Configuration Manager 2007 for automating software distribution.

All Microsoft staff use Office Enterprise 2007 as their business productivity application suite. As such, Microsoft IT added the provision to install and activate the RMS client to the installation script of Office Professional Edition 2003 from the Microsoft IT software distribution servers. As the staff later upgraded to Microsoft Office 2007 running on Windows Vista, this provision became unnecessary.

Use Configuration GPO to Enforce Corporate Settings

Within Microsoft, users of Microsoft Office might install it from distribution servers not managed by Microsoft IT (such as those used internally by the Microsoft Office development team), bypassing the custom Microsoft IT installation scripts that routed all IRM document licensing requests to the main corporate forest. As a result, Microsoft IT was forced to use a GPO to deploy a change in the client registry. This change revised a registry key setting on client computers that were outside the Microsoft IT standard to override the default AD RMS service discovery setting, which pointed to AD DS in the user's logon forest, which in turn (by default) referred the user to the AD RMS servers located in that same forest.

Address User Rights

Windows XP requires the logged-on user account to have administrator rights to install software. If an organization mandates that its employee users cannot have administrator rights, it can use a software deployment tool such as System Center Configuration Manager 2007 to install application and certificate files in a different user context than the logged-on user. System Center Configuration Manager can then effectively mimic an administrator logon and complete the installation. Because Windows Vista includes an AD RMS client, this operation is not necessary unless a newer version of the AD RMS client must be deployed.

Automatically Retrieve Use License for Outlook

Microsoft IT uses Office Outlook 2007 in cached mode, which means Office Outlook 2007 does not need to maintain a constant connection with the Exchange Server 2007 server to send and retrieve e-mail. Exchange Server 2007 includes a component called the prelicensing agent, which allows for the distribution of access licenses together with protected content delivered to Office Outlook or Office Outlook Mobile clients. Microsoft IT modified its Office Enterprise 2007 installation script to update the registry key that controls whether client computers automatically retrieve use licenses for Office Outlook e-mail messages.

Enabling these setting prevents the appearance of a dialog box—which asks the user if he or she wants Office Outlook to automatically retrieve the use license for all rights-protected e-mail messages received—at the first time a rights-protected e-mail message or document attachment is sent to that e-mail client. Microsoft IT preset the automatic use-license download, which is a best practice that the Microsoft Office 2007 product group recommends.

Consolidate Licensing Across Forests

With Active Directory infrastructures encompassing multiple forests, an organization should use an AD RMS Certification load-balanced cluster in one forest to serve publishing and licensing requests for the entire enterprise. This action simplifies administration tasks and minimizes troubleshooting work when all publication licenses come from the same source. The organization should deploy registry keys to users from other forests to point them to this cluster. It should use AD RMS clusters on the other forests only for expansion of distribution lists and account activation.

Security

Microsoft derived the following security lessons and best practices from its experience in implementing and managing AD RMS and IRM.

Use LDAP Signing to Help Secure Network Communications

Communications between AD RMS and the global catalog should be digitally signed. Signing Lightweight Directory Access Protocol (LDAP) traffic helps guarantee that the packaged data comes from a known source and that it has not been tampered with. Windows Server 2003 and Windows Server 2008 enable LDAP signing and encrypting by default. Organizations should use Windows Server 2008 for their Active Directory servers to implement this best practice.

Do Not Use SQL Server Authentication Mode

For the highest level of security, an organization should not configure the SQL Server database servers on the AD RMS infrastructure to support SQL Server authentication. In SQL Server authentication mode, credentials are passed in plaintext in the connection string, so SQL Server should be configured to support only Windows authentication.

Enforce Access Restrictions

An organization should ensure that only those personnel who need to administer AD RMS have:

• Membership in the Administrators or AD RMS Service Group local groups on the AD RMS server.
• The Log on Locally permission on the AD RMS servers.
• Terminal Services user access on the Remote Desktop Protocol (RDP) connection configuration on the AD RMS servers.

In addition, the organization should ensure that the discretionary access control lists (DACLs) that are configured for the servers restrict access to only essential personnel.

To support group expansion across forests, AD RMS automatically assigns read access to directory services to all authenticated users who have domain credentials. To increase security, the organization should remove this access from the DACL and replace it with each service account that is in the different forests.

Help Secure SQL Server Databases

Allowing unprotected database communications is a high security risk. To help prevent malicious users from capturing or modifying logged data, an organization should help secure SQL Server databases by configuring either SSL or Internet Protocol security (IPsec) to provide encrypted channels.

Do Not Deploy Any Additional Services on AD RMS Servers

After provisioning AD RMS on a server, an organization should not use this server to run any Web sites or additional services. If services other than the AD RMS services run on AD RMS servers, conflicts that can result in security issues may occur. Isolating AD RMS on its own dedicated servers helped Microsoft IT predict and manage workload. Isolation also prevented the introduction of software incompatibilities that may have compromised the integrity or functionality of the AD RMS service.

Create a Dedicated User Account to Use as the AD RMS Service Account

For security reasons, an organization should create a special user account for use as the AD RMS service account. The organization should not use this account for any other purpose and should not give the account any additional permissions. It should add the AD RMS Service Group to the IIS_WPG group on the domain controller. Membership in the IIS_WPG group is required for running the AD RMS application pool (_DRMSAppPool1).

Use an HSM to Help Protect Private Keys

Instead of using software encryption, an organization should use a Hardware Security Module to help protect AD RMS private keys. Using an HSM improves the security of private keys by keeping private keys in tamper-resistant hardware and never exposing them to software-based attacks.

Use Groups to Manage Access to AD RMS Administration

An organization should add members to the AD RMS Enterprise Administrators, AD RMS Auditors, or AD RMS Template Administrators groups, identifying those domain users or domain Global groups that are responsible for administering AD RMS, instead of adding them to the local Administrators group in the AD RMS server.

For even higher security, the organization should remove the domain users from the local Users group on the AD RMS servers, and then add the users and groups who are members of the AD RMS Service group to the local Guests group.

Administration

Microsoft IT derived the following lessons and best practices from its experience in managing and administering AD RMS and IRM.

Centralize Servers in a Single Location

It is a best practice to centralize AD RMS server deployment as much as possible (within the known constraints of link reliability and network bandwidth). Centralizing the AD RMS servers simplified server administration duties for Microsoft IT.

Prepare for AD RMS Server Monitoring Issues

The Active Directory Rights Management Services Management Pack is a System Center Operations Manager management pack that manages the logical parts of AD RMS that an operator or administrator is interested in monitoring, configuring, or reporting on. The management pack includes monitoring capabilities on AD RMS Deployment, AD RMS Web Services, and AD RMS Logging Service.

In the information reported by the management pack, color indicates health states:

• Green: Normal operation.
• Yellow: Degraded operation.
• Red: Failure.

Each health state is related to an operation or the type of functionality that a managed entity is designed to perform. Detection rules detect health states.

Although the Active Directory Rights Management Services Management Pack can detect transitions to specific health states, not all rules in the management pack have been designed to take advantage of the State feature of Microsoft Operations Manager. In these cases, transitions to specific health states are exposed only through the generation of alerts, and the relevant health state change is not reflected on the AD RMS Role and related State Views.

For more information about the Active Directory Rights Management Services Management Pack, refer to the Monitoring Scenarios page in the Windows Server 2008 Technical Library at http://technet.microsoft.com/en-us/library/cc468596.aspx.

For more information about the errors and events that AD RMS records, refer to the Events and Errors page for AD RMS in the Windows Server 2008 Technical Library at http://technet.microsoft.com/en-us/library/cc771924.aspx.

Monitor the Size of the Logging Message Queue

An organization should use System Monitor to regularly monitor the size of the outbound logging message queue. If the queue size grows substantially, the organization should verify that the logging listener service is operating correctly. If a malicious user causes the logging listener service to stop, the outbound logging message queue will grow and eventually exceed the disk space of the AD RMS server. If this occurs, the server will deny requests.

Manage Growth in the Logging Database

Every AD RMS licensing request that the Microsoft IT AD RMS servers receive is logged in the AD RMS SQL Server database. The usage of RMS and IRM within Microsoft during the pilot and initial full deployment stages was generating growth in the logging database of about 1 GB per week, with a projection of 1 GB per day after actual usage estimates were realized. To reduce the volume of data to be logged, Microsoft IT later changed the logging configuration so that only critical events and necessary performance data were recorded by default. Microsoft IT enables higher logging settings only when necessary for research or troubleshooting purposes.

To aggregate logging data from the different AD RMS clusters, Microsoft IT developed a series of scripts and created a secondary, separate database to serve as a logging database archive. The scripts pull out from each cluster the data that is most relevant for usage reporting and store it in a single centralized database. Microsoft IT also implemented a script that keeps only the past 30 days of raw data on a rolling basis within the live AD RMS logging database. Any older data is archived to the Microsoft IT–developed database.

The "request duration" record for each AD RMS transaction is one of the best performance indicators, because it gives an overall indication of the load and efficiency of the servers and of the user experience. AD RMS also provides Windows performance counters that record the average number of transactions processed during the past second, and the number of long-running transactions. Microsoft IT collects the performance counters only during research or troubleshooting activities, with no permanent storage for historical counters.

Microsoft IT uses SQL Server Reporting Services to automatically produce—daily and on demand—reports of AD RMS usage, status, and performance. Among the most useful reports are request volume by type, frequency and distribution of licensing errors by type, and average request duration by hour. Microsoft IT uses these reports daily to assess the health and performance of the AD RMS infrastructure and to plan proactive maintenance and expansion.

Develop Policy Templates

AD RMS templates, such as those that Microsoft IT created for use with Office Enterprise 2007, enable enterprises to define what types of official, global AD RMS policies they want their staff to use as publishers of confidential content. Templates can be made to help protect company-confidential content, attorney/client privileged content, business partner content, and more. The IT group of any large enterprise organization should involve the corporate legal and security teams in brainstorming what is needed to enforce corporate communication policies.

Perform Frequent Backups of the Configuration Databases

The configuration databases store information that is vital to the functioning of AD RMS. In addition, the load-balanced AD RMS cluster configuration database stores the key pairs for the entire installation. If an organization performs regular backups, it can quickly restore AD RMS if a database server fails.

Any enterprise deploying AD RMS should have, at a minimum, a log-shipped secondary (warm standby backup) server available in case the shared disk drive storage in the load-balanced AD RMS cluster has a catastrophic failure. A warm standby server will enable the IT team to recover AD RMS service with a minimum of delay. Microsoft IT backs up its logs every three minutes, so in a worst-case scenario, the databases can be restored to within three minutes of failure, minimizing the effect of a service outage.

Conclusion

Microsoft benefited from the deployment of the AD RMS server infrastructure and its counterpart IRM within Office Enterprise 2007 in several ways. The protective content user rights available through IRM offer a highly detailed level of control over how information is used and shared. Unique user rights for Microsoft Office documents can be assigned to separate individuals and distribution groups. IRM helps protect the confidential contents of business e-mail and documents from unintended consumers through the use of 128-bit encryption, can limit the time that protected content can be opened, and enables authors to define how their content can be used or shared. AD RMS enables an organization to create rights policy templates that provide a uniform way to help protect sensitive information.

At the same time, as evidenced by the ever-growing IRM usage numbers in Microsoft IT, AD RMS and IRM have filled an important data protection gap for Microsoft staff. Many groups within Microsoft IT, in addition to the legal and human resources departments at Microsoft, have begun adopting AD RMS and IRM in lieu of other, older alternatives, such as S/MIME. This adoption is due in large part to the easy setup and usability features in Office Enterprise 2007, as well as the configuration work that Microsoft IT completed to make the installation of IRM seamless to Microsoft users. The support data that Microsoft IT gathered further reflects the ease of use of these products and the relatively small administrative burden that AD RMS has introduced on the Microsoft corporate network infrastructure.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2009 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, BitLocker, Excel, InfoPath, Internet Explorer, Outlook, PowerPoint, SharePoint, SQL Server, Windows, Windows Live, Windows Mobile, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.