Deleting User Accounts in RMS Configuration Database

When you delete a user account from Active Directory, the entry for the user’s rights account certificate that is in the user key table of the root configuration cluster’s configuration database is not automatically deleted. Because of this, the user key table can grow unbounded as new user keys are added, but old ones are not deleted. If the user accounts are not deleted from the database, the RMS Account Certification Report in the RMS Administration page will be skewed with the old user account information.

There are also no SQL SP that can perform this task automatically.

You can however perform the following steps to clean up user accounts in the configuration database:

Note: The tables that are relevant to this scenario are UD_Machines, UD_UserMachine, UD_Users, and UD_WindowsAuthIdentities.

1. Given a user SID that has been deleted from Active Directory, you would first look up the SID in the UD_WindowsAuthIdentities to find the corresponding i_UserId.
2. You would then delete any occurrences of the i_UserId from the UD_UserMachine, UD_Users, and UD_WindowsAuthIdentities tables.*
3. Then, if any i_MachineId entry in the UD_UserMachine table does not have another user designated besides the deleted i_UserId, than that i_MachineId should be deleted out of the UD_Machines table."

Trusted Chain of Keys

It is true that no one knows everything about a technology, but it does help if you have a background in the backend depedency components. When it comes to RMS, there is no denying it, you must understand key encryption, the various types of encryption strengths and how they are used in conjunction with RMS. I will attempt to explain how RMS uses these components in addition to explaining the various licenses (PL/UL).

On the RMS Client side

• Public and private key pairs are used for the RMS Machine Certificate, RAC, and CLC.
• The lockbox (a secure dll that exists on each RMS client) encrypts the private key of the machine certificate.
• The public key of the machine certificate is used to encrypt the RAC (which is unique for each user and machine).
• The public key of the RAC is then used to encrypt the CLC. The RMS servers public key is also stored along with the CLC for offline publishing and for creation of the PL (Publishing license).

On the RMS server side, you have the Server Licensor Certificate. The SLC is also a private and public key pair. The private key of the SLC is encrypted with either a software based password that is provided during RMS Provisioning OR it can be encrypted with an HSM (nCipher, etc.)

All users and computers are assigned public and private key pairs based on the RSA standard while all content is encrypted with AES Symmetric keys (which gets stored in the PL and is referred to in RMS as a content key). RMS uses XrML (not x.509) certificates.

Digital signatures are used as well and provided assurance that data has not changed, providing tamper evidence for document protection. (all certificate and licenses are digitially signed).Digital signatures use a one way hash, which reduces a document to a unique number, often referred to as a document finerprint. This unique has value will change if any of the content is changed. Some examples of has algorithums include SHA-1 and MD5.

RMS Caching

RMS caches Active Directory user and group data in the SQL server Directory Services database. Caching of this information improves performance by limiting the requests made to Active Directory for this information when users request licenses to consume rights-protected content. Decreasing the number of cached entries may cause more frequent requests to Active Directory to be made for user data, depending upon the license-request load and cache expiration settings. Increasing the number may improve performance if the volume of requests to Active Directory is high.

When data is cached, changes to users and groups that have been cached may not be reflected in RMS transactions until the cached data is purged. For example, if a user whose data is cached is added to a new group, requests for RMS use licensed by this user for documents protected using the new group will be denied until the cached data is purged. Therefore, if group membership changes are common, reducing or eliminating data caching may be necessary.

By default, RMS caches data for 720 minutes (12 hours).

Caching can be enabled and disabled in the RMS Configuration database by setting the DRMS_ClusterPolicies table ID 134 to 1.

In addition, if caching is enabled, server registry keys for RMS can be set to control the level of caching. Modification of these is generally only needed to fine-tune performance if load on the RMS infrastructure increases to the point that performance degradation is seen or to resolve problems with stale cached data due to user and group modifications.

Why would you need a subordinate licensing server?

A few days ago, I had a discussion on why you would ever want to have a subordinate licensing server in an RMS Design. In this posting, I will walk through some of the discussion points:

In the RMS world, a licensing cluster can only issue Use Licenses from the licensing server where the originating publishing license was generated. The root cluster (certification) still handles user enrollments, proxying of workstation enrollments, revocation of subordinate licensing servers, server licensor certificate. What this means is that there is still traffic generated over the WAN link, so if you are trying to avoid network usage, this is not the best option.

A subordinate licensing server is best used in situations where a department (e.g. R&D) needs to be completely isolated from rest of the company and to ensure that only use licenses are granted to users who are in R&D (assuming the user publishing content is in R&D). This ensures that the super user group, who can decrpt RMS protect dcoument, is only known by that department and not the root cluster. There are other scenarios where a subordinate licensing server might come into play, including high usage, slow networks or DMZ, but these all have severe downfails which I usually veer away from.

If we take placing a subordinate licensing server in a DMZ for instance, and its being done so that external users can obtain use licenses for internally published content, then you will run into issues authenticating those users. This is where something like ADFS or creating external user accounts would come into play and is outside the expertise of RMS.

For a high usage scenario, this is really not a feasible option simply because RMS should be clustered together at the root server and nodes added to the cluster as capacity increases. There are several reasons for this, most notably for ease of administration.

What doesn't RMS do out of the box?

As I said in my previous post, RMS is not a golden egg to solve the world's security problems. Out of the box, RMS does not:

- Provide a holistic policy enforcement based on business groups (finance, HR, legal). What this means is that you will need to configure each group of RMS consumers and manage them seperately outside of RMS. There is also no way to identify who can use RMS and who can protect using RMS.
- There is no way to enfore an RMS Template to be applied to a document, whether it be word or an email. More on RMS template will be discussed in another posting.
- Protection of Derivative content - RMS protection does not move between applications.
So if a user moves RMS content into a non RMS protect document that content (assuming they have the RMS rights) is no longer RMS protected.
- Non-Microsoft Applications - with RMS SP2, xps and infopath products are now RMS Enabled applications in addition to those existing RMS enabled applications (word, excel, powerpoint and outlook). If you want to enable RMS protected for non microsoft applications, you would need to look into customzing the application using the RMS SDK or look into using a third party tool (Liquid Machines Document Control 6.x)
- Role based document expiration - there is no way to expire documents on a per user and role basis.

What is RMS?

You might be asking what exactly is Rights Management Services and why would I want to implement this version 1 product? The short answer is that it is used to protect highly sensitive documents, reduce liability and information disclosure.

RMS is not the golden egg by any means. It should be used in conjunction with other solutions such as smart cards to protect private keys, perimeter security, etc.

RMS does not require nor utilize standard x.509 certificates (PKI) but rather uses XrML based certificates (based on XML, www.XrML.org)

In order to understand RMS under the covers, you need to understand that RMS Is based on public key technology, symmetric keys (content key) and certificates. RMS uses a server as an intermediary to solve some of the traditional challenges associated with public key technology (public/private key process is CPU intensive and slow, distribution of symmetric key to recipient, etc.)

RMS CAL in Vista

This week I had a question relating to the RMS Client CAL in Vista and whether it would be free. The short answer is no, it will not be free with Vista.

"The RM Client comes out of the box with all versions of Vista. It is there for free to use with Passport. If you want to use it with RMS services, it requires the same CAL as any other version. One CAL per RMS user."