Unlocking the black box that is AD RMS Part 1

So you want to understand what’s going on under the hood of Active Directory Rights Management Service (AD RMS)?  You can try searching Microsoft TechNet and MSDN, and what you’ll find is somewhat disappointing. I’m not sure why, but Microsoft hasn’t done a great job of breaking AD RMS down into the nit and grit as they have done with other applications.

My goal over the next few weeks is to fill that gap. Over the past few days, I have been working to break open that black box and I want to share what I’ve learned. I will not be focusing on the basics of AD RMS, as I feel the following posts do a good job of that:

Still curious? Well then, let’s begin. This first post will focus primarily on the tools I used to gather the information I will be presenting.

Packet Capturing Tools

You can’t properly study a tool that has a client-server model without capturing that network traffic.  Normally I stick with Wireshark, but for this process I ended up using Microsoft Network Monitor (Netmon).  The reason for Netmon over Wireshark is Netmon will report the PIDs and process names of the applications creating the traffic. This was a big help in monitoring AD RMS on the servers as we can narrow the traffic we care about down to the IIS worker process. I also find the LDAP query parser in Netmon to be far superior to Wireshark.

Web Proxy Debugging Tool

With AD RMS transactions taking place over HTTP/HTTPS, it only makes sense to utilize a tool such as Fiddler. For those unfamiliar with Fiddler, it is a web proxy debugging tool that makes analyzing web transactions (both HTTP and HTTPS) a breeze. I began using it when I was digging into Federation a year or two back. I find myself using it on a daily basis as more and more apps begin to communicate primarily over HTTP/HTTPS.

I used Fiddler to capture the web transactions between the AD RMS client and the AD RMS server. It parses the packets so nicely, you can easily dig into the XrML of the RAC/CLC/SLC/EULs going back and forth. This was a huge aid in understanding what exactly an AD RMS certificate looks like.

AD RMS Client and Server Side Tracing

Client and server side tracing was an absolute necessity. This is the stuff you’ll want to take a look at if you really want to understand AD RMS. Microsoft has some wonderful articles that describe how to set it up. Keep in mind the client tracing is specific to Office 2010.

Event Logs and Diagnostic Logging

You can’t dig into a Microsoft product without examining event logs! The Directory Services log on the domain controllers are huge here. You’ll need to enable AD diagnostic logging to capture the LDAP queries being run by the AD RMS client and server. This article is a great place to learn more about turning on AD diagnostic logging.

Procmon

Do you hate yourself? If so, procmon is the tool for you! Procmon came in very handy when I needed know what registry keys the AD RMS client and server were hitting when looking for hardcoded settings.

Lab Environment

Last and most importantly, let me describe my lab environment. For this project I setup four servers and two clients. The server/client setup is detailed below. A two-way transitive forest trust was established between contoso.local and fabrikam.local. A two-way AD RMS Trusted User Domain between the separate AD RMS clusters.

SERVER01
OS: Windows Server 2008 R2 Standard
Domain: contoso.local
Roles: Active Directory Domain Services, Active Directory Certificate Services
Applications: Microsoft Network Monitor

SERVER02
OS: Windows Server 2008 R2 Standard
Domain: fabrikam.local
Roles: Active Directory Domain Services, Active Directory Certificate Services
Applications: Microsoft Network Monitor

SERVER03
OS: Windows Server 2008 R2 Standard
Domain: contoso.local
Roles: Active Directory Rights Management Services, Windows Internal Database, SQL Management Studio
Applications: Microsoft Network Monitor, Debugview

SERVER02
OS: Windows Server 2008 R2 Standard
Domain: fabrikam.local
Roles: Active Directory Rights Management Services, Windows Internal Database, SQL Management Studio
Applications: Microsoft Network Monitor, Debugview

CLIENT01
OS: Windows 7 Professional
Domain: contoso.local
Application: Microsoft Office 2010 Professional, Microsoft Network Monitor, Debugview, Fiddler

CLIENT02
OS: Windows 7 Professional
Domain: fabrikam.local
Application: Microsoft Office 2010 Professional, Microsoft Network Monitor, Debugview, Fiddler

When working with AD RMS, it is critical to remember the importance of certificate and certificate revocation checks. In a lab environment, I would suggest you make it easy on yourself and disable CRL checking for your client and server boxes according to this article. This will save you some headaches.

Do yourself a favor and disable AD RMS caching. It will save you significant time when trying to replicate the acquisition of a fresh RAC or EUL. This article describes the process. Also, if you opt to use a WID, check out this article for connecting to the WID using SQL Management Studio.

All right folks, that will do it for this post. Next up will be a breakdown of intraforest consumption of protected content. To prep yourself for the post, I would suggest reviewing the following articles:

My experience with the 70-640

I decided early last year it was time to update my MCSA to the MCITP:SA (which is actually being changed back to MCSA next July). Upon reviewing the material, I saw they were now including R2 information. Since I didn’t feel like relying solely on Technet for R2 material, I figured I would wait another year and give Microsoft time to get a revamped R2 book out there.

Earlier this year we had a budget approved to upgrade our infrastructure to Server 2008. It seemed like the perfect opportunity to purchase the Server 2008 R2 books and crank through the material via labbing and through real life experience.

Over the next four months, I put my mind into exam mode. I’ve developed a pretty solid system ever since I began taking certification exams back in 2005. I first read through a chapter, go through the chapter again taking handwritten notes, convert the notes to digital form, and end with studying the digitized notes each day until the exam. I’ve found by the time I near the end of the book I’ve memorized a good portion of the first half or two-thirds of the book.

The exam required a ton of labbing. I focused on ADCS, ADRMS, and ADFS since those were the three technologies I had the least amount of experience with. DNS has always come easy for me, so I didn’t spend much time on it. After a few months, I had grasped the material and was ready to take the exam.

I heard Microsoft was changing the format of the exams to make them a bit more difficult, and the changes were noticeable. I won’t go into that because I don’t want to violate the NDA. However, there is a video out there from the head of Microsoft’s certification department that talks about the planned changes.

At the end of the day, I scored 858/1000. I was hoping for something in the 900s, but a pass is a pass. I’ve made my notes available here for anyone who is interested.

On to the 70-642!

Configuring EFS with ADCS Server 2008

Over the past few months I’ve been studying for the 70-640. I decided to put the CCNA on hold since I’m in the process of building a new Server 2008 network. From what I’ve gathered from reviews of the exam from my friends over at Tech Exams, the exam really focuses on AD CS.

In the process of studying for the exam, I’ve been labbing AD CS like crazy. Over the past few days I’ve been setting up a virtual lab similar to the advanced lab detailed in the AD CS Step-by-Step Setup Guide.

Today I decided to play with certificate autoenrollment and EFS. I couldn’t find anything on the web that gave the full details on how to set everything up, so I figured I would write up the process to save others the time it took me to round up all the info.

I’m not going to go into how to setup AD CS, as there are plenty of guides out there that will walk you through the process. With that in mind, let’s begin.

Step 1: Duplicate the EFS Recover Agent certificate template

First and foremost you’re going to want to setup a recovery agent. You’ll be able to use this account to decrypt any documents that users encrypt with EFS. This can be useful in situations like where you have to restore an encrypted document from a backup or if a user somehow manages to lose his or her private key. Due to the power of this account, you’re going to want to make sure to lock it down.

Open up Server Manager, expand the ADCS role, click on the Certificate Templates node, and right-cick on the EFS Recovery Agent template and select Duplicate Template. Choose the Windows 2008 Enterprise option (the test lab is a pure 2008 network). On the general tab check off the option to publish the certificate to Active Directory. I would recommend this option for most certificate templates. Make sure your Request Handling tab looks like the one pictured below:

EFS Recovery Agent - Request Handling tab

Microsoft now recommends you use ECC algorithm rather than the RSA (see Microsoft Changes in EFS). This will require you to change the encryption algorithm on the Cryptography tab from RSA to one of the ECDH variants. Next, tweak your security settings to make sure the accounts you plan on using have the enroll permission. Hit Apply and OK to close the window.

Step 2: Duplicate the User and Basic EFS certificate templates

You’ll want to do this is the same way you duplicated the template in step 1. The General, Request Handling, and Cryptography tabs are going to have the same settings we discussed above. Make you properly configure your security settings. I would recommend giving users autoenroll on the User certificate. Google will produce a number of guides for configuring autoenroll of certificates.

Step 3: Add the templates to the issuing CA’s certificate templates

Open up Server Manager on your issuing CA, expand the issuing CA node, right-click the Certificate Templates node and select New -> Certificate Template to Issue. Select the three templates you created and hit OK.

Step 4: Issue the EFS Recovery Agent certificates

Log on to a computer as the account(s) you want to set as recovery agents, open a new MMC and add the Certificates snap-in, and select the Current User option. Once the snap-in opens, right click over the Personal node, select All Tasks, and Request New Certificate. Select the default policy you are presented with, check off the EFS Recovery Agent template you created, and select Enroll.

At this point you should backup EFS Recovery Agent certificate and private key as detailed in this article. Store the backup in a secure location.

Step 5: Configure EFS PKI settings in the Default Domain Policy GPO

You’ll now want to configure the GPO that will push your EFS settings out to the clients. I’m going to place the settings directly into the Default Domain Policy.

Open GPMC and navigate to the node listed in the screenshot below. Right-click over the Encrypting File System node and hit Properties. Configure as shown in the screenshots below.

EFS GPO - General

On the certificates tab, select the custom Basic EFS template you created.

EFS GPO - Certificates

Leave the Cache tab settings as is unless you have a reason to change them. Click Apply and OK to close the window.

Now you’ll need to add the EFS Recovery Agent. Right-click over the Encrypting File System node and select “Add Data Recovery Agent”. Find the accounts you issued the EFS Recovery Agent certificates for and select them.

At this point, you’re done! You have successfully setup the infrastructure for EFS with Server 2008 AD CS. If you autoenrolled the User and Basic EFS certificates, users will be able to encrypt once they reboot their computers. Otherwise, they will need to request them using Web Enrollment or through the Certificates snap-in.

If you end up having to use the EFS Recovery Agent to decrypt an encrypted document, make sure you remember to load the EFS Recovery Agent certificate and private key for the recovery account on the workstation you are logged into. You would accomplish this by exporting the certificate in the same manner as backing up the key. After that, you would open the Certificate snap-in, right-click the Personal node, select Import, and choose the exported certificate.

This was a real learning experience for me and was very useful in reinforcing a number of AD CS concepts. On to Web Enrollment!

*A few additional helpful tips.

  • If you receive “parameter is incorrect” when trying to encrypt a document,
    check the User and Basic EFS certificate templates to make sure you selected an ECC algorithm.
  • If you receive “access is denied” when trying to decrypt an encrypted document using an EFS recovery agent account, verify that you have loaded the private key for the EFS recovery agent certificate on the workstation. This error also occurs if you changed the recovery agent certificate and the item was encrypted before the change. You can verify this by checking the thumbprint of the certificate (details tab when you double-click a certificate) against the recovery agent thumbprint of the encrypted document (right-click document -> Advanced button -> Details button).