Azure RMS Resource Center

Azure RMS Resource Center

What is Azure RMS?

How does Azure RMS work? Under the hood

Activating Azure Rights Management

Configuring applications for Azure Rights Management

Set up Information Rights Management (IRM) in SharePoint admin center

Step-By-Step: Setup and Enablement of Office 365 Message Encryption

Office 365 Message Encryption FAQ

Set up Microsoft Azure Rights Management for Office 365 Message Encryption

What is Azure RMS?

Azure RMS (Azure Rights Management) is the the protection technology that comes from Azure Information Protection, a cloud-based solution that empowers organizations to classify, label and protect their documents and emails. Azure RMS uses encryption, identity, and authorization policies to assist you in securing your files and emails. Since Azure RMS is cloud-based, it works across multiple devices, from phones and tablets to PCs. With Azure RMS, you can protect your information from both within your organization and outside your organization since the protection you get remains with the data, even when it leaves your organization’s boundaries.

As an example, if you email a document to a partner company, or save a document to your cloud drive. The constant protection that Azure RMS provides, not only helps to secure your company data, but could also be legally mandated for compliance, legal discovery requirements, or just good information management procedures.

“Reasoning over data” is a term that’s sometimes used to describe authorized people and services that can read and inspect the data that Azure RMS protects. This isn’t easily accomplished by other information protection solutions that use peer-to-peer encryption, that’s  why it’s a crucial element in maintaining control of your organization’s data.

How does Azure RMS work? Under the hood

It’s important to understand how Azure RMS works, in that Microsoft and the Rights Management service, doesn’t see or store your data as part of the information protection process. Information that you protect through RMS is never sent to or stored in Azure unless you explicitly store it in Azure or use another cloud service that stores it in Azure. Azure RMS will make the data in your document unreadable to anyone other than authorized users and services:

  • Your data is encrypted at the application level and includes a policy that defines the authorized use for your document.
  • When a protected document is used by a legitimate user or it an authorized service, your data in the document is decrypted and the rights that are defined in the policy are enforced.

Throughout the Azure RMS protection process when it’s encrypting, decrypting, authorizing, and enforcing restrictions, the “secret formula” is never sent to Azure.

Cryptographic control used by Azure RMS: Algorithms and key lengths

You might not need to know yourself how RMS works, but you might be asked about the cryptographic controls that Azure RMS uses, to make sure the protection is industry-standard.

Cryptographic controlsUse in Azure RMS
Algorithm: AES

Key length: 128 and 256 bits [1]

Documentation protection
Algorithm: RSA

Key length: 2048 bits [2]

Key protection
SHA-256Certificate signing

Footnote 1:

Azure Information Protection client and the Rights Management sharing application for generic protection and native protection use 256 bits when the file has a .ppdf file name extension or is a protected text or image file (such as .ptxt or .pjpg).

Footnote 2:

Azure Rights Management service has 2048-bits key length when the service is active. 1024-bits is supported for the following optional scenarios:

  • During a migration from on-premises if the AD RMS cluster is running in Cryptographic Mode 1 and can’t be upgraded to Cryptographic Mode 2.
  • For archived keys that were created on-premises before the migration so that content that was protected by AD RMS can continue to be opened after migrating to Azure Rights Management.
  • If customers choose to bring their own key (BYOK) by using Azure Key Vault. We recommend but do not enforce a minimum key size of 2048-bits.

How the Azure RMS cryptographic keys are stored and secured

Azure RMS creates a single AES key (the “content key”) for each document or email that it protects, and that key is embedded to the document, and persists through all the different editions of the document.

The content key is protected with the organization’s RSA key (the “Azure Information Protection tenant key”) as part of the policy in the document, and the policy is also signed by the author of the document. This tenant key is common to all documents and emails that are protected by the Azure Rights Management service. This key can only be changed by an Azure Information Protection administrator if the organization is using a tenant key that is customer-managed (known as “bring your own key”, or BYOK).

This tenant key is protected in Microsoft’s online services, in a highly controlled environment and under close monitoring, according to Microsoft. When you use a customer-managed tenant key (BYOK), this security is enhanced by the use of an array of high-end hardware security modules (HSMs) in each Azure region, without the ability for the keys to be extracted, exported or shared under any circumstances,  that’s what I call security! If you’re interested in more information about the tenant key and BYOK, you can check out, Planning and implementing your Azure Information Protection tenant key.

Licenses and certificates that are sent to a Windows device are protected with the client’s device private key, which is created the first time a user on the device uses Azure RMS. This private key, in turn, is protected with DPAPI on the client, which protects these secrets by using a key derived from the user’s password. On your mobile device, the keys are used only one time, since they are not stored on the clients, these keys don’t need to be protected on the device.

How Azure RMS works: First use, content consumption and content protection

To better understand how Azure RMS works, I’m going to take you through a typical flow once your Azure Rights Management service is activated and when a user first uses the Rights Management service on their Windows computer (this process is sometimes referred to as bootstrapping), protects content, and then consumes content that has been protected by someone else.

After the users environment has been initialized, that user can then start protecting documents or consume protected documents on their computer. If this same sure moves to another Windows computer, or another user uses their same Windows computer, the initialization process is repeated for your and their protection.

Initializing the user environment

Before any user can protect or consume protected content on a Windows computer, the user environment must be prepared on the device. This is a one-time process and happens automatically without intervention.

Step 1: The Azure RMS client on the computer first connects to the Azure Rights Management service, and authenticates the user by using their Azure Active Directory account. When the user’s account is federated with Azure Active Directory, this authentication is automatic and the user is not prompted for any credentials.

Step 2: After the user is authenticated, the connection is automatically redirected to the organization’s Azure information Protection tenant, which issues certificates that let the user authenticate to the Azure Rights Management service in order to consume protected content and to protect content offline.

A copy of the user’s certificate is stored in Azure so that if the user moves to another device, the certificates are created by using the same keys.

Content protection

When a user protects a document, the RMS client takes the following actions on an unprotected document:

content protection 1







Step 1: The RMS client creates a random key (the content key) and encrypts the document using this key with the AES symmetric encryption algorithm.


content protection 2









Step 2: The RMS client then creates a certificate that includes a policy for the document that includes the usage rights for users or groups, and other restrictions, such as an expiration date. These settings can be defined in a template that an administrator previously configured, or specified at the time the content is protected (sometimes referred to as an “ad-hoc policy”).

The main Azure AD attribute used to identify the selected users and groups is the Azure AD ProxyAddreeses attribute, which stores all the email addresses for a user or group. However, if a user account doesn’t have any values in the AD ProxyAddresses attribute, the user’s UserPrincipalName value is used instead.

The RMS client will then use the organization’s key that was obtained when the user environment was initialized and uses this key to encrypt the policy and the symmetric content key. The RMS client also signs the policy with the user’s certificate that was obtained when the user environment was initialized.

content protection









Step 3: This is when the RMS client embeds the policy into a file with the body of the document encrypted previously, which together comprise a protected document.

This document can be stored anywhere or shared by using the method, and the policy always stays with the encrypted document.

Content consumption

When a user wants to consume a protected document, the RMS client starts by requesting access to the Azure Management service:

Content consumption













Step 1: The authenticated user sends the document policy and the user’s certificates to the Azure Rights Management service. The service decrypts and evaluates the policy, and builds a list of rights (if any) the user has for the document. To identify the user, the Azure AD ProxyAddresses attribute is used for the user’s account and groups to which the user is a member. For performance reasons, group membership is cached. If the user account has no values for the Azure AD ProxyAddresses attribute, the value in the Azure AD UserPrincipalName is used instead.

Step 2: The service then extracts the AES content key from the decrypted policy. This key is then encrypted with the user’s public RSA key that was obtained with the request.

The re-encrypted content key is then embedded into an encrypted use license with the list of user rights, which is then returned to the RMS client.

Step 3: Lastly, the RMS client takes the encrypted use license and decrypts it with its own user private key. This lets the RMS client decrypt the document’s body as it is needed and render it on the screen.

The client also decrypts the rights list and passed them to the application, which enforces those rights I the application’s user interface.

When external users from your organization consume content that you’ve protected, the consumption flow is the same. What changes for this scenario, is how the user is authenticated. For more information, you can check out this Microsoft article: When I share a protected document with somebody outside my company, how does that user get authenticated?


Here are some variations of some standard scenarios:

Mobile devices: When mobile devices protect or consume files with the Azure Rights Management service, the process flows are much simpler. Mobile devices don’t first go through the user initialization process because instead, each transaction (to protect or consume content) is independent. As with Windows computers, mobile devices connect to the Azure Rights Management service and authenticate. To protect content, mobile devices submit a policy and the Azure Rights Management service sends them a publishing license and symmetric key to protect the document. To consume content, when mobile devices connect to the Azure Rights Management service and authenticate, they send the document policy to the Azure Rights Management service and request a use license to consume the document. In response, the Azure Rights Management service sends the necessary keys and restrictions to the mobile devices. Both processes use TLS to protect the key exchange and other communications.

RMS connector: When the Azure Rights Management service is used with the RMS connector, the process flows remain the same. The only difference is that the connector acts as a relay between the on-premises services (such as Exchange Server and SharePoint Server) and the Azure Rights Management service. The connector itself does not perform any operations, such as the initialization of the user environment, or encryption or decryption. It simply relays the communication that would usually go to an AD RMS server, handling the translation between the protocols that are used on each side. This scenario lets you use the Azure Rights Management service with on-premises services.

Generic protection (.pfile): When Azure Rights Management service generically protects a file, the flow is basically the same for content protection expect that the RMS client creates a policy that grants all rights. When the file is consumed, it is decrypted before it is passed to the target application. This scenario lets you protect all files, even if they don’t natively support RMS.

Protected PDF (.ppdf): When the Azure Rights Management service natively protects an Office file, it also creates a copy of that file and protects it in the same way. The only difference is that the file copy is in PPDF file format, which the Azure Information Protection client viewer and the RMS sharing application knows how to open for viewing only. This scenario lets you send protected attachments via email, knowing that the recipient on a mobile device will always be able to read them even if the mobile device doesn’t have an app that natively supports protected Office files.

What problems does Azure RMS solve?

Below is a table that shows problems that occur within organizations and how Azure RMS can solve those issues.

ProblemAzure RMS solution
Protect multiple file types√ In early implementations of Rights Management, only Office files could be protected, using native Rights Management protection. Now, generic protection that was first offered by the Rights Management sharing application and now by the Azure Information Protection client means that more file types are supported.
Protect files anywhere√ When a file is protected, the protection stays with the file, even if it is saved or copied to storage that is not under the control of IT, such as a cloud storage service.
Safely share information√ When a file is protected, it is safe to share with others. For example, an attachment to an email or a link to a SharePoint site. If the sensitive information is within an email message, you can protect the email or simply use the Do Not Forward option from Outlook.

The benefit of attaching a protected file rather than protecting the whole email message is that the email text is not encrypted, so you can include instructions for first-time use if the email is being sent outside your organization. Anybody can read the instructions but because the attached document is protected, only authorized users will be able to open the document, even if the email or document is forwarded to other people.

Auditing and monitoring√ You can audit and monitor usage of your protected files, even after these files leave your organization’s boundaries.

For example, you work for Contoso, Ltd. You are working on a joint project with three people from Fabrikam, Inc. You email these three people a document that you protect and restrict to read-only. Azure Rights Management auditing can provide the following information:

– Whether the people you specified in Fabrikam opened the document, and when.

– Whether other people that you didn’t specify attempted (and failed) to open the document—perhaps because it was forwarded or saved to a shared location that others could access.

– Whether any of the specified people tried (and failed) to print or change the document.

In addition, the document tracking site lets users and administrators track, and if necessary, revoke access to protected documents.

Support for commonly used devices, not just Windows computersSupported devices include:

– Windows computers and phones

– Mac computers

– iOS tablets and phones

– Android tablets and phones

Support for business-to-business collaboration√ Because Azure Rights Management is a cloud service, there’s no need to explicitly configure trusts with other organizations before you can share protected content with them. If they already have an Office 365 or an Azure AD directory, collaboration across organizations is automatically supported. If they do not, users can sign up for the free RMS for individuals subscription.
Support for on-premises services, as well as Office 365√ In addition to working seamlessly with Office 365, you can also use Azure Rights Management with the following on-premises services when you deploy the RMS connector:

– Exchange Server

– SharePoint Server

– Windows Server running File Classification Infrastructure

Easy activationActivating the Rights Management service for users requires just a couple of clicks in your management portal. Or, if you prefer command-line control, just two PowerShell commands.
Ability to scale across your organization, as needed√ Because Azure Rights Management runs as a cloud service with the Azure elasticity to scale up and out, you don’t have to provision or deploy additional on-premises servers.
Ability to create simple and flexible policiesCustomized rights policy templates provide a quick and easy solution for administrators to apply policies, and for users to apply the correct level of protection for each document and restrict access to people inside your organization.

For example, for a company-wide strategy paper to be shared with all employees, you could apply a read-only policy to all internal employees. Then, for a more sensitive document, such as a financial report, you could restrict access to executives only.

Broad application support√ Azure Rights Management has tight integration with Microsoft Office applications and services, and extends support for other applications by using the Azure Information Protection client.

√ The Azure Information Protection SDKs provide your internal developers and software vendors with APIs to write custom applications that support Azure Information Protection.

For more information, see Other applications that support the Rights Management APIs.

IT must maintain control of data√ Organizations can choose to manage their own tenant key and use the “Bring Your Own Key” (BYOK) solution and store their tenant key in Hardware Security Modules (HSMs).

√ Support for auditing and usage logging so that you can analyze for business insights, monitor for abuse, and (if you have an information leak) perform forensic analysis.

√ Delegated access by using the super user feature ensures that IT can always access protected content, even if a document was protected by an employee who then leaves the organization. In comparison, peer-to-peer encryption solutions risk losing access to company data.

√ Synchronize just the directory attributes that Azure RMS needs to support a common identity for your on-premises Active Directory accounts, by using a directory synchronization tool, such as Azure AD Connect.

√ Enable single-sign on without replicating passwords to the cloud, by using AD FS.

√ Organizations always have the choice to stop using the Azure Rights Management service without losing access to content that was previously protected by Azure Rights Management. For information about decommissioning options, see Decommissioning and deactivating Azure Rights Management. In addition, organizations who have deployed Active Directory Rights Management Services (AD RMS) can migrate to the Azure Rights Management service without losing access to data that was previously protected by AD RMS.

Activating Azure Rights Management

Configuring applications for Azure Rights Management

Set up Information Rights Management (IRM) in SharePoint admin center

Step-By-Step: Setup and Enablement of Office 365 Message Encryption

Office 365 Message Encryption FAQ