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 AD RMS under the hood: Client bootstrapping (Part 2 of 2).
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.
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:
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 server bootstrapping, 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:
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.
Alexey Goldbergs, Technology Solutions Professional, Microsoft Russia
Enrique Saggese, Senior Security Consultant, Security Center of Excellence
Is my assumption correct that an AD RMS Client Version 2.0 uses different file system directories and registry keys?
AD RMS Client 2.0 Deployment Notes -
Thanks for your information on AD RMS. Everytime when I was reading word 'bootstraping' , it looks such heavy to me that I thought it would be definately going a complex process which need extensive efforts by administrators...
Juergen, sorry for the delay in responding. Yes, the 2.0 client uses different folders and registry keys, since the two clients can coexist for different applications in the same computer.
I would like to use the RMS encryption through ASP.NET Web form of data flow, refer to link code.msdn.microsoft.com/.../AD-RMS-SDK-20-Interop-eb3fbce7
But has not been successful, please could you give an example???My EmailBox:email@example.com
Thanks appreciate it
If you're interested in how Azure RMS works, under the hood - see