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.
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, AD RMS under the hood: Client bootstrapping (Part 1 of 2), 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 post 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 SPC creation. 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):
○ 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 related TechNet article, AD RMS Client Requirements.
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.
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:
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:
Type of RAC
Default Validity Period
Domain joined computer
Stand-alone computer or computer belonging to another domain
AD FS RAC
Used for federated users
Windows Live ID RAC Private
Used for Windows Live ID on a private computer
Windows Live ID RAC Public
Uses for Windows Live ID on a public computer
Until you log off
** - 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 Crypto-Pro.
Contributor: Enrique Saggese, Sr. Program Manager, Information Protection team, Microsoft.