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!
- Dan
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):
-
Client checks if it has been manually configured with registry settings for activation.
? For x86 clients: HKEY_LOCAL_MACHINESoftwareMicrosoftMSDRMServiceLocation.
? For 64 bit clients running 32 bit applications: HKEY_LOCAL_MACHINESoftwareWow6432NodeMicrosoftMSDRMServiceLocation.
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:
- 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).
- The server extracts machine public key from the SPC sent by the client.
- 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.
- 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.
- 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 Cryptographic Mode 2 instead of default RSA 1024-bit.
- The server encrypts the key pair using its public key.
- The server submit created blob to its database for the next time this user will request RAC from another device.
- The server creates a Rights Account Certificate that includes user’s RAC public key.
- The server signs this RAC with its private key.
- The server encrypts the user’s RAC private key using machine’s public key (extracted from received SPC in step 1).
- 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:
|
Type of RAC |
Decsription |
Default Validity Period |
|
Standard RAC |
Domain joined computer |
**365 days |
|
Temporary RAC |
Stand-alone computer or computer belonging to another domain |
15 minutes |
|
AD FS RAC |
Used for federated users |
7 days |
|
Windows Live ID RAC Private |
Used for Windows Live ID on a private computer |
6 months |
|
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.