Active Directory Rights Management Services (AD RMS ) : Part 3 ( Available Rights and other technologies )
Types of Rights Available
By using AD RMS–enabled applications, such as Office Word , Office Excel , and Office PowerPoint from Office Enterprise , a document owner can apply rights to a document file through one of three methods:
- Default rights applicable to all consumers (such as 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 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.
Right | Description |
Full control | This right gives the consumer the same abilities given to the publisher. This right acts as if no rights restrictions have been applied. It is typically enabled only for an individual who is a member of a larger group of consumers for whom rights that are more restrictive have been applied. It can also be used to transfer ownership of a document. |
Change | This right enables the consumer to read, edit, and save changes to a protected document (but not print). |
Read | This right enables the consumer to read a protected document but not print, edit, save, or copy (and with Office Outlook 2003 and Office Outlook 2007, also not forward). |
Document expiration | This right expires the consumer’s ability to open a protected document at a date that the publisher set. |
Print content | This right enables the consumer to print protected content. If this right is not assigned, the user cannot print the document, even if he or she can open it and view it on the screen. |
Allow users with read access to copy content | This right enables the consumer to read and copy content of a protected document to the Clipboard but not print, edit, or save the original document.If this right is assigned, the user might be able to copy the content to another document and then print or save it from there, so it should be assigned with care. |
Access content programmatically | This right enables another application to access protected content programmatically. |
Users can request additional permissions | This right enables the consumer to contact the publisher at a specified e-mail address to request an upgrade in the rights assigned. |
Allow users with earlier versions of Office to read with browsers supporting Information Rights Management | This right enables protected content to be read in Internet Explorer through RMA. |
Require a connection to verify a user’s permission | This right sets the use license to expire immediately after the protected content has been accessed. As a result, the consumer must have online access to the AD RMS server to get another use license every time the document is opened. |
By default, not all document types in Office Professional Edition 2003 offer the ability to set all of the rights available in IRM. below table lists the policy restrictions available in the AD RMS–enabled applications within Office Professional Edition 2003 and IRM-enabled editions of Microsoft Office 2007.
Outlook | Word, Excel, PowerPoint, and InfoPath |
Read (cannot forward, print, save, or copy) | Full control Change content but no printing Read (cannot print, save, or copy) Read with copy content permission Print content Document expiration Enable content access programmatically Require new license with every access Provide e-mail address for users to request upgraded rights Enable content access by means of RMA |
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
compares IRM in Microsoft Office with S/MIME digital signing, S/MIME encryption, ACLs, EFS, and BitLocker.
Feature | IRM and AD RMS | S/MIME signing | S/MIME encryption | ACLs | EFS | BitLocker |
Attests to the identity of the publisher | Yes | Yes | No | No | No | No |
Sets fine-grained usage policy on information | Yes | No | No | Yes | No | No |
Prevents unauthorized viewing | Yes | No | Yes | Yes | Yes | Yes |
Encrypts protected content | Yes | No | Yes | No | Yes | Yes |
Offers content expiration | Yes | No | No | No | No | No |
Offers use license expiration | Yes | No | No | No | No | No |
Controls content usage to reading, forwarding, saving, modifying, or printing by consumer | Yes | No | No | No | No | No |
Extends protection beyond initial publication location | Yes | Yes | Yes | No | Yes | No |
Keeps information protected even when outside a user’s direct control | Yes | No | No | No | No | No |
Offers the ability to collaborate with others on protected information | Yes | No | No | Yes | Yes | No |
Helps protect information with a smart card | No | Yes | Yes | No | Yes | No |
Provides untrusted administration of a file share | Yes | Yes | Yes | No | Yes | No |
Helps protect information from other users on a shared computer | Yes | Yes | Yes | No | Yes | No |
Helps protect information on a lost or stolen laptop | Yes | Yes | Yes | No | Yes | Yes |
Provides a physically nonsecure branch office server | Yes | Yes | Yes | No | Yes | Yes |
Is document format agnostic | No | No | No | Yes | Yes | Yes |
Comparing RMS and PKI
| PKI | AD RMS | |
Enrollment | Sometimes difficult, inconvenient for end users | Automatic, transparent |
Lifecycle management | Updating keys could require manual intervention | Automatic, transparent |
Time of protection decisions | What if one of the recipients does not yet have certificates? What if the intended audience changes over time? | Group memberships can change but document rights persist |
Protection after decryption | Once the data is decrypted, there is no control over it | Limit use of content after decryption Do not forward, print, or copy/paste |
NASER
Does security with RMS Includes the message body ( lock the message body )
Ahmed Hussein
Yes ,RMS encrypts the massage body.
Himanshu Kohli
Could you add to this article, some points of difference between NTFS Permissions and ADRMS Permissions on the basis of their scope, implementation etc.
Ahmed Hussein
thanks for the note. i did not mention it because the huge difference in technology and since the NTFS did not bring anything new to the table , but i will try in future post to make it more comprehensive.