AD RMS: Features and Operational Considerations
As I mentioned before, Server 2008 R2 is still in “Release Candidate” status so the details in these articles might change before the product is officially released to manufacturing (RTM), so please keep this in mind.
Now before we get started, let’s do a quick review of what we already covered:
In AD RMS – Data Access Controls we briefly reviewed file access controls to data and resources by leveraging permissions via NTFS and share restrictions. In this article we will take a look at some of the other ways outside of AD RMS that administrators can limit intentional and unintentional data leakage.
In AD RMS – Encryption: EFS and BitLocker we reviewed the Encrypting File System and BitLocker functionality. While not directly related to Active Directory Rights Management Services they are a part of any good security and control strategy.
In today’s segment on Features and Operational Considerations we will review some of the higher level features and operational considerations of the technology in order to get a good understanding of what it offers in terms of content permission and control. I’ll cover:
- Why use AD RMS?
- What AD RMS can do
- How Rights Management works (in a nutshell)
- Shares and Licenses
When administrators leverage Active Directory Rights Management Services (AD RMS) as part of their security strategy, they add an additional layer above and beyond standard file based security, EFS, or disk encryption technologies such as BitLocker.
This is accomplished by allowing for the protection of information through persistent usage policies and rights management. The best part of this use and rights security is that it is not limited to where the data is stored but rather it is part of the data itself, which means that no matter where the data resides it effectively carries the permissions and restrictions with it.
AD RMS allows administrators to set up the services that will allow data owners to configure permissions to sensitive information as part of their security efforts to keep it from intentionally or accidentally being sent to or received by people that should not have access to it in the first place.
As an example, if I have general file access rights (read) to a Word document and I have it in my possession there is nothing preventing me from forwarding that out to the world in an email.
AD RMS resolves that issue.
As another example, if I have general file access rights (read) to a Word document and I am fired from my company I will always have access to that Word document saved on my own storage device.
AD RMS resolves this problem as well.
The AD RMS environment that administrators will deploy includes a system running Server 2008 R2, the latest version released. This system would be running with the AD RMS server role enabled in order to handle all of the necessary certificates for the data. You would also need it to host database services and the AD RMS client.
The AD RMS client is included as part of Windows 7 and Windows Vista and is leveraged as part of the solution to process the permissions on the data.
Data owners are able to define who can open, modify, print, forward, or take other actions with the data. Policy templates can also be created and can be applied directly to the information so that the users do not have to define permissions or rights individually.
As an example a template could be set up as “INTFTE” which allows for “all rights denied except READ” and that could be applied to Word Documents and Spreadsheet and the like, where only those people that are full time, internal employees would even be granted access to the data and then only at a READ level. At that setting they would be unable to print out the data, copy and paste it out and the ability to create screen shots or clippings would be disabled when that document was open.
If you want to be able to leverage rights management to data created on a given application it must be rights management aware or be able to leverage add-ons that have been created to make an application AD RMS-enabled, even if it does not natively implement RMS functionality. Text files created with Notepad cannot be rights enabled because the application cannot leverage the functionality natively as an example.
How Rights Management Works (in a nutshell)
The way the Active Directory Rights Management Service works is that it will issue RMS licenses by way of the AD RMS client which is required for creating the permissions and restrictions on the rights-protected content. The client is also needed for access to that data as well.
Data that is protected by AD RMS leverages encryption and an embedded Usage Policy that defines how each user or group will have access to that data. The data owner will decide the rights that those trusted users will have and they will enable that access right through the application itself.
When a data creator / owner decides that they will rights protect a Word 2007 document, that is done right through Word by selecting the “Office Button” (sometimes called “The Pearl”) in the upper left hand corner of the application and choosing the Prepare option (preparing the document for distribution) and then choosing the Restrict Permission option.
[NOTES FROM THE FIELD] – When content is rights protected (often referred to a “published” or “distributed”) through AD RMS, it is encrypted with Advanced Encryption Standard (AES) 128-bit encryption. (Data Encryption Standard (DES) 56-bit encryption is available for backward compatibility).
In our example above in using Word, AES 128-bit encryption would be used as Microsoft Office 2007 always uses AES 128-bit encryption by default.
AD RMS uses public and private keys to encrypt the content encryption symmetric key. The rights policy data in the publishing license and the use license are also encrypted. AD RMS also uses the public keys to digitally sign AD RMS certificates and licenses as well.
Once the permissions are set (such as READ) then specific users or groups are assigned that license or right to that data. The data owner may then put the Word document out on a share (where the share may have access and permissions rights added to it through the share itself and / or where file permissions may be set via NTFS).
When a user with share and file rights access attempts to view the document they must also have this “licensed” right to do so from the owner or they will be denied access to the data from the rights management perspective.
You can see where combining share, file system, EFS, and BitLocker can add to the security of data and how RMS adds an additional layer even above and beyond that.
Shares and Licenses
If a user was accidentally put into a group that has permissions to a shared resource (such as the Payroll folder and network share), they would suddenly have access to data that they should never have been granted access to in the first place.
However, if the actual data was rights protected this user would not have the license right to access the data; despite the fact they are in a share they don’t otherwise belong in they cannot read the data because they have no RMS access to it.
Additionally, in a situation where someone is fired or quits working for a company, their rights to that data can be revoked. Despite the fact that they may still have data saved on a removable drive or flash memory in their possession, they will no longer be able to access it as their rights, remotely managed via the AD RMS service, will now be denied.
An overly simple way to consider AD RMS is — deny all access rights to all users / groups except those with specific granted rights by way of RMS permissions.
For a much more of a detailed look at the actual process please consider a review of Deploying Active Directory Rights Management Services at Microsoft — specifically the Process That IRM Uses to Generate and Retrieve Licenses section of the article.
In my next article AD RMS – System Requirements and other Considerations we’ll go over the recommend system requirements and some of the high level configuration considerations for a standard set up. See you then!