Freigeben über

An Expired SLC in AD RMS?

  • Artikel

In the world of technical support, issues seem to appear in clusters at times. I’ve just had a couple of issues where the AD RMS server licensor certificate (SLC) expired.

The the olden days, as my kids call it, RMS v1 had an SLC with a two year validity. Hence it needed to be renewed every two years (renewing an SLC nowadays requires a workaround). When you provision an AD RMS server (either fresh or upgrading from v1) the SLC is given a lifetime validity of over 250 years. Thus in AD RMS there is no mechanism for renewing the SLC.

If the above paragraph is true then how would one have an expired SLC in AD RMS? How would this expired SLC manifest itself? I’ll partially answer the former question and delve into the latter.

The only expired AD RMS SLC issues I’ve encountered stem from an upgraded RMS v1 environment. The appearance of the issue is subtle.

Issue appears:

At some point in the RMS v1 lifetime the SLC was created and a two year countdown to expiration began. Any SLC renewal reset the two year timer. AD RMS is added and the RMS v1 cluster is updated (so we thought). However, in some cases, the SLC is not updated. So the two year expiration countdown is still, well, counting down.

Expiration day arrives and most folks don’t notice at first. Unless a user gets a new RAC or CLC, creating protected content works fine. Any protected content for which one already has a valid license is good. Only in instances where a new use license is generated or new RAC needed does one start seeing errors.

New content use licenses issued from the expired SLC RMS server are correctly tagged as invalid by the client. Protected content may not be accessed. I don’t recall the exact errors the user receives but I do remember they were nothing unusual. Nothing in the error messages made me suspect anything out of the ordinary.

As a few day passes more existing (and valid) licenses expire and more folks get new ones and these invalid licenses don’t open the content. On the surface we just find a few more users complaining that they can’t get to content. All this licensing stuff is happening underneath and we don’t really notice that part.

Troubleshooting:

Getting a client-side trace give us our first hint. However this is small and easily missed clue. In the heavily edited snippet from one such failed client log there’s the arrow pointing to the issue.

[msdrm]:+DRMGetSignedIssuanceLicense
[msdrm]:DRMGetSignedIssuanceLicense Args...
<SNIP>
[msdrm]:-DRMGetSignedIssuanceLicense HR=8004cf58   

The DRMGetSignedIssuanceLicense return is the key error. E_DRM_INVALID_CLIENT_LICENSOR_CERTIFICATE (0x8004CF58)

From a server-side trace or opening protected content in notepad and digging through the XML we find the root cause.

<SECURITYLEVEL name="Server-Version" value="5.2.3790.134" />
<SECURITYLEVEL name="Server-SKU" value="RMS 1.0" />
<OBJECT type="Server-Licensor-Certificate">
<FROM>2003-02-05T00:00</FROM>
<UNTIL>2012-07-13T22:37</UNTIL>

Looking at the selected items above (cherry picked from the XML in trace output) several things are of note. This is an AD RMS cluster yet the "Server-Version" is v1. More importantly the the from/until date range is expired. This is an expired SLC.

Resolution:

This appears to bring us back to the main question. The question of how does an AD RMS SLC expire? Better yet, how do I fix it?

Once again, my friend and our RMS guru, Jason had the answers. The cause of this is what Jason dubbed the “half baked upgrade.” The steps to fix this issue is exactly as Jason described in that post.

Prerequisites:

  • AD RMS Service account password.
  • AD RMS cluster key password. *
  • Have a machine we can temporarily add the AD RMS role onto (joining the existing cluster).
  • Have a user account that is
    • a local administrator on the new AD RMS server
    • an enterprise administrator, and
    • a sysadmin on the SQL instance hosting the AD RMS databases.
  • Back up the RMS databases.

* No matter how positive you are that you know the RMS cluster key password you don’t. The most common way to get into this situation is not knowing the cluster key password when attempting the initial upgrade from RMS v1 to AD RMS. It would be prudent to just reset the cluster key password to what you think it already is before you do any of the other steps. It’s really easy.

Steps to fix:

  1. Export the AD RMS server certificate.
  2. Export the AD RMS server trusted publishing domain (TPD) certificate.
  3. Edit the ADRMSFileVersion value in the DRMS_ClusterPolicies table of the DRMS_Config database (screenshots on this step below).
  4. Add the AD RMS role to the new server, adding it to the existing cluster.

One the “upgrade” is successful you may remove the role from the temporary cluster member added.

AdRmsFileVersion 1

AdRmsFileVersion 2

AdRmsFileVersion 3

Comments

  • Anonymous
    January 01, 2003
    good to see explaination along with the snapshot............