Hi folks,

Although this blog normally features content updates and product announcements from the members who work with me within the Information Protection team here at Microsoft, we do occasionally have the opportunity to feature guest bloggers from AD RMS community whose expertise we think you will really enjoy and benefit from hearing.

In this case, I'm pleased to offer you Part 1 of 2 in the story on AD RMS client bootstrapping that Alexey Goldbergs of Crypto-Pro will be be presenting on our team blog. It gives a lot of great insight to what is happening at a deeper level at the AD RMS client as users access rights-protected content. (Update: if you are looking for Part 2, it's out now here at .

Though we like to pride ourselves on making AD RMS something you shouldn't have to know all the "under the hood" workings of to make great use of it, for those who enjoy knowing more of that sort of thing, Alexey can and will provide you all the intimate technical details.

Enjoy!

Hello, Alexey here again. Today I want to start the deep diving into client bootstrapping.

Client bootstrapping occurs the first time each AD RMS user tries to protect or consume protected content (such as documents or messages) on an AD RMS client computer or device and includes three consecutive steps:

1. Security Processor Certificate (SPC) creation also known as “machine activation”.
2. Acquisition of a Rights Account Certificate (RAC) also known by its old name, the Group Identity Certificate (GIC).
3. Client Licensor Certificate (CLC) acquisition.

Since I prefer short blog posts (sorry, Enrique J), I will describe only the first step today: machine activation. During machine activation, the AD RMS client creates an SPC and a corresponding private key. This identifies the lockbox on the AD RMS client computer or device that is correlated with the logged-on user’s profile.

As with , client machine activation in AD RMS is different than in Windows RMS (v. 1.0). In Windows RMS, the client machine was connected via the Windows RMS server to an Internet activation service hosted by Microsoft. This activation service generated a unique lockbox containing private key and machine certificate, which allowed the client machine to use Windows RMS. This behavior was changed in Windows RMS Service Pack 1 (SP1). The following figure shows how it looks in AD RMS:

• The AD RMS Client generates a 1024-bit RSA public/private key pair using the client lockbox (%WinDir%\System32\secproc.dll). The key length and crypto algorithm are part of the AD RMS client software, so you cannot change them.
• The client encrypts the private key using the user’s password and .
• The resulting blob is secured through RSAVault and stored in the registry.
• The client creates an SPC that includes the public key it just created, tied to hardware ID. The SPC is unique for each AD RMS user that logs on to the client computer.
• The client signs the SPC with its private key, so the SPC is a self-signed certificate of the AD RMS client.
• Finally, the AD RMS client writes the results to a file (CERT-Machine.drm) in the %LocalAppData%\Microsoft\DRM folder. To ensure that the private key is kept private, the CERT-Machine.drm file (that will be shared in a future step) does not contain the AD RMS client computer’s private key.

Another difference between Windows RMS SP1 and AD RMS is that AD RMS does not require end users to have administrative privileges on their machine in order to perform the activation process.

On the next blog post I will discuss the next step: RAC/GIC acquisition.

Author:

Alexey Goldbergs, Technology Solutions Professional, Microsoft Russia

Reviewer:

Enrique Saggese, Senior Security Consultant, Security Center of Excellence

Hi folks,

A little while back we had a guest blog post that provided Part 1 of the story on AD RMS client bootstrapping by our esteemed community member Alexey Goldbergs of Crypto-Pro first presented here. I'm pleased to announce that Part 2 is now available.

Enjoy!

Hey, what's up? After a very looooong delay it's Alexey Goldbergs of Crypto-Pro here with you once again to give you the rest of a deeper look into the AD RMS client bootstrapping process.

As I mentioned in my previous post, , this is the second part of my discussion on how the bootstrapping process occurs, from the client perspective, which consists of acquiring user certificates, including the Rights Account Certificate (RAC). In some materials you might also see the term Group Identity Certificate (GIC) but keep in mind if you do that it is referring to the same thing. (You can check out this by Enrique Saggese to learn more about what the RAC is and how it is related to other AD RMS entities.)

RAC acquisition starts right after the . This is the first time when an AD RMS client communicates with the AD RMS Server and the RAC is the first certificate that isn’t self-signed but is signed by AD RMS Server certificate (SLC) which was created during the AD RMS Server bootstrapping process described in Part 1.

But before the client can receive the RAC it should find the "right" AD RMS Certification Server. So this is how the service discovery process looks like in a typical scenario (Note that this is the sequence for a client trying to protect content for the first time. The process is slightly different for a client that’s consuming content before it is activated for the first time):

1. Client checks if it has been manually configured with registry settings for activation.

   ○   For x86 clients: HKEY_LOCAL_MACHINE\Software\Microsoft\MSDRM\ServiceLocation.

   ○   For 64 bit clients running 32 bit applications: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\MSDRM\ServiceLocation.

   You can find more details about key values for registry overrides in this article, .

2. If these registry keys are empty then the client sends the request for RMS Service Connection Point (SCP) to Active Directory, which returns the URL for the Intranet Certification URL configured by AD RMS.

3. After the client has used this URL to acquire a RAC, the client communicates with the AD RMS Certification "ServiceLocator" service to ask for the AD RMS Licensing Service URL. This service will be used for getting the next certificate - the Client Licensor Certificate (CLC). This URL could also be manually configured in the client with registry keys instead of using automatic discovery.

Going back to RAC acquisition, as soon as the client finds the certification server it goes through the following sequence:

1. Client sends request for the RAC and it includes its Secure Process Certificate (SPC) to the AD RMS Certification Server (<http/https>://<AD_RMS_cluster_name>/_wmcs/certification/certification.asmx).
2. The server extracts machine public key from the SPC sent by the client.
3. The user has already authenticated against the web service, so the server users the user information to query the users email address from Active Directory.
4. The server checks if the user already has a RAC in the AD RMS database (as you will see it the next steps the RAC is stored there as an encrypted blob) and if so gets it from this database.
5. If the user doesn’t have a RAC in AD RMS database then the server generates the key pair which could be up to RSA 2048-bit if the cluster is configured to use instead of default RSA 1024-bit.
6. The server encrypts the key pair using its public key.
7. The server submit created blob to its database for the next time this user will request RAC from another device.
8. The server creates a Rights Account Certificate that includes user’s RAC public key.
9. The server signs this RAC with its private key.
10. The server encrypts the user’s RAC private key using machine’s public key (extracted from received SPC in step 1).
11. The server sends encrypted private key and RAC back to the client.

Properties of the RAC will vary depending on the client situation and authentication mechanism. There are five types of RACs AD RMS will issue, used for different scenarios and with different validity period:

** - The default lifetime of 365 days for a standard RAC is a setting that many organizations in actual deployment choose to reduce. Like most other certificate and license lifetimes, the duration of the RAC can be modified to suit your needs if you decide that you want to control who can use AD RMS more tightly. This is a configurable option in the AD RMS management console.

After acquiring the RAC, the client uses the service discovery process discussed above to find the Licensing URL, which it will use to acquire a Client Licensor Certificate, the final certificate that is used to protect content.

CLC issuance is very similar to RAC issuance, with the only difference (besides being done by calling Publish.asmx in the Licensing pipeline instead of Certification.asmx in the Certification pipeline) that CLCs are not stored at the server, so every time you request a new one (e.g. because you are using a new client machine) the server will generate it from scratch. This is not a problem since the CLC is only used for signing Publishing Licenses for protecting content and not for encryption.

After creation at the server, the CLC private key is encrypted with the users RAC public key and sent to the client along with the Client Licensor Certificate, so the client will be able to decrypt the private key when needed to create protected content.

Once the client has received the RAC and CLC, the client is fully bootstrapped and ready to protect new content.

Author: Alexey Goldbergs, Deputy Chief Technical Officer at .

Contributor: Enrique Saggese, Sr. Program Manager, Information Protection team, Microsoft.