AD RMS — A Quick Insight

Leak.

Drip>Drips>Stream>Flood.

The metaphor derived from aberrant faucet behavior has entered the lexicon as the expression we associate with the dispersion and publication of classified (read secret), sensitive, privileged, highly personal, or work-in-progress documents, files and e-mails that somehow wind up going viral on the web or in the front pages of your preferred newspaper.

A leak as we know it is basically an issue of failed or compromised security within a public or private organization. Leaks may be the result of a hacked network, the efforts of a frustrated or disaffected employee motivated by a personal agenda, or the embarrassing release of data retrieved from a stolen laptop, owned by anyone from a CEO to a Senator and lost in transit between meetings. It’s about access, and ultimately, regardless of the spirit and the moral or political intention, it’s about theft.

The best plug for a leak is preventing it. That’s what the Windows Active Directory Rights Management Services (or AD RMS as they say in IT, the hotel-of-choice world-wide for acronyms) are all about — securing and protecting the privacy of exchanged files and documents.

Here’s how it works.

When they’re ready to publish content, AD RMS clients query and receive new licenses that protect the content according to the rights and conditions that the publisher (author, business, etc.) selects to protect that content.

When a document is authored and rights protection is chosen, the AD RMS client acquires a Client Licensor Certificate (CLC), which enables content protection. The CLC then encrypts the document, creates and signs a Publishing License (PL), and then attaches a copy of the PL to the encrypted content. This protects the document from theft, abuse, or alteration when it’s sent to others inside or outside the business or organization.

When the rights-protected content is received, the recipient will first need to use a rights-enabled app like Microsoft Word to again query and receive an end-user license for the content on their end. In order to obtain the end-user license, the AD RMS client must first determine if the recipient of the content complies with the policies set forth in the publishing license that was used to protect the content.

If the AD RMS client approves, the client essentially ensures that the user honors the conditions indicated in the end-user license, which often comes with certain restrictions. This protects the documents according to the intentions or conditions set by the original authors and publishers, and restricts usage by the recipient to the rights policies that have been assigned.

Should the document arrive as, say, an e-mail to an unintended user, the content cannot be opened, or even viewed. Only authorized users have access. AD RMS is a more sophisticated AD DS manifestation of organizational rights management that’s sort of based on IRM (Information Rights Management) technology, which allows for remote control of documents. The B2B model expressed in AD RMS typically is used to protect financial data, sensitive executive communications, intellectual property, and other files requiring secure passage. AD RMS doesn’t by itself limit the ability to share information, it restricts access to that information.

Here’s a step-by-step description of the AD RMS exchange process, involving a hypothetical story I’m working on in collaboration with my hypothetical co-author, Darren:

1. As I apply my preferred access restrictions, the AD RMS client launches and initiates a service request for me to the AD RMS server.
2. The AD RMS server returns a Client Licensor Certificate to the AD RMS client installed at my desktop, letting me save the document in encrypted form with my desired level of rights-protection.
3. I attach and send the rights-protected Word document to Darren in an email.
4. Darren gets my email, saves the attached document to his local desktop, and opens it. When he does, the AD RMS client working at his desktop contacts the AD RMS server to get an end-user license.
5. The AD RMS client at Darren’s desktop receives the end-user license, which indicates that he’s allowed to view the still-encrypted document. The AD RMS client then decrypts the document and applies the specific restrictions, allowing Darren to access it’s content according to the access permissions that I’ve assigned to it. Cool.

AD RMS can’t prevent all malfeasance, such as content being erased, or captured and transmitted by malware or spyware, corruption related to computer viruses, or theft by screen-shot. But these types of actions and circumstances are outside of the provenance and design of AD RMS, anyway.

AD RMS is a role installed in Server Manager. The screenshots below detail the main steps for setting up AD RMS.

1. Install the AD RMS server role by using the Roles and Features Wizard found on the Manage menu of the Server Manager dashboard.

2. Configure a Windows Firewall exception on the AD RMS server. This tool can be found in the Tools menu on the Server Manager dashboard.

3. Add the AD RMS server to the MMC console, using the Active Directory Rights Management Services Console. The screens below are the main screens you’ll see during the configuration. You’ll follow the steps as they appear in the console pane.

Internet security continues to evolve in scope and sophistication, as does the hacking and piracy it seeks to curtail. The development of AD RMS and the technology on which it is built is a good example of the complexity and challenges of the cat-and-mouse game that IT security has become.

In light of the continuing spate of international corporate e-mail leaks (the Panama Papers), classified U.S. and international government document leaks (Assange, Snowden), and major institutional hacks (credit card and health records), the game isn’t getting any simpler.

However, if the security of the information data flow from the office to the web is ultimately about access, privilege, and encryption, then you know that when the pipes crack, we have better tools to plug the leaks with.