It’s time for client activation. As of now we have:
- Client PC with Security Processor Certificate (SPC)
- AD RMS server with Service Licensing Certificate (SLC)
- Server with Active Directory Domain Service role.
- SQL server with RMS databases.
So, client has to be activate first to start protect documents. As you remember when you installed AD RMS server role you also registered Service Connection Point. This is specially entry in Active Directory which allows clientsto identifies the connection URL for the service to the AD RMS-enabled clients.
1. Client “asks” AD DS for Service Connection Point, looks like “give me the URL where AD RMS role is hosted”. This step is very important: if client activation doesn’t happen I recommend to start first of all with “Get RMS SCP” command from AD RMS Toolkit . Here you can find some trick how to force RMS activation on client side without appropriate entry in Active Directory. The secret in client registry.
2. As the answer on client request it gets appropriate URL AD RMS Certification pipeline: https://<RMS>/certification.asmx
3. Using URL which client got on a step above, it asks RMS server for Rights Account Certificate (RAC). This request for RAC contains user’s Security Processor Certificate (SPC). Understanding AD RMS Ceritificates.
4. AD RMS server unpack public key from user’s SPC for future purposes (step 9).
5. AD RMS server sends request to AD DS for user’s email address. Why does RMS require SMTP address for user? Why RMS require SMTP entry at least (instead of real email address in your email exchange system)? Good questions, think so? I’ll publish answer at next post, just leaving this question for you…
6. Probably this isn’t a first user’s attempt to ask for RAC, probably RMS server already had issued RAC for user earlier? RMS checks RAC for appropriate user in SQL server. The next step depends on RAC availability in SQL server: if RAC already exist server brings it back for user (not interesting case for us), otherwise server generates new RAC.
7. Server generates key pair: private and public key for RAC. The key length might be up to RSA 2048 bit if your RMS server already was patched and configured for Cryptographic Mode 2
8. AD RMS server encrypts new key pair with SLC public key and store result (BLOB) in SQL. So, next time when RMS-client asks for RAC , RMS server will bring back certificate with these public\private keys in it (see step 6).
9. Finally (for this stage) RMS generates new RAC certificate and put there:
- public key
- private key encrypted with user’s public key from SPC (server got this SPC public key on step#4).
Server signs RAC certificate with public key from SLC.
RAC certificate is ready to be sent to user. Done!
10. It’s time to order Client Licensor Certificate (CLC), which can be submitted only with RMS licensing web role. What the URL for this licensing role?
It is obvious from AD RMS console, but it isn’t obvious for client. Client asks for licensing URL and substitutes “Certification.amsx” in pipeline for “Publishing.asmx”
11. Client asks fro CLC using URL address which it got on a step above.
12. RMS server generates key pair: public and private key for CLC, generates new certificate and put there these 2 keys:
- public key
- private key protected with public key from RAC. So, only RAC’s private key owner can decrypt CLC private key.
Server signs new CLC certificate with public key from SLC.
Pay attention that CLC certificate, neither keys aren’t saved in SQL, it means that RMS server generate these keys\certificate each time when client asks for them. How often it happens? Obviously not so often: when end-user uses new client PC. In the rest cases end-users uses CLC to sing Publishing license which was requested earlier.
CLS is done and ready to be sent to user back with RMS server SLC.
Congratulation. We are ready to protect and consume protected documents.