(This blog post was published on the original RMS team blog in March 2010.)
Hi folks,
Today I'm acting as a conduit for one of the many AD RMS experts that we have in the community that work with us at Microsoft. Thanks to Alexey for sharing his knowledge about the inner workings of AD RMS!
- Dan
First of all let me introduce myself. My name is Alexey Goldbergs and I’m a Technology Solutions Professional on Security from Microsoft Russia. With this blog post I want to start the series which I call “AD RMS Under the Hood” where I’m going to explain you how AD RMS really works behind the scene.
Those of you who have heard about Active Directory Rights Management Services (hereinafter referred to as “AD RMS”) have at least once seen the following picture or one like it:
-
Author receives a Client Licensor Certificate the first time they rights-protect information.
-
Author defines a set of usage rights and rules for their file; application creates a Publishing License and encrypts the file.
-
Author distributes file.
-
Recipient clicks file to open, the application calls to the RMS server, which validates the user and issues a Use License.
-
Application renders file and enforces rights.
But what does it really mean to say that the “author receives a Client Licensor Certificate”? What is the Publishing License (PL)? What does the Use License (UL) look like? Well…. This is why I’m here, actually.
On the next few of my blog posts you will get to know the answers to all these questions.
But before we get started let’s step back and look at the activation process of the first server in a new AD RMS cluster (also known as server bootstrapping ). What happens when you click on the Install button on the last page of AD RMS Server role installation wizard?
-
At the beginning of the bootstrapping process, the server generates key pair.
The key length depends on the option which you chose on the Configure AD RMS Cluster Key Storage page in the installation wizard. There are two options available: Use AD RMS centrally managed key storage and Use CSP key storage . With the first option the server generates a 1024-bit RSA public/private key pair.
If you selected the second option ( Use CSP key storage ), you can select a hardware-based CSP (cryptographic service provider), also known as a hardware security module HSM) which allows you to improve the security of the private key by keeping the private key in a tamper-resistant hardware module and never exposing it to software-based attacks.
The next steps describe the process for the first option selected. -
The server encrypts the private key using the complex AD RMS cluster key password (which you entered on the appropriate page of the installation wizard) and DPAPI .
-
The resulting blob (binary large object) is stored in the AD RMS configuration database. The private key is retrieved and decrypted (with the complex password stored under the AD RMS service account profile) from this database each time an AD RMS server is booted.
-
Next, the server creates the server licensor certificate (SLC) which includes the AD RMS cluster public key.
-
Finally, the server signs the SLC with its private key (thus, it is a self-signed certificate).
And this is the key difference between AD RMS and Windows RMS (the predecessor of AD RMS) server bootstrapping. Unlike Windows RMS, the AD RMS key chain root does not link up to Microsoft; instead, it ends in the organization’s AD RMS certification cluster SLC.
Here is how Windows RMS (Windows Rights Management Services) bootstrapping looked after the server generated the key pair:
-
The server created an enrolment request package which included the server’s URL, version, internal server name, public RSA key, and GUID.
-
The enrolment request was sent to the Microsoft Enrolment Service.
-
The enrolment service returned a certificate chain that contained the licensor certificate chain of trust as well as the licensor certificate itself, which contained the server’s public key. This certificate was signed by the enrolment server private key.
Another difference is that the Windows RMS SLC key was valid for one year and needed to be periodically renewed, whereas the AD RMS SLC is valid for 250 years.
The created SLC is shared by all the servers in the new AD RMS cluster.
On the next blog post I’m going to add some details which Enrique intentionally skipped through on his blog post .
Stay tuned!
Author:
Alexey Goldbergs, Technology Solutions Professional, Microsoft Russia
Contributor:
Enrique Saggese, Senior Security Consultant, Security Center of Excellence
Reviewer:
Sergey Simakov, Senior Security Consultant, Security Center of Excellence