Unlocking the black box that is AD RMS Part 2

Let’s begin shall we. I’ve included a copy of the captures I used to gather the information below.

Scenario: Client IntraForest Activation and Creation of Protected Content
Author: UserA@contoso.local
Consumer: UserB@contoso.local
Captures: Scenario 1 Captures

  1. Client searches registry to see if service connection point (SCP) has been hardcoded. It checks the following keys:
    1. HKLMSoftwareMicrosoftMSDRMServiceLocationActivation – This is a hardcoded location for client activation.
    2. HKLMSoftwareMicrosoftMSDRMServiceLocationEnterprise – This is the hardcoded location to obtain a CLC.
    3. HKCUSoftwareMicrosoftOffice14.0CommonDRMServiceLocation – This is where previously discovered service locations are stored for Office 2010.
    4. HKCUSoftwareMicrosoftOffice15.0CommonDRMServiceLocation – This is where previously discovered service locations are stored for Office 2013.
  2. Client then queries contoso.local global catalog for an AD RMS SCP with the following query:
    • Filter: (& (objectClass=serviceConnectionPoint)(keywords=MSRMRootCluster)(keywords=1.0))
      Attributes: ( serviceBindingInformation )
  3. Domain controller in client’s domain returns the AD RMS SCP information. This value is normally http(s)://RMSClusterDNSName/_wmcs/certification.
  4. Client connects to SCP which exists in AD RMS server and is directed to ServiceLocator.asmx and requests a service location URL for obtaining a CLC.
  5. AD RMS returns the Contoso.local AD RMS cluster’s licensing pipeline which is normally set to http(s)://RMSClusterDNSName/_wmcs/licensing
  6. Client writes this information to the following registry entries/keys:
      Office 2010

    • HKCUSoftwareMicrosoftOffice14.0CommonDRMCachedCorpLicenseServer
    • HKCUSoftwareMicrosoftOffice14.0CommonDRMServiceLocations
    • Office 2013

    • HKCUSoftwareMicrosoftOffice15.0CommonDRMCachedCorpLicenseServer
    • HKCUSoftwareMicrosoftOffice15.0CommonDRMServiceLocations
  7. Client connects to SCP which exists in AD RMS server and is directed to ServiceLocator.asmx and requests a service location URL for activation (obtaining a copy SLC public key).
  8. AD RMS Server returns activation pipeline which is normally set to http(s)://RMSClusterDNSName/_wmcs/certification.
  9. Client writes this information to a series of registry entries in the following key:
    • HKCUSoftwareMicrosoftOffice14.0CommonDRMServiceLocations – Office 2010
    • HKCUSoftwareMicrosoftOffice15.0CommonDRMServiceLocations – Office 2013
  10. Client connects to SCP which exists in AD RMS server and is directed to ServiceLocator.asmx and requests a service location URL for performing certification (obtaining a RAC)
  11. AD RMS Server returns certification pipeline which is normally set to http(s)://RMSClusterDNSName/_wmcs/certification.
  12. Client writes this information to a series of registry entries in the following key:
    • HKCUSoftwareMicrosoftOffice14.0CommonDRMServiceLocations – Office 2010
    • HKCUSoftwareMicrosoftOffice15.0CommonDRMServiceLocations – Office 2013
  13. Client contacts Activation URL (which is normally http(s)://RMSClusterDNSName/_wmcs/certification) and hits Server.asmx to obtain a copy of the SLC’s public key.
  14. AD RMS Server returns a copy of the SLC’s public key to the client.
  15. Client receives a copy of the SLC public key and performs machine activation generating a machine key in C:UsersUserNameAppDataLocalMicrosoftDRM for Office 2010 and C:UsersUserNameAppDataLocalMicrosoftMISPC for Office 2013.
  16. Client contacts Certification URL (which is normally http(s)://RMSClusterDNSName/_wmcs/certification) and hits Certification.asmx to obtain a RAC.
  17. AD RMS Server checks it’s database to see if it has a copy of the user’s RAC, if not it generates one using the following process.
    1. AD RMS Server queries a DC in its local domain for the user’s email address using the user’s SID as an identifier. The following query is used:
      • Filter = ( & ( | (objectSid=User’sSID) (sIDHistory=User’sSID) ) ( | (objectCategory=CN=Computer,CN=Schema,CN=Configuration,DC=domain,DC=com) (objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=com) ) )
        Attributes = mail,objectSid,sIDHistory,proxyAddresses,memberOf,primaryGroupID,distinguishedName,uSNChanged,msExchOriginatingForest,msExchDynamicDLBaseDN, msExchDynamicDLFilter,userPrincipalName,sAMAccountName
    2. AD RMS Server queries a DC in its local domain for the user’s primary group. I’m unsure as to why it does this. The debug logs say something about establishing immediate group membership. The following query is used:
      • Filter = ( & (objectCategory=CN=Group,CN=Schema,CN=Configuration,DC=domain,DC=com)(objectSid=PrimaryGroup’sSID) )
        Attributes = distinguishedName
    3. AD RMS Server generates a RAC with the ID field populated with the user’s email address and sends back to user.
  18. Client receives RAC and saves it to C:UsersUserNameAppDataLocalMicrosoftDRM for Office 2010 and C:UsersUserNameAppDataLocalMicrosoftMISPC for Office 2013.
  19. Client contacts CLC Service URL (which is normally http(s)://RMSClusterDNSName/_wmcs/licensing and hits publish.asmx and requests a CLC.
  20. AD RMS Server creates a CLC and sends it to the user.
  21. Client receives CLC and saves it to C:UsersUserNameAppDataLocalMicrosoftDRM for Office 2010 and C:UsersUserNameAppDataLocalMicrosoftMISPC for Office 2013.

Client Activation and Creation of protected content is complete.

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: