You can find this particular post at https://blogs.technet.com/b/rms/archive/2012/04/16/accessing-protected-content-offline-and-content-pre-licensing.aspx.

One of the biggest issues with having to acquire licenses to consume protected content is that connectivity to the licensing server cannot always be taken for granted.

Yes, today we are rarely far from a network connection, at the office and at home, even in public places, and mobile devices with 3G coverage make it easy to be connected most of the time. But what happens when you really are not connected? What if you are on a plane and don’t feel like paying $10 to read an email you already have in your laptop? What if simply there are no wireless networks around?

Even if you have a wireless connection, sometimes it can take a few seconds to download a license, which really makes the experience of using protected content sub-par.

Fortunately AD RMS provides us with quite a few options that make it possible to use protected content while not connected to any network. Let’s review them.

Protecting content

First off, protecting content in Office does not require a connection. Protection is always performed offline, that is without accessing your AD RMS server. Of course, the first time you use IRM in Office you HAVE to connect to the AD RMS server to initialize the client. Check the excellent post by my friend Alexey Goldbergs on the RMS blog for a description of the Client activation process. But after all that is done, you can protect messages all you want without ever contacting AD RMS. The fact that you have a Client Licensor Certificate enables you to create publishing licenses, and the copy of the Server Licensor Certificate you have allows you to encrypt the content without contacting the server (see my previous post on content protection for a description of this process). Online publishing is technically possible as well, but to my knowledge no applications currently use it.

But what about consuming content? Well, there we have a few options.

Consuming self-protected content

Something that we might dismiss as obvious but might not always be is that you can consume without a connection the content that you protected yourself. This is because when you protect a document, you automatically create a license to consume the content for the author, and this license is always cached. Thus, if you protect a document offline you will be able to open it offline.

Using cached licenses

Second, documents (and when I say documents I also include emails in the term) might allow the option to cache licenses issued for them. In fact, this is enabled by default for ad-hoc protection, do not forward emails and for templates. When this option is enabled for a protected document, once a user has acquired a license to consume it, the license will be useable offline during the period specified by the policy in the document.

As I said, the ability to consume a document with a cached license can be limited when protecting the document. This can be done in different ways:

1) When protecting a document in Word, PowerPoint or Excel with an ad-hoc (custom) policy, you can specify, under Advanced options, the “Require a Connection to verify a user’s permission”, which effectively disables caching of the licenses issued against the document. Unless this option is checked, a license issued to consume the document will be cacheable for up to one year.

2) When protecting with Do Not Forward, there’s a registry value (RequireConnection DWORD, under the Office IRM registry keys) which can be set to 1 to disable caching. This does not disable caching on the machine where it is set, but instead configured Office to disable license caching for all documents protected in that machine, so clients consuming those licenses will have to acquire a license every time they open the content. This setting also has effect on Office documents, effectively pre-setting the checkbox indicated in point 1).

3) When protecting with a template, the template itself can indicate if licenses are cacheable and for how long they will be useable before requiring a new one. This is the most flexible option.

But by default licenses are cacheable, meaning that normally you have to acquire a license only the first time you open a document or email. Or maybe not even then, if you are using Exchange Prelicensing.

Exchange Prelicensing

And Prelicensing is the other case I want to describe where you don’t need to connect to an AD RMS server to acquire a license to consume a document.

When someone sends a protected email to you and you are a user of Exchange 2010 or 2007 SP1, the message goes through a few services before reaching you. At one point, it will go through an Exchange Hub Transport server. If the Exchange HT server is running one of those versions and is enabled to use IRM (that is, if the server has the RMS client installed and the service is configured to do prelicensing) Exchange will acquire a license on your behalf and embed it into the message before the message is delivered to an Office 2007 or later client. This is a bit more complicated than it sounds since the server needs to know the users RAC in order to be able to acquire a license for the user. So here’s what happens in Exchange 2010 when Exchange decides it needs to prelicense a message:

1) Exchange obtains the users email address as its identifier. This is easy since, well, it is an email platform and one thing it knows is the email of each user.

2) Exchange calls acquireprelicense on the Licensing pipeline in the AD RMS cluster that was used to protect the message, gives it a copy of the Publishing License and requests a license.

3) AD RMS calls the PreCertification service in the cluster that happens to have the RAC for the user in question. It may or may not be the same RMS cluster - for example, in an environment where Exchange is installed in a resource forest, users and Exchange would most likely be in different forests - so this might be a remote call to another forest. In order to find the corresponding cluster it analyze the user object in question, find out the forest where it is hosted (by checking the msDS-SourceObjectDN attribute in AD) and read the Service Connection Point in that forest to get the RMS Certification URL.

4) With the users RAC at hand, the RMS server will issue a license to it (if appropriate) and send it to Exchange, which will embed it in the email and in every attached document that inherited protection from the email (an email and its attachments all share the same Publishing License, so the same Use License will be valid for all of them).

5) When the email is delivered to the user, the user will be able to double click on the email and have it open without having to acquire a license. The same will be true for any attachments that were protected with the email.

So, unless the Publishing License in the email indicated that the licenses are non-cacheable or the license has expired, the user will be able to consume the email without having to use a network connection to acquire a license at that moment.

Keep in mind that this only works for users of Office 2007 and up (and also for Windows Mobile 6.x) connected to an Exchange server running Exchange 2007 SP1 or later (also, keep in mind that the process for prelicensing described above is the one used in Exchange 2010, Exchange 2007 uses a slightly different sequence).

Automatic License Fetching

Users of Office 2003 should not despair though, as that version has a capability called “License Pre-fetching” which is more limited than Prelicensing but still quite useful. Basically, License Pre-fetching occurs after an email has been delivered to a client whenever the client has some spare cycles after a full send/receive cycle. This will acquire licenses for all protected messages that have just been delivered without the user opening the messages, to the messages are ready to consume whenever the users clicks on them. It is different from Prelicensing in that the licenses are requested by the client, so the client has to have connectivity to the RMS client at the time of downloading the messages for this to work.

This capability is enabled by default in Office 2003 and can be disabled via the settings described in this article.

So what all this means is that in most circumstances users trying to consume protected content will be able to do so even if they are not connected to a network. It also means that if you are connected to a slow or expensive network you will not have to wait or pay for the traffic to acquire a license in any of the cases described above.

You can find this particular post at https://blogs.technet.com/b/rms/archive/2012/04/16/licenses-and-certificates-and-how-ad-rms-protects-and-consumes-documents.aspx.

In a previous post I discussed how to deploy the back-end components of the AD RMS infrastructure in a way that’s fault tolerant, or at least fault tolerant enough for the demands of AD RMS.

But of course, all that is not too useful unless the AD RMS servers themselves provide the necessary availability. Let’s discuss now how to deploy AD RMS in a way that provides fault tolerance.

First, we need to discuss what happens when the services provided by AD RMS are not available.

The AD RMS servers perform a few functions, the most salient ones:

• Machine activation: the process of configuring a computer to enable it to securely process AD RMS-protected content.
• User activation: the process of issuing certificates to the user so it can author and consume protected content. These are two separate functions actually, since the user is activated in two separate operations, one through which the user acquires its identity certificates for the purpose of authenticating in the AD RMS environment, another one through which the client acquires a certificate that will enable the user to protect content. But for the purposes of this discussion we can consider them just one step.
• Protecting content online. AD RMS provides the capability to perform document protection by talking to a server to create the necessary publishing license. But in practice this functionality is not used, at least not today. All existing applications perform RMS protection in an offline fashion, without contacting RMS for each individual protection action. As long as the user is activated, protection can be performed without contacting the server.
• Acquiring use licenses. This is necessary to consume protected content. But since most use licenses can be cached, a user only needs to acquire a use license for content that he or she hasn’t accessed before, content that wasn’t prelicensed by Microsoft Exchange or content whose use license has been expired or is marked as non-cacheable.

So the first conclusion is that when the AD RMS platform is down or unreachable, we can still perform some actions. We can consume content that we accessed previously for which we still have a valid license. We can consume content that was pre-licensed by Microsoft Exchange. We can protect new content, or reply to existing protected email.

But there are some things that can’t be done when the AD RMS infrastructure is unreachable. We can’t activate new users, or existing users in new devices. We can’t renew existing users certificates when they expire, which typically happens after one year. Perhaps most importantly, we can’t acquire licenses for new content for which we don’t have a valid use license already.

So we need to find ways to make our RMS infrastructure more resilient.

AD RMS provides the capability to deploy Licensing-Only servers. These servers are also called sub-enrolled servers are somewhat similar to a child Certification Authority in a PKI, since their Server Licensor Certificate is signed by the “parent” Certification RMS server (which is, for that reason, also called the Root RMS server). Licensing-only servers are similar to certification servers with two big exceptions. The first one has already been mentioned: the Server Licensor Certificate for a Licensing-Only server is not self-signed like that of a Certification Cluster, but it is signed by the “parent” certification server. The other one, more important, is that a Licensing-Only server, as its name implies, can only perform licensing functions. That is, it is not capable of performing the Certification functions, which basically consist on the issuance of machine and user identity certificates (SPC and RAC respectively, see my second post in this blog for more information). So it depends on the identity certificates issued by its parent Certification Server for validating users and for encrypting communications with those users.

There’s always a temptation to deploy Licensing-only servers to scale up an RMS deployment or to provide fault tolerance, but this doesn’t work because of a big reason. When you protect content with a licensing-only server, the content is encrypted (indirectly) with that server’s Server Licensor Certificate public key. Thus, only that server (or another server that shares the same SLC) will have the necessary private key to decrypt that content. Conversely, content protected with the Root server cannot be consumed by asking a license from a Licensing-Only server, since you need the private key of the root server in order to decrypt that content.

So, a Licensing-Only server is no good to consume content protected with the root server, and is thus no good to provide fault tolerance or redundancy to an existing RMS server. What are Licensing-Only servers good for? Well, that’s food for another post.

So what you need in order to provide redundancy to an existing RMS server? You need a server that has the same Server Licensor Certificate, or that at least has a copy of it. There are two ways in which that can happen.

The first one is if you install a new server and tell it to be part of the same cluster as the original server. This is an option during installation. You tell Setup to connect to the existing database of an AD RMS server, and it will add this node as a member of the AD RMS cluster. What’s more important, it will not create a new Server Licensor Certificate, but it will share the existing one (assuming you are not using a Hardware Security Module to protect the server keys, you will be prompted for the password used to encrypt the SLC private key in the RMS database of the original server).

After you have deployed a second node in an RMS cluster (or any number of additional nodes) you still don’t have redundancy, since your users will still be contacting the original RMS server for a license when they need it. In order to be able to consume protected content from either of the two (or more) nodes in the cluster, you need two things:

1. Load Balancing. You need some hardware or software that balances traffic to any active node in the cluster, instead of going always to the same one.
2. An alias. Since clients are going to be talking to the URL stamped in the protected documents to acquire a license, you need to map that URL’s server FQDN to the load-balanced IP address. This is why it is important never to configure the RMS URL to refer to the physical name of the first RMS server. Always use a DNS alias (typically a manually configured A record with a “fantasy” name such as “Rights” or “RMS”) for your cluster URLs when you install the first server. And use one that’s valid externally, even if you won’t be making the server accessible externally, just in case you change your mind in the future.

For Load Balancing you can use any of the common load balancers. You can use a hardware load balancer, which in many cases provide some niceties such as service failure detection and geographic awareness, or you can use Network Load Balancing, which is a component in Windows Server. While NLB does the trick and its’ free, it can be sometimes difficult to deploy if you don’t have the right network hardware (for instance, in many configurations, you will need two network cards on each server) and it is somewhat tricky to use in a virtualized environment, sometimes requiring the virtual switches in the virtualization hosts to be configured in certain ways. So if you are running physical servers and your networking infrastructure is somewhat modern, you should be able to use NLB without problems. But if you are virtualizing servers, or have some network hardware that might not have support for multicast traffic or doesn’t deal well with MAC address changes, you might be better off by using a hardware load balancer.

So is that all? Just install a second RMS server as part of the cluster, load balance it with the first one and you are all good? Well, actually yes. That’s all that’s needed to have a redundant RMS cluster.

Of course, you can then decide to do some interesting things, such as putting different RMS nodes in different locations and load balance between those locations (another advantage of using an external load balancer, since NLB is not too easy to configure in a geographically distributed fashion). Since AD RMS is not too DB-intensive and most access to the DB is asynchronous, it wouldn’t cause too much trouble to distribute the RMS servers this way, but keep in mind that your servers might refuse to boot if they can’t connect to the RMS DB due to excessive latency or network reliability problems, so make sure you have a decent connection between your different datacenters (according to my tests, no significant packet loss and a latency of less than 70ms) if you want to do something like this. If you do want to go the geographically distributed way to provide datacenter redundancy, you can put a bunch of RMS servers in each datacenter, put the RMS DB in one side and a stand-by DB server in the other one (see my previous post) and load balance with an external load balancer between the two sets of nodes. That way:

• If one node fails, the other nodes will handle the load.
• If the active database fails, you can quickly failover to the second database. This will involve activating the passive DB server (with the latest copy of the data), changing the DNS alias (or setting up a hosts file in each RMS server if changes in DNS are slow in your organization) and then recycling IIS in the RMS servers to force them to see the change. This might all take a few minutes, maybe a few hours, but since the RMS servers will continue to issue use licenses while you do this, most users shouldn’t see the impact.
• If a whole datacenter fails, you can use the remaining RMS servers and DB server to continue operating. Depending on which side fails, this might be more or less automatic, but again users shouldn’t see much of an impact.

So if you are really worried about service availability, this design should provide you with very good availability at a reasonably low cost.

I mentioned before that there’s another way to make the private key of a server available to another server so it can issue licenses to content protected by the first. This is by actually exporting the Private Key from one server and importing it into another one. Actually, you need a bit more than that, since the second server will also need a copy of the full SLC and of all the RMS templates in the other server in order to be able to license content for it. Fortunately, this is all automatically done when you export/import a Trusted Publishing Domain. By exporting a TPD from one server and importing it into another you can enable the second server to issue licenses to content protected by the first server. But while this is a valid way to provide some sort of redundancy to your environment, installing additional nodes to the original cluster is usually much easier and more functional, so only in very specific cases with particular requirements (such as complete physical isolation between environments, imagine if you are deploying AD RMS in a submarine) this makes sense as a solution.

Trusted Publishing Domains have their uses in other situations, but I will discuss that in another future post.

You can find this particular post at https://blogs.technet.com/b/rms/archive/2012/04/16/ad-rms-redundancy-and-fault-tolerance-part-1.aspx.

A very common question when deploying a service in the enterprise is how to make it resilient. In the case of AD RMS this typically means setting up the infrastructure so server failures don’t affect the user’s ability to consume content. In this post we will cover the back-end side of the solution, and in a future post we will discuss the making AD RMS servers themselves resilient.

The first thing to consider when designing AD RMS for high availability is that, once activated, clients in many cases don’t need to access the AD RMS server infrastructure for some of the RMS-related operations they might want to perform. Content protection with Office applications is always performed offline at the clients, so even if a client can’t reach an AD RMS server, the user will be able to protect a document or email without problems. When protecting a document, a client will also issue itself an Author license, which will allow the user that has just protected the document to continue consuming the document without having to contact the server, even after closing it and reopening it.

Users consuming content protected by others might also be able to make use of the content without having to first contact the server. That depends on several factors: if they have acquired a license before, if the use license is cacheable and if the license is still within its validity period. The possibility of caching a license is defined either in the template used to protect the document or the setting to “Require a connection to verify a user’s permission” that can be used when manually protecting a document (this setting can also be pre-set at the author’s machine via registry overrides). Cacheable licenses are valid for up to one year but the maximum duration can be specified in a template.

A user might have acquired a license before if the document (email or attachment) was pre-licensed by Microsoft Exchange. In these cases, Exchange will acquire a license on behalf of the user before delivering the email and any attachments to the client, so the user won’t have to get a license at the time the content needs to be consumed.

In any of these cases when the user has a valid license in the machine to consume the document, the client won’t need a connection to the AD RMS server in order to use the document, so whether the server is working and accessible or not won’t have an impact in the user’s ability to consume the content.

But for the initial consumption of a non-prelicensed piece of content or for consuming a document after any previously acquired license has expired, the client will have to contact the AD RMS server. A client will also need to contact the AD RMS server the first time it is used on a machine, or when it is time to renew the client machines or the users certificates, which typically last one year.

Since those are not all that uncommon situations you should in most cases ensure your AD RMS infrastructure is highly available.

Let’s review what components need to be made highly available for AD RMS to be.

Besides the client components, the key elements that make AD RMS tick are the AD RMS servers themselves, the RMS Database and Active Directory. It should be fairly obvious that any AD infrastructure needs to be made highly available, and most AD deployments are made with that in mind. One thing that is often missed though is that an AD server will only talk to an AD Global Catalog server for tasks such as group expansion, and that means that the AD RMS servers have to always have access to an AD GC in order to work effectively. While the AD Caching database that’s part of the AD RMS database infrastructure can provide some ability to continue operation when a GC is not available, it is not substitute for a GC located close to the AD RMS servers, and since any DC might be out of service at some points, you should have at least two GCs in the same network or site as the AD RMS server.

The next element to consider is the AD RMS Database. AD RMS uses the database for multiple tasks, including:

• Storing the server/cluster keys and configurations, including Rights Policy Templates.
• Caching information from AD.
• Storing logging information about activities performed on the cluster, such as issuance of licenses.
• Storing and retrieving copies of the user’s Right Account Certificates.

The first thing to note is that AD RMS retrieves the server’s configuration and the cluster keys when the service is started. So once an AD RMS server is up and running it will continue to work even when the database is unreachable.

Also, most of the write operations between an AD RMS server and its database server are done via the intermediate agent of Message Queuing running on the AD RMS host. That means that if the DB is not available at one point AD RMS will continue to perform these operations while keeping the information in a queue in local memory until the database becomes available again, and it will dump the data into the database whenever it becomes available again. This means that AD RMS can continue to work for long periods of time without access to the AD RMS database and logging information will continue to be gathered.

Regarding the caching DB, AD RMS will only use it if it is available. If the RMS DB is unreachable, AD RMS will try to contact a Global Catalog for fresh information about users and groups, and other than a potential load increase in AD this shouldn’t affect performance of the service.

Which leaves us with the last point in the list above: storing and retrieving copies of the user’s RACs. This is the only recurrent frequently performed operation that needs to be performed with access to the RMS Database. AD RMS needs access to the RMS DB every time a user is activated on a new machine in order to check for a pre-existing RAC and in order to save a RAC when one is created. It also needs access to pre-existing RACs when Exchange needs to pre-license content, since in order for Exchange to request a use license on behalf of the user the server needs to know the public key of the user it needs to be issued for.

So what does this all mean?

It means that if the AD RMS database fails, AD RMS will continue to operate almost normally, with only partial loss of functionality. What functionality will be lost?

• AD RMS servers won’t be able to be booted or rebooted while the RMS Database is unreachable.
• New user activation won’t work until the database is back in service. That is, a user that has never used AD RMS on a machine won’t be able to activate the machine and use AD RMS until the RMS Database is reachable.
• Exchange pre-licensing will not work during the DBs downtime. Still, email content will be accessible with a normal licensing request when opened as long as the AD RMS servers are available at consumption time to issue a license.
• Changes in configuration such as creating or modifying RMS templates or changing exclusions won’t be possible with the DB inaccessible.
• Some operations, such as adding users to a revocation list, can be hampered in some cases by the DB not being available, since revoking a user’s RAC would need a copy of the RACs GUID, which is most easily obtained from the database.

Of these, the first two should normally be the limiting factors with the other issues being generally tolerable in most cases for short periods of time. Which means that if an AD RMS Database is down or inaccessible for a few minutes, or in many cases even for a few hours, most users won’t notice a problem and will continue to work mostly unaffected.

Does this mean that the AD RMS Database is not important? No! It is of uttermost importance to the AD RMS system. If the database is gone for good, so is your protected data, thus the RMS DB needs to have some reasonable level of protection from failure. But it does mean that the Database’s continuous availability is not as essential as it would be for many other applications relying on a database.

So let’s review some of the most obvious alternatives for protecting the RMS DB against failure.

• Setting up the DB on a Failover Cluster
• Providing a “warm standby” database via Log Shipping or some other similar mechanism
• Having a good (and functional) backup and restore policy

A Failover cluster seems like a good option at first glance, but when we look at it in more depth we can see it provides the sort of protection that AD RMS doesn’t really need. The strength of a failover cluster is that it provides almost immediate (sub-minute) recovery for hardware, operational or application failures, and it provides the ability to perform some types of server maintenance such as server patching without affecting the service. But a failover cluster doesn’t provide much protection against data-centric failures, such as a storage unit failure or an operational or software error that could corrupt the data. Granted, these events are very infrequent, or at least they should be, but that is the sort of event that would take a long time to recover. Since AD RMS isn’t seriously affected by brief interruptions in the database, having instantaneous recovery of the DB provides only marginal value, whereas something that protects the service against longer interruptions would be highly recommended. So we conclude that using a failover cluster for hosting the AD RMS DB is not the most efficient use of resources, as it is an expensive configuration that adds little value, and doesn’t protect us against the type of events that should concern us most.

A warm standby provides a different type of protection. While they can in theory recover the DB to a working state in a few minutes, most of these solutions require some manual intervention so it is a good assumption that up to one hour, sometimes more, could pass before the DB is fully recovered form a serious failure. But that’s generally not a problem for AD RMS. Users can typically go for one hour without Exchange pre-licensing as long as they can acquire a license when they want to consume the content. New users or users setting up a new machine during one specific hour when the service is operating on contingency mode shouldn’t be that many, and they will typically have other issues during the first few hours after installing the machine that not being able to activate AD RMS at the first try, while a nuisance, shouldn’t be a big problem. And during a period when you are trying to recover the AD RMS form a catastrophic database failure, not being able to create AD RMS consumption reports or modify policy templates should be the least of your concerns.

So we can see that this is a valid and very useful configuration that can protect us against the type of problem we should be concerned about at a generally lower cost than a failover cluster.

But so will a good backup strategy. Unless you have a backup solution that cannot recover a server within a few hours, you might be able to do quite well without a hot or warm standby solution. Of course, your backup system needs to be a well-oiled process, your backups need to be tested and you have to have some sort of hardware spares to rebuild the DB when needed. It is troubling to see how many companies have a thorough backup solution in place but don’t have a good recovery plan for when things fail. But as long as you can trust that your backups work and that you will be able to recover them to working hardware within a few hours (and maybe even apply your last transaction logs from the original database if the data is still accessible and you have the DB set to full recovery model) you should be good with that. AD RMS will continue to run after reconnecting to the DB and most users shouldn’t even notice the interruption.

One caveat here: in order to be able to recover the AD RMS DB in another system, you will need to have configured your AD RMS database to use a DNS alias to refer to the database server. This is a general recommendation that should always be followed with AD RMS: don’t call the Database server by its proper name, use an alias (CName or manual A record in DNS) during setup to point AD RMS to the DB server. You will regret it if you don’t as recovering from a server failure and maybe even during future upgrade and migration processes. And the same applies to the AD RMS servers themselves: always use an alias, and not the server’s own names for the AD RMS server URLs. This will avoid some grief in the future, guaranteed.

So now we know what we need to do to have an AD RMS database and a directory server that is resilient enough to provide support to an AD RMS server infrastructure that’s highly available. So what about the AD RMS servers themselves? Well, this post is long enough already, so let’s leave that for my next post.

You can find this particular post at https://blogs.technet.com/b/rms/archive/2012/04/16/licenses-and-certificates-and-how-ad-rms-protects-and-consumes-documents.aspx.

In my last post I described the high-level AD RMS infrastructure components. I am now going to describe how AD RMS protects documents and how it is used to consume documents.

At a high level, AD RMS works along with RMS-enabled applications to allow users to create and consume protected content. Protection works by encrypting a document, creating a policy and stamping it all together, along with a certificate identifying the author and some other information in a single file. Consumption works by using the users identity certificate and the policy stamped in the document to request from the AD RMS server a license to decrypt it and use it.

Let’s dig a little bit into what certificates and licenses are for AD RMS and how they relate to each other.

AD RMS Certificates and Licenses

In AD RMS, every entity that interacts with the system is represented by a certificate.

Each AD RMS server cluster is represented by one certificate, the Server Licensor Certificate, or SLC, which in Windows Server 2008 AD RMS and later is a self-signed certificate. The private key corresponding to this certificate is used by the server to sign many other identity certificates used in the system, and it is also used by the clients to encrypt other materials for the server to decrypt, as will be discussed later.

Client machines themselves have a Security Processor Certificate (SPC), which identifies each machine and allows the machine to encrypt other elements stored locally in the computer.

Users are identified by two certificates. One which is utilized to identify users against the AD RMS servers, and another one which is used to identify a user that has protected a piece of content.

The first one is called the Rights Account Certificate (RAC) but might also be referred by its old name the Group Identity Certificate (GIC). When a user first authenticates against the certification URL of an AD RMS cluster, the user is issued a RAC or GIC, and then it uses this certificate for any future identification needs to the system. The RAC is also used by the server to encrypt licenses being sent to the user, and by the client to sign the other user certificate mentioned above, the CLC or Client Licensor Certificate. This one is obtained from the RMS licensing pipeline during client activation, and it is used to sign the Publishing Licenses embedded into any encrypted document.

Which brings us to the Publishing Licenses: these are also certificates but are used not for identifying a user but to express rights over a document. A Publishing License is basically a list of rights, like an Access Control List, that expresses a list of subjects (normally identified by their email addresses) and their rights (View, Edit, Print, Copy, etc.). The PL is stamped into a protected document and it is encrypted with the Server Licensor Certificate’s public key (so only the server can decrypt it) and signed with the user’s Client Licensor Certificate (so everyone can view who wrote it).

Finally, there’s one more commonly used license, also in the form of a certificate: the Use License. This is a certificate expressing the rights one user (the one requesting a license) has over one document. It also contains the encryption key used to encrypt the content of the document, but more on this later.

It must be highlighted that all these certificates and licenses are not your standard X.509 certificate. An X-509 certificate basically attests one claim about one subject, but does not have the flexibility to express complex lists of rights like AD RMS needs. That is why Microsoft chose the XrML certificate standard to express all these certificates. All AD RMS certificates and licenses are in the XrML format.

To summarize, if not to clarify, you can take a look at the following diagram, which represents the relationships between all these certificates:

Don’t worry if you didn’t understand what all these certificates and licenses mean. The main point here is that you understand that all these certificates exist and that they all depend on each other. It will all become clearer as you see how they work together.

How AD RMS protects and consumes documents

Let’s say that you are a user who wants to protect a document with AD RMS. The first thing you have to do is to get your client bootstrapped and initialized. I’m not going to cover that process in this post, let’s just assume the client is already bootstrapped at this point, and that the user already has a RAC (Rights Account Certificate) a CLC (Client Licensor Certificate) and a copy of the Server Licensor Certificate (SLC).

The user who wants to protect a document only has to click on one button (such as a Rights Policy Template in the Office menu or the Do Not Forward option in Outlook) and the application will automatically perform a series of steps in order to get the document transformed into a protected document. The series of steps are as follows:

1. The client creates a random symmetric encryption key (128 bits as of this writing). Let’s call that the Content Key.
2. The client takes the body of the document it wants to protect and encrypts it with the Content Key by using the AES protocol. It ends up with an encrypted object with is an AES-128 encrypted version of the original document, and it still has the Content Key used to encrypt it.
3. The client has a local copy of the Server Licensor Certificate with its public key. It uses this public key to encrypt the Content Key. Which means that this encrypted Content Key will only be readable by the server whose SLC was used.
4. The client then creates a list of rights expressing who can do what on the document. This list depends on the action the user performed to protect the document. For example if the user clicked on the Do Not Forward button in Outlook, the list will include all the intended recipients of the email, and for each the rights will include View but not Copy or Print. The logic is slightly different if the document is protected with a Rights Policy Template as the list of rights will be replaced with a reference to a predefined list in the server, but the process is more or less the same.
5. After creating a list of rights, the client will take this list and express it in XrML. Then the client takes the encrypted Content Key (encrypted with the SLC), the public part of its own CLC and the list of rights created before, encrypts them with the Server Licensor Certificate's public key along with some other information (such as the URL of the Licensing URL that should be used to acquire a license to consume the document) and builds what we call the Publishing License with them. This PL is then encrypted with the Server Licensor Certificate's public key, so only the server will be able to decrypt it. The client also takes the private key from the user’s Client Licensor Certificate and signs the encrypted object.
6. Finally,all this is embedded to the original content encrypted with the Content Key to create a protected document. The content key is also stored encrypted with the CLCs public key, so the author can also decrypt the content without having to acquire a license.

And that’s it. From a series of certificates, an unencrypted document and a list of rights, we have created an AD RMS protected document. See how easy it was?

It is actually slightly more complicated than that, as the client also grants Owner rights to the author, and issues itself a license to consume the document without contacting the server, but that’s just details. The important part is what was described above.

Of course we now have to consume the document. For that we have a just very slightly more complicated process, which in this case involves the server.

So assume the author sent the document to an authorized recipient via whatever means they want to use. Let’s say the protected content was an email which the author sent to the intended recipients. Again let’s assume that the recipient was previously activated and initialized in the AD RMS environment so the user already has a RAC and all the other necessary elements configured.

Now that the recipient has a copy of the protected document or email, he or she clicks on it and it opens on screen with some restrictions enforced. But before that happens, the client has to work with the server to consume the document. Let’s see what they do to get that done.

1. It all starts with the client taking the encrypted document and extracting the signed and encrypted publishing license, the encrypted content key and the author’s CLC and sending it to the server indicated in the document as part of a request for a Use License. Notice how the content of the document is NOT sent to the server, even in encrypted form.
2. As part of the request for a license the client also sends to the server the public part of its own RAC, the user’s identifier.
3. We mentioned before that the author had encrypted the document with a symmetric content key, and that it encrypted that content key with the server’s SLC public key. Since the server has the private part corresponding to that SLC, the server can use that to decrypt the encrypted content key and obtain the original, unencrypted version of the content key. This content key is good to decrypt the body of the encrypted document, but since the server does not have the body of the document, nor it cares about it, that’s not where it all ends.
4. The server then extracts the Publishing License from the client’s request and evaluates it against the requesting user’s identity. If the server decides that the user doesn’t have rights to the document, then it declines the request at this point. If the user does indeed have rights to consume this document, then the server proceeds with the next step.
5. After determining that the user does have rights to the document, the server takes the information from the Publishing License (the list of rights) to create a specific list of the rights the requesting user has on the document. The list will look like “user X has Read rights”. The server also takes the decrypted content key and encrypts it with the users RAC public key. The requesting user will now be the only one that will be able to decrypt this content key. The server takes these two things together (the re-encrypted content key and the list of rights for the user) and uses them to build a use license, which is sent to the user as a response to the users request.
6. At the client, the encrypted content key is extracted from the Use License and decrypted by using the users RAC private key. It must be noted that the user never sees the decrypted content key, and it is only the client application, under the protected environment of the RMS Client’s lockbox, that ever gets a copy of the key.
7. The client application, with the decrypted content key decrypts the body of the document and uses the rights information from the use license to display the document on the user’s screen while enforcing restrictions according to the policy that has been defined.

And that’s all there is to it. The authorized recipient of the document can now consume the protected document in a controlled way. Again, this is slightly simplified and we have left out all the steps to get the client activated, plus we have omitted some concepts like content pre-licensing, but the main logic is there.

So now you understand how AD RMS is used to protect and consume documents and how all the keys mentioned before take part in this process.

With this now behind us, I will devote my future posts to explain how to design solutions based on AD RMS for typical and not so typical scenarios.

 You can find this particular post at https://blogs.technet.com/b/rms/archive/2012/04/16/ad-rms-infrastructure-concepts-part-1.aspx.

Hello and welcome to my blog!

This blog will be used to present AD RMS architecture concepts, as well as other relevant topics I might decide arbitrarily to discuss.

As you will learn from reading my blog I am quite passionate about AD RMS and all things Information Protection in the Enterprise. I have been working with this technology for several years now and I think it should be part of the security, compliance and risk management strategy of any enterprise dealing with sensitive information.

As I mentioned above, I will be dealing mostly with architectural aspects of designing and deploying Information Protection in the enterprise, and not as much on other aspects of the technology, such as how to make it work in different scenarios. For that you have some excellent content in Jason Tyler’s blog and the blog from the AD RMS product group at Microsoft.

While I will be discussing high-level design aspects in most of my posts, let me start with something somewhat different: how AD RMS works. It should be obvious that doing an adequate design for an AD RMS solution will be much easier if you understand what’s going behind scenes, so I will be dedicating the rest of this article to provide some background about AD RMS infrastructure components, and in my next post we will exploring AD RMS certificates and licenses and how it all works together.

AD RMS infrastructure

AD RMS, like any IT service, relies on some infrastructure to work. In the case of AD RMS there are several components that work together in order for the solution to deliver a useful service. The most relevant ones are:

· AD RMS servers and clusters

· The AD RMS SQL Server database

· Active Directory

· The Rights Management Services client and RMS-enabled applications in the client

· AD RMS-integrated server applications

While there are other components that work along with AD RMS to make the whole thing work, those should cover the most important ones needed to understand other topics in this blog.

AD RMS Servers and Clusters

AD RMS provides its services to other elements as a web-service, and it is thus hosted inside Internet Information Services in a Windows Server. It normally runs over HTTPs (though running it over HTTP is also possible) providing a few web service operations that can be consumed by clients and services to perform information protection and consumption tasks.

AD RMS actually not only uses IIS in the hosting server, but it also uses Message Queuing to interact with the AD RMS database which we will be discussing later. That ensures that operations in the AD RMS services that need to send data to the database can be performed asynchronously and that in turn increases performance and resiliency of the database services.

Multiple AD RMS servers are typically joined together forming AD RMS clusters, which are basically collections of identically-configured AD RMS servers connected to the same AD RMS database and working together to resolve requests from other clients and servers. In an AD RMS cluster it doesn’t matter which server resolves a request, so the requests are typically load balanced through a mechanisms such as Network Load Balancing in Windows or an external load balancer.

AD RMS Database

As stated, a group of identical AD RMS servers form an AD RMS cluster. Servers in a cluster don’t host persistent service-related data in their own disks. All configurations, logs, persistent status and operation data and caches are actually hosted externally to the AD RMS servers in a SQL Server database called the AD RMS Database. That way, all servers share a common configuration and if a server fails users can continue to work through other servers in the cluster.

There’s actually not a single AD RMS database but three. Those three databases are typically hosted in the same server and are:

· The AD RMS Configuration Database, which hosts all the configurations defining the behavior of the cluster such as its URLs and caching behavior, as well as copies of some certificates and other items needed to keep the service running. It typically also holds the core certificates and keys for the AD RMS servers themselves.

· The AD RMS Caching database, which is used to cache frequently used data about the users and groups defined in Active Directory, in order to avoid impacting the performance of AD every time the service needs anything from the directory.

· The AD RMS Logging Database, in which AD RMS puts information about transactions that have been performed by the service. This information is not used by AD RMS for anything other than for reporting.

Active Directory

AD RMS uses Active Directory to authenticate users of the system within the forest where it is installed. It also uses AD to obtain information about the email address of the users, which is used as the users’ identifier thorough the system, and to obtain information about group membership when the rights assigned to a document refer to a group instead of an individual user.

As stated above, AD RMS caches data from AD in the AD RMS AD Caching database in order to avoid hitting the domain controllers too hard.

Client-side components

AD RMS typically works together with client-side components to perform the encryption, decryption and policy enforcement tasks.

The main client-side components in an AD RMS system are the Rights Management Services client and AD RMS-enabled applications.

The Rights Management Services client, which comes installed as part of Windows Vista SP1 and later and in Windows 7, and that can be installed in earlier versions of Windows, deals with all the key management, communicates with the AD RMS services in requesting licenses and providing certificates and communicates with the client applications to perform the encryption and decryption of content. It also provides a secure environment for all these tasks to occur, helping prevent tampering and potential key disclosures.

AD RMS enabled server-side applications

While most AD RMS-related operations are performed between the clients and the AD RMS servers, having some level of integration between certain server-side services and AD RMS can provide for a better user experience and more efficient IT services. For example, Exchange Server 2010 can acquire licenses for content on behalf of the users so users don’t have to wait for a license to be acquired when they open email they have in their inbox. It also provides the ability to create and consume protected content in the browser when using OWA, along with other capabilities.

In my next post I will describe how certificates and licenses form part of the AD RMS process and how all these components work together in detail.