Hi there. Welcome to the second post in my series exploring the evolution of Active Directory Rights Management Service (AD RMS) into Azure Information Protection (AIP). In the first post of the series I gave an brief overview of the important role AIP plays in Microsoft’s Cloud App Security (CAS) offering. I also covered the details of the lab I will be using for this series. Take a few minutes to read the post to familiarize yourself with the lab details because it’ll be helpful as we progress through the series.
I went back and forth as to what topic I wanted to cover for the second post and decided it would be useful to start at the high level comparing the components in a typical Windows AD RMS implementation to those used when consuming AIP. I’m going to keep the explanation of each component brief to avoid re-creating existing documentation, but I will provide links to official Microsoft document for each component I mention. With that intro, let’s begin.
The infrastructure required in an AD RMS implementation is pretty minimal but the complexity is in how all of the components work together to provide the solution. At a very high level it is similar to any other web-based application consisting of a web server, application code, and a data backend. The web-based application integrated with a directory to authenticate users and get information about the user that is used in authorization decisions. In the AD RMS world the components map to the following products:
- Web Server – Machine running Windows Server with Microsoft Internet Information Services and Microsoft Message Queuing Service
- Application Code – Code installed onto the machine after adding the AD RMS role to a machine running Windows Server
- Data Backend – Machine running Windows Server with Microsoft SQL Server running on it hosting configuration and logging database (optionally Windows Internal Database (WID) for test environments)
- Directory – Windows Active Directory provides authentication, user information used for authorization, and stores additional AD RMS configuration data (Service Connection Point)
Nodes providing the AD RMS service are organized into a logical container called an AD RMS Cluster. Like most web applications AD RMS can be scaled out by adding more nodes to the cluster to improve performance and provide high availability (HA). If using MS SQL for the data backend, traditional methods of HA can be used such as SQL clustering, database mirroring, and log shipping. You can plop your favorite load balancer in front of the solution to help distribute the application load and keep track of the health of the nodes providing the service.
Beyond the standard web-based application components we have some that are specific to AD RMS. Let’s take a deeper look at them.
- AD RMS Cluster Key
The AD RMS cluster key is the most critical part of an AD RMS implementation, the “key to the kingdom”, as it is used to sign the Server Licensor Certificate (SLC) which contains the corresponding public key. The SLC is used to sign certificates created by AD RMS that allow for consumption of AD RMS-protected content as well as being used by AD RMS clients to encrypt the content key when a document is newly protected by AD RMS.
The AD RMS cluster key is shared by all nodes that are members of the AD RMS cluster. It can be stored within the MS SQL database/WID or on a supported hardware security module for improved security.
- AD RMS Client / AD RMS-Integrated Server Applications
Applications are great, but you need a method to consume them. Once content is protected by AD RMS it can only be consumed by an application capable of communicating with AD RMS. In most cases this is accomplished by using an application that has been written to use the AD RMS Client. The AD RMS Client comes pre-installed on Windows Vista and up desktop operating systems and Windows Server 2008 and up server operating systems.
The AD RMS client performs tasks such as bootstrapping (sometimes referred to as activation). I won’t go into the details because I wouldn’t do near as well job as Dan does in the bootstrapping link. In short it generates some keys and obtains some certificates from the AD RMS service that facilitate protecting and consuming content.
AD RMS-integrated server applications such as Microsoft SharePoint Server and Microsoft Exchange Server provide server-level services that leverage the capabilities provided by AD RMS to protect data such as files stored in a SharePoint library or emails sent through Microsoft Exchange.
- AD RMS Policy Templates
While not a component of the system architecture, AD RMS Policy Templates are an AD RMS concept that deserves mention in this discussion. The templates can be created by an organization to provide a standard set of use rights applicable to a type of data. Common use cases are having multiple templates created for different data types. For example, you may want one data type that allows trusted partners to view the document but not print or forward it while another template may restrict view rights to the accounting department.
In AD RMS the policies are stored in the AD RMS database but are accessible via a call to the web service. Optionally they can be exported from the database and distributed in other means like a Windows file share.
As you can see there are a lot of moving parts to an on-premises Windows AD RMS implementation. Some of the components mentioned above can get even more complicated when the need to collaborate across organizations or support mobile devices arises.
How does AIP compare? For the purposes of this post, I’m going to focus that comparison on Azure RMS which provides the protection capability of AIP. Azure RMS is a software-as-a-service (SaaS) offering from Microsoft replaces (yes Microsoft, let’s be honest here) AD RMS. It is licensed on a per user basis via a stand-alone, Enterprise Mobility + Security P1/P2, or qualifying Office 365 license.
The architecture of Azure RMS is far more simple than what existed for AD RMS. Like most SaaS services, there is no on-premises infrastructure required except in very specific scenarios such as hold-your-own-key (HYOK) or integrating Azure RMS with an on-premises Microsoft Exchange Server, Microsoft SharePoint Server, or servers running Windows Server and File Classification Infrastructure (FCI) using the RMS Connector. This means you won’t be building any servers to hold the RMS role or SQL Servers to host configuration and logging information. The infrastructure is now managed by Microsoft and the RMS service provided over HTTP/HTTPS.
Azure RMS shifts its directory dependency to Azure Active Directory (AAD). It uses the tenant in which the Azure RMS licenses are associated with for authentication and authorization of users. As with any AAD use case, you can still authenticate users against your on-premises Windows Active Directory if you’ve configured your tenant for federated authentication and source data from an on-premises directory using Azure Active Directory Connect.
The cluster key, client, integrated applications, and policies are still in place and work similar to on-premises AD RMS with some changes to both function and names.
- Azure Information Protection Tenant Key
The AD RMS Cluster key has been renamed to the Azure Information Protection tenant key. The tenant key serves the same purpose as the AD RMS Cluster and is used to sign the SLC certificate and decrypt information sent to Azure RMS using the public key in the SLC. The differences between the two are really around how the key is generated and stored. By default the tenant key is generated (note that Microsoft generates a 2048-bit key instead of a 1024-bit like was done with new installations of AD RMS) by Microsoft and is associated with your Azure Active Directory tenant. Other options include bring-your-own-key (BYOK), HYOK, and a special instance where you are migrating from AD RMS to Azure RMS. I’ll cover HYOK and the migration instance in future posts.
- Azure Information Protection Client
The AD RMS client is replaced with the Azure Information Protection Client. The client performs the same functions as the AD RMS Client but allowing for integration with either on-premises AD RMS or Azure RMS. In addition, the client introduces functionality around Azure Information Protection including adding a classification bar for Microsoft Office, Do Not Forward button to Microsoft Outlook, option in Windows File Explorer to classify and protect files, and PowerShell modules that can be used to bulk classify and protect files. In a future post in this series I’ll be doing a deep dive of the client behavior including analysis of its calls to the Azure Information Protection endpoints via Fiddler.
Unlike the AD RMS client of the past, the Azure Information Protection Client is supported on mobile operating systems such as iOS and Android. Additionally, it supports a wider variety of file types than the AD RMS client supported.
- Azure RMS-Integrated Server Applications
Like its predecessor Azure RMS can be consumed by server applications such as Microsoft Exchange Server and Microsoft SharePoint Server with the RMS Connector. There is native integration with Office 365 products including Exchange Online, SharePoint Online, OneDrive for Business, as well as being extensible to third-party applications via Cloud App Security (I’ll demonstrate this after I complete this series). Like all good SaaS, there is also an API that can be leveraged to add the functionality to custom developed applications.
- Rights Management Templates
Azure RMS continues to use concepts of rights management templates like its predecessor. Instead of being stored in a SQL database, the templates are stored in Microsoft’s cloud. Templates created in AD RMS can also be imported into Azure RMS for continued use. I’ll demonstrate how that process in a future post in this series. Classification labels in AIP are backed by templates whenever a label applies protection with a pre-defined set of rights. I’ll demonstrate this in a later post.
Far more simple in the SaaS world isn’t it? In addition to simplicity Microsoft delivers more capabilities, tighter integration with its collaboration tools, and expansion of the capabilities to third party applies through a robust API and integration with Cloud App Security.
See you next post!