If you would like to read the other parts of this article series please go to:
- Getting to Know the Enterprise Mobility Suite (Part 1)
- Getting to Know the Enterprise Mobility Suite (Part 2)
- Getting to Know the Enterprise Mobility Suite (Part 4)
- Getting to Know the Enterprise Mobility Suite (Part 5)
Introduction
In Part 1 of this series, we talked about how EMS – Microsoft’s new mobile device management solution – offers organizations a more mobile, cloud-centric way of doing business. We discussed the components of EMS: Microsoft Active Directory Premium, Microsoft Intune and Microsoft Azure Rights Management and we provided an overview of what each one is and does and how it fits into the solution. In Part 2, we discussed some of the particulars of deploying Azure AD and InTune in your organization.
In this, Part 3, we will continue this series by beginning to present an overview of how to deploy and manage my favorite part of EMS: the Azure Rights Management service, and we’ll wrap up that topic – and the series – in Part 4.
The evolution of Microsoft’s Rights Management Services
Two years ago, I wrote a series of articles for our sister publication, Windowsecurity.com, called The Evolution of Microsoft’s Rights Management Services. Those articles go into detail about RMS from its introduction in 2005 as an add-on component for Windows Server 2003 through its transformation to Active Directory RMS in Server 2012 and then its leap into the cloud as Azure RMS in 2013.
To very briefly summarize, RMS began life as a great idea that was difficult to implement. The big obstacle was the requirement to set up and configure a rights management server on your network, which required deploying IIS since RMS ran on top of it. Things got a little easier in Windows Server 2008 when RMS was added as a server role, but you still had a number of other services on which it was dependent that had to be installed and configured. Some progress was made in Server 2012 with support for more versions of SQL Server and support for AD RMS in server core installations. Nonetheless, deploying RMS continued to be a challenging prospect that deterred many admins from even undertaking the task.
In Part 2 of the Evolution series, I went into the (then current) features of Azure RMS and how it could go beyond the capabilities of AD RMS on Windows Server with a focus on making rights management work in a mobile world. One of the advantages of cloud computing, of course, is that it makes things such as this easier. Instead of deploying services on servers in your own data center, you subscribe to and use those services that have already been installed, configured properly and are running in a cloud provider’s data center. There are still plenty of dependencies that you have to keep in mind to deploy Azure RMS, but the difference is that the cloud service provider does a lot of the heavy lifting for you.
Planning for Azure RMS deployment
The first and most obvious requirement in order to deploy and use Azure RMS is an Azure subscription – but not just any Azure subscription includes and supports RMS. Those that do include (of most interest to us in this series) the Enterprise Mobility Suite, and also Office 365, an Azure Rights Management Premium subscription or an RMS for individuals subscription.
Before you get all excited about using RMS with Office 365, it’s important to know that it isn’t included in most O365 plans. It is included in Enterprise E3 and E4, Education A3 and A4, and Government G3 and G4 subscriptions – in other words, you’ll need to have one of the top tier, most expensive versions of Office 365 to get Azure RMS with it (sorry to burst the bubble).
The good news is that if you don’t have a subscription that includes Azure RMS, you can subscribe to it as a standalone service. This is called Azure RMS Premium (formerly called Standalone), you can use it with versions of Office 365 that don’t include RMS. It will work with all versions of O365, although there are some limitations with the Business Premium edition of O365.
NOTE:
There is a trial subscription of this service available but it’s important to know that if you use the trial and it expires, you’ll not be able to access the content that was protected by RMS unless and until you buy a paid Azure RMS subscription or one of the Office 365 editions that includes it or subscribe to EMS. Also note that if, on the other hand, you have a paid subscription that includes RMS and you later decommission and deactivate it, you will still be able to access the content that you protected with Azure RMS.
Finally, for individual users whose organizations don’t have AD RMS or Azure RMS and who want to be able to protect their content or access RMS-protected content, there is a subscription for RMS for Individuals. This is a good solution for individuals in other organizations with whom you want to share your protected content when their orgs don’t have Azure AD accounts. AD RMS for individuals creates an unmanaged Azure tenant and directory for the org that contains an account for the individual user.
It’s a free service, so you might wonder why everyone doesn’t just get an individual subscription instead of a company paying for a subscription. The answer is that RMS for individuals is designed for the consumption of RMS-protect content. Even though you can also protect content with it, that feature is intended for trial usage only. The Terms of Service for this free subscription make it clear that Microsoft can limit the number of users in an organization who use the free service to create and share protected content. You can view the ToS here.
In addition to a subscription that includes the RMS service, you’ll need the following to deploy it in your org:
- Azure Active Directory. This is the means by which users are authenticated for RMS purposes so you’ll need an Azure subscription with Azure AD. You can set up directory integration if you want to use your on-premises Active Directory services’ user accounts.
- Multi-factor authentication. MFA is supported by RMS but is not required. MFA requires Office 2013 or above, the Rights Management sharing app for Windows or the app for your mobile device. MFA is configured in the Azure Portal on the Active Directory page.
- Client OS support. Client devices that will be used to create, share and access RMS-protected content will need to run operating systems that support RMS. That means Windows 7, 8, 8.1 or 10, Windows 8 or 8.1 RT, Windows Phone 8.1, Mac OS X 10.8 or later, Android 4.0.3 or later, iPhone/iPad running iOS 7.0 or later. Some operating systems may support more RMS features and capabilities than others and some require the AD RMS Mobile Device Extension.
- Application support. RMS-protected content can be created, shared and consumed only with applications that support Azure RMS. This includes Microsoft Office Pro 2010, 2013 and 2016, Office 365 editions that include Azure RMS, the Rights Management Sharing app for Windows, Mac, Windows Phone, iOS and Android. You can download the RMS sharing app here . RMS is also supported by LOB apps written in-house or by software vendors using the RMS SDK. Note that Office for Mac 2011 is not support by Azure RMS at the time of this writing.
- Infrastructure. Your network infrastructure and firewalls must be properly configured to allow connectivity to specific URLs and IP addresses and ranges that are used by Azure RMS. You can find these here.
- On-premises servers. You can use Azure RMS with your on-premises Exchange 2010 or 2013, SharePoint 2010 or 2013, or Windows Server 2012/2012 R2 file server with File Classification Infrastructure (FCI) to protect Office files. Hybrid Exchange deployments – in which some users are using Exchange Online and others have accounts on an on-premises Exchange server – are supported by Azure RMS, using the RMS connector for Exchange server.
What if you have on-premises AD RMS and you want to run it alongside Azure RMS? Microsoft says no – or rather, they don’t support this type of deployment, except during a migration. You can migrate from AD RMS to Azure RMS, or you can continue to use AD RMS and decommission and deactivate Azure RMS. There is also a “backward” migration path from Azure RMS to AD RMS, so you have several options. You can find out more about the most common scenario, migrating from AD RMS to Azure RMS here.
Summary
In this, Part 3 of our series on EMS, we explored the requirements and considerations that you need to think about when planning for your deployment of the Azure Rights Management Services (RMS) component of EMS. Next time, in Part 4, we’ll wrap up this series with a deeper dive into the how-to of that subject.
If you would like to read the other parts of this article series please go to:
