The Evolution of Microsoft’s Rights Management Services (Part 1)

If you would like to read the next part in this article series please go to The Evolution of Microsoft’s Rights Management Services (Part 2).


It’s been a while since I last wrote about Rights Management Services (RMS) for When I looked back through my files to review that last article, I was surprised to see that it was published in September of 2003. That was exactly ten years ago; time goes by quickly in our fast-paced IT world.

The article, of course, was in reference to RMS in Windows Server 2003. Since then, RMS has gone through a number of changes and improvements, first in Server 2008/2008 R2 and then in Server 2012. In July, Microsoft released a preview of the latest and greatest version of RMS, which runs on Windows Azure.

It’s time for us to play catch-up, beginning with the name, which in Windows Server 2008 morphed from Windows Rights Management Services to Active Directory Rights Management Services (AD RMS) and that name stuck for Windows Server 2012. The new cloud-based version of RMS is currently being called Azure Rights Management Services or the Microsoft Rights Management Suite in this preview stage.

Brief overview of RMS from 2005 to 2012

Microsoft created the rights management service to extend protection of documents, email and web pages from unauthorized copying, printing, forwarding, editing, deleting, etc. It gives the creator of content more control over what happens to that content when they share it with others. RMS didn’t come with Windows Server 2003; it was actually released as an add-on in 2005.

It’s not a replacement for access controls, encryption and other data protection technologies; it’s designed to work in conjunction with them. You can protect a file by encrypting it, but if you share it with someone else, once that person decrypts and accesses it, he/she can copy, change or share it with others whom you didn’t authorize. RMS can even make your recipient’s copy of the file “self-destruct” after a specific period of time, so the timeframe for access is limited.

RMS does not completely protect the information. The recipient could still, for example, open the file and take a picture of the screen with a cell phone, and then share that with someone else.

If you think about how digital rights management (DRM) works, RMS works in the same way in that the protected file is encrypted and signed and then bound to a Publishing License. The AD RMS client software on the file owner’s machine can specify the restrictions to be placed on the file (i.e., what things the recipient isn’t allowed to do with it).

When the recipient receives the file, he/she has to have an end-user license for the content in order to be able to open it. The AD RMS client software requests and obtains this license from an AD RMS server.

Rather than setting the restrictions individually on each file every time, you can use rights policy templates so that, for example, you could have a specific set of restrictions such as “cannot save, copy or print” that could be applied by using the template. The templates that are available are stored in a database on the AD RMS server.

Speaking of client software, AD RMS works only with applications that are designed to be rights management enabled. This includes a number of Microsoft applications, such as Office programs (Word, Excel, PowerPoint, Outlook), SharePoint and Exchange. Microsoft also has a software developers’ kit (SDK) that can be used to create your in-house applications so that they’re RMS-enabled. You can download it from the MSDN web site.

AD RMS in Windows Server 2008

One big change that occurred in Windows Server 2008, although with the name change, was the positioning of AD RMS as a server role. In Server 2003, you had to install RMS from an .MSI file and then it ran as a web service on IIS 6.0/ASP.NET. With Server 2008, it still runs as a web service on top of IIS, but things have changed so that you can install the AD RMS server role by simply selecting it from the Select Server Roles page in the Add Roles Wizard through Server Manager. This made it much easier to deploy a rights management server.

Not that the process became simple. Note that you still need IIS installed, along with Windows Process Activation Service (WPAS) and Message Queuing. You still need a database but you can use the Windows internal database to host the AD RMS databases if you have a single-server installation rather than an AD RMS cluster. In addition, if you will use an SSL encrypted connection for your AD RMS cluster (and you should, for best security), you will need to import an existing SSL certificate. You also have to register the AD RMS service connection point (SCP) with Active Directory.

It wasn’t just the installation and setup process for RMS that changed in Server 2008, though. In Windows Server 2003 RMS, you had to use a web interface to manage the RMS server. Server 2008 provided for performing AD RMS administration tasks through a Microsoft Management Console (MMC) in the same way you manage other server roles that are built into the operating system.

For enterprise networks, another valuable added feature was the integration of AD RMS with Active Directory Federated Services (AD FS). This made it easier to use RMS protection across a federation for sharing protected files with external users. In this case, AD RMS directs requests to the federation server, which authenticates the user via Active Directory and issues a security token that the single sign-on (SSO) agent validates and then identifies the user to the AD RMS server. For more information about how this works, see Using Active Directory Federation Services with AD RMS on the TechNet web site.

Microsoft also removed the requirement that the server licensor certificate (SLC), which is used to issue certificates, be signed by the Microsoft Enrollment Service. What this means is that companies no longer were as dependent on that Microsoft service in order to deploy an RMS server. Windows Server 2008 comes with a server self-enrollment certificate that can be used to sign the SLC.

AD RMS in Windows Server 2012

In Windows Server 2012’s implementation of AD RMS, the method of management hasn’t changed. However, there are some differences in the setup process that make it easier to configure RMS to work with a SQL server. You no longer have to use an administrator account with local admin rights on the SQL Server when you install AD RMS. However, the AD RMS installer account does need to have sysadmin permissions on the SQL server. More versions of SQL Server are now supported as well. You might have guessed that SQL Server 2012 support would be added, but Microsoft has also added support for SQL Server 2005 SP3, 2008 SP3 and 2008 R2 SP1.

A very welcome change in Windows Server 2012 AD RMS is the ability of administrators to deploy AD RMS on remote computers, and you can do this either through the graphical Server Manager interface or via Windows PowerShell, which is quickly becoming the admin tool of choice for many Windows IT pros.

Of special interest to security folks who may be upgrading from Windows Server 2003 or 2008 is the new support for simple delegation for AD RMS. This actually came along in Windows Server 2008 R2 and makes it easy to delegate the same access rights for content that are assigned to management personnel to their assistants. Something that is to Windows Server 2012 is the ability use PowerShell to enable simple delegation.

Another security-related change in AD RMS in Windows Server 2012 is support for stronger encryption and stronger (longer) cryptographic keys for hash functions (now 256 bit as opposed to the 160 bit keys that were used previously). This improvement is particularly important when it comes to complying with standards such as the National Institute of Technology (NIST) standards regarding computer security and encryption that recommend 2048 bit RSA keys (NIST Special Publication 800-57). Using strong encryption involves upgrading your AD RMS servers to cryptographic mode 2, which can be done either via the MMC or PowerShell.

The Windows Server 2012 AD RMS server role is now supported in Server Core installations. This is good news for security-minded admins because Server Core, by removing many of the services that are installed in the regular full installation of Windows Server, reduces the risk because there are fewer services and applications that are normally included in the operating system (such as Internet Explorer) and thus fewer vulnerabilities that attackers can exploit. Server Core was first introduced in Windows Server 2008. However, AD RMS, along with some other server roles that were available in the full installation (Certificate Services, AD FS, Network Policy and Access Services, Terminal Services and a few more) was not supported in the Windows Server 2008 Server Core installation. Now it is, although the Federation Support role for AD RMS is not supported on Server Core installations.

Another change to Windows Server 2012 is that if you decide you prefer to manage your rights management server via the graphical interface, it’s now possible to switch your Server Core installation to a full installation and back, without reinstalling the operating system.


In this, Part 1 of our series on the evolution of Active Directory Rights Management Services, we provided an overview of what RMS is, how it works and some of the changes it has undergone from its release as an add-on for Windows Server 2003 back in 2005 to its incarnation in Windows Server 2012. In Part 2, we’ll talk about the next generation of RMS, Azure RMS, which has been revamped in a big way and was released in public preview form this summer.  – Deb

If you would like to read the next part in this article series please go to The Evolution of Microsoft’s Rights Management Services (Part 2).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top