Any RMS protected content can only be consumed or created within the trust boundaries of the domain. It is sometimes desirable to be able to share protected content with other external parties (Partners etc) so what do you do then? Well there are a number of options available, of which the main three used are:

TUD – or Trusted User Domain is primarily used when a company with an RMS infrastructure wants to share protected content with another organization with their own RMS infrastructure. In order to do this a traditional Active Directory trust must first be in place, we can then export the SLC public key of the RMS cluster from the domain wanting to consume content and import it on the RMS cluster in the domain wanting to share content. This of course can be replicated both ways so that both sides can open RMS protected content from the other.

TPD – or Trusted Publishing Domain is usually used in one of two scenarios, one where an AD RMS cluster is being decommissioned and replaced. An example might be where forests are being merged and one cluster is taking over the functions of the others. The other scenario might be when a cluster has to issue licenses for content protected by clusters in another forest (can be used for cross forest RMS protected content exchange) To implement this trust you must export the private key of the cluster you are wanting to consolidate and import it into the TPD section of the remaining AD RMS cluster, this is so use licenses can still be acquired for content protected by the decommissioned cluster.

AD FS support for AD RMS – This is an extremely good feature for collaboration with multiple forests where partners do not have their own AD RMS infrastructure or even don’t have directories based on AD. To implement this solution AD FS must be configured and a federation trust must be in place. You then in AD FS usually create a new claims aware application entry for AD RMS certification URL, you can then define which claims to accept (for AD RMS this is UPN then email) you then do the same for the licensing URL. You must also make sure to add the server role for AD RMS Identity Federation Support and enable federated identity support in the AD RMS console. There are some registry key changes that have to be made on the trusted domain machines (the side without AD RMS) so that the home realm discover works correctly but this can be done via GPO’s*. You will then be able to send and receive RMS protected content from this entity even though they do not have AD RMS implemented!

• *Registry Key – HKLM/Software/Microsoft/
• Create registry key: MSDRM
• Under this create another registry key: Federation
• Under this add a string value named: FederationHomeRealm
• with a value of: urn:federation:YourDomain.com

So as you can see there are many options for expanding your RMS protection outside the boundaries of your domain or forest. Hope you find this useful!

Recently had an issue with our internal RMS infrastructure where users were not able to RMS protect any documents, email etc. Going through some troubleshooting I found that clients were not going through the bootstrapping process correctly and therefore were not getting the needed XrML RMS certificates …..

So I was able to browse to the certification and license pipelines no problems, AD RMS server was contactable, was seeing the traffic hit the server in the IIS logs some with 403 and 404 errors…Resolution??

If you go to internet options >> Advanced >> Security and then uncheck the two options:

Check for the publishers certificate revocation

Check for the server certificate revocation

Then try and RMS protect content then suddenly bootstrapping process works, you get your certificates and all is good!

The reason for this is if your AD RMS certification and licensing pipelines are using an internal CA to issue a certificate for HTTPS and your client machines cant reach the CRL distribution point it will not allow you to connect! The quick fix is to uncheck the two options specified above and go through the bootstrapping process, you will then be able to protect and consume RMS content. However the correct fix is to ensure the CRL distribution is correct for your CA and accessible for your AD RMS clients

Want to implement AD RMS but already have file servers full of unprotected content? No problem! With the AD RMS bulk protection tool and File Classification Infrastructure this can be achieved. In FCI we can create classifications based on business impact (based on Key words e.g. private, or regular expressions such as National Insurance numbers etc) and have RMS templates applied to classifications as we see fit, oh the power! * This can also continue to apply to additional files uploaded to the file servers each time the File Server Resource Manager rules and file management tasks run (which can run on a schedule) You can also using FCI set a flag to apply to files that have been encrypted with a time stamp and can configure it to send an email to the owner of the file which has been encrypted.

Have SharePoint libraries? Again no problem these can be configured to apply protection based on the NTFS permissions on download from the library, it’s all covered! Automation is the new buzz word within RMS and it continues with Exchange 2010’s automatic protection of emails using transport rules to apply pre-defined templates based on email content or recipients.

*Note – By default only the Microsoft Office suite and xps viewer file extensions can be RMS protected, however IRM’s can be downloaded for hundreds of other file types so nearly all file extensions can benefit from RMS protection!

To RMS or not to RMS? I think the former

Just a quick post to advise Microsoft has now released a KB to remove the application manifest expiry feature in AD RMS. The reason for this is that this legacy feature was previously used to confirm that applications accessing or creating RMS protected content were to be trusted.

This was done by applications being signed by application signing certs issued by MS. Once the application signing cert expired the application would no longer be trusted to open or create RMS protected content until it was renewed with application updates, which would cause problems and errors between expiring signing certs and application updates!

This can now be controlled by the system administrator rather than by signing certs, administrators can now define applications, or older versions of applications as untrustworthy themselves.

The update to remove this feature is KB979099 where the update can be found for all RMS client operating systems.

RMS secures data using certificate key pairs, however it does not require PKI which is a common misconception. PKI can be very useful alongside RMS for securing communications between client and server etc however it is not a requirement. The certificates used in RMS are in XrML (Extensible rights Markup Language), those you should be aware of are as follows:

Server Licensor Certificate – This is the certificate created when RMS is installed on the first server in a cluster, it is a unique certificate to identify itself. If further servers are added to the cluster then the SLC is shared with these. By default in a root cluster this deals with certification by issuing RAC’s and licensing protected content. In particularly large implementations additional licensing servers can be installed which have their own SLC

Machine Certificate – This is created the first time that a RMS aware application is used and is tied to the hardware of the machine as well as the user login, so multiple Machine certificates can exist on the same machine if multiple users use it. As well as the machine certificate machines receive a unique Lockbox. The Lockbox contains the machines private key and the machine certificate contains the machines public key so the Lockbox is central to all encryption and decryption.

Rights Account Certificate – This is the certificate which identifies a user and a standard RAC is associated with the computer that the user is logged onto. The SLC issues a RAC to the client the first time they attempt to consume RMS protected content. The RAC contains the key pair and the private key is encrypted by the public key of the machine certificate.

Client Licensor Certificate – The CLC is created by the root cluster and sent the the client when they try to protect content using RMS aware apps. They have to be connected to the network to receive this but it grants them the right to publish content, even when not connected. Same as the RAC the CLC contains a key pair, its private key is encrypted by the public key of the user who requested it (their RAC) It also contains the public key of the cluster which issued the certificate which is signed by the private key of the cluster. The private key of the CLC signs any Publishing Licences it creates

Publishing Licence – The PL is created when a client right protects content and specifies what users have access and what access they have. It contains a symmetric key to decrypt the content which is encrypted by the public key of the cluster which issued the PL.

Use License – This is presented to a client when they attempt to access rights protected content and contains the rights of the authenticated user requesting access. This is tied to the RAC (which identifies the user). The PL will be sent to the Root Cluster along with the users RAC and if access is allowed the cluster will decrypt the symmetric key using its private key and then re-encrypt the symmetric key using the public key of the user. The user will then be able to decrypt and use the rights they have been granted to access the data.

Heavy stuff but hope this can make a little more sense and show how robust AD RMS actually is! Hopefully will follow up with some more information on integration with some well known MS technologies such as Exchange and SharePoint in the near future…

Active Directory Rights Management Services is a very powerful and useful product to use for protecting sensitive and confidential data, however many people are unaware of the capabilities it has. I hope in this post to give a very high level view of what it can do and follow up with some more architectural lower level blogs for those more interested

It is recommended that an RMS install uses a SQL database on a separate machine to store all logging information, Configuration information etc. Once the RMS role is installed on a member server then a SCP (Service Connection Point) is published in AD so that whenever a user tries to protect/consume data using RMS aware applications they know where to go to get certified or licensed for this.

On the client side an RMS Client is required. Operating Systems from Vista onwards include the client in the default installation however for earlier OS’s the client can be downloaded from Microsoft. As RMS is reliant on IIS and is a web based technology the client requires an email address attribute in Active Directory as this is what RMS uses to identify users. This does NOT mean that you need exchange or any kind of email system installed internally.

When a user attempts to consume content for the first time they will receive a machine certificate as well as a Rights Account Certificate to identify them, this will check the publishing licence to see if they have access and what access they have and then send them a use licence based on this. When they first try to protect content they must be connected to the network to receive a Client Licensor Certificate which allows them to publish content, however once they have a CLC they can protect content offline. All these certificates are stored in the users profile in XrML format.

When a user tries to protect content they have two options, they can either set manual permissions, or select from templates that can be created on the Root Cluster. As well as permissions you set conditions, some of these include allowing the ability to print, forward or when you want the content to expire and therefore be inaccessible (Microsoft is currently working towards automatic protection and this is implemented to a degree in SharePoint 2007 and very well in Exchange 2010, will hopefully go into more detail in a later post!)

Currently RMS aware file formats include the Office suite (excluding One Note) and xps although additional IRM protectors can be downloaded from 3rd party sites to support protection for hundreds of file formats, very cool stuff!

See my next post for more information on the RMS Certificates.