The Azure Rights Management service (Azure RMS) is a cloud-based service that provides information protection capabilities for an organization's devices, services, and applications.
Azure RMS is notably available as the Azure Rights Management Premium subscription or is part of the Enterprise Mobility Suite, or part of the Office 365 Enterprise and Education subscriptions, and is natively integrated in this latter case with Exchange Online email, SharePoint Online, and Office client applications to apply persistent protection to the content to meet the business requirements of your organization.
Note For additional information on Cloud subscriptions that support Azure RMS, see the eponym section in the Microsoft TechNet article Requirements for Azure Rights Management.
Once a document or email is protected, it stays protected as it travels between clients, devices, servers and online services, even if the document travels outside of the organization's boundaries.
Azure RMS never sees your sensitive content, but because Azure RMS is responsible for secure electronic key exchange operations between client devices, servers and other systems, it requires authentication and authorization information. For this, it leverages Azure Active Directory (Azure AD) and its associated services, such as Azure Active Directory Connect (Azure AD Connect) for directory synchronization as well as single sign-on, a.k.a. federation, with Active Directory Federation Services (AD FS) if you want to.
Note Azure AD Connect is a single and unified wizard that streamlines and automates the overall onboarding process for both directory synchronization with on-premises AD single-forest and multi-forest environments (including password (hash of hash) synchronization) and single sign-on if you want to.
Azure AD Connect is the one stop shop for connecting your on-premises directories to Azure AD, whether you are evaluating, piloting, or in production.
Note Azure AD supports integration with AD FS and other third-party federation server such Shibboleth2, PingFederate, SiteMinder, etc. to provide a (federated) single sign-on experience for corporate federated users while keeping user passwords on-premises - if the same sign-on experience enabled by the password (hash of hash) synchronization capability of Azure AD Connect isn't sufficient and/or doesn't fulfill the security requirements of your organization.
Note In complement to Azure AD Connect, the Azure Active Directory Connect Health (Azure AD Connect Health)
cloud based service in the
Azure Preview Portal helps you monitor and gain insight into health, performance and login activity of your on-premises identity infrastructure. As such, it offers you the ability to view alerts, performance, usage patterns, configuration settings, enables you to maintain a reliable connection to Azure AD and much more.
Azure AD Connect Health is a feature of the Azure AD Premium edition and represents a key part of our effort to help you monitor and secure your cloud and on-premises identity infrastructure. For more information, see the article Monitor your on-premises identity infrastructure in the cloud.
Interestingly enough, Azure RMS also leverages in the above context the modern authentication in Office 365. Modern authentication brings Active Directory Authentication Library (ADAL)-based sign in to:
This update enables you to configure new security scenarios for sign in with Office 365. It indeed allows Office client applications to engage in browser-based authentication with AD FS (or other supported STSs) to sign in to the Azure AD/Office 365 service to gain access to Exchange Online email, SharePoint Online, Skype for Business Online (formerly Lync Online), and to activate the Office client license.
New authentication scenarios are enabled with Azure RMS thanks to availability of modern authentication as follows:
Note MFA is a method of authentication that requires the use of more than one verification method and adds a critical second layer of security when your users sign-in. It is one of important cloud security controls. For additional information, see the bog post Cloud security controls series: Multi-factor Authentication.
Important note On iOS devices, and as of this writing, MFA support on Office client applications and RMS sharing application works only with PhoneFactor MFA application (this is the previous version of Azure Authenticator). Microsoft is actively working to fix this and you can thus expect an update in the next few weeks. In the meantime, you can try out MFA with RMS on all other platforms.
Note Support for smart cards is however challenging on mobile devices running iOS or Android.
As a whole, modern authentication update in RMS applications enables you to use stronger authentication with Azure RMS.
Furthermore, as indicated above, modern authentication is not just devoted to Windows devices but provides a cross platform support (Windows, OS X, iOS, and Android).
The following table offers a synthesis of the modern authentication availability as of this writing.
Windows | Mac OS X | iOS | Android | |
Office 2013/2016 (Word, Excel, PowerPoint, OneNote, Publisher, Visio, Access, Project) | Available now | N/A | Available now (Excel, OneNote, PowerPoint, and Word) | Available now (Excel, OneNote, PowerPoint, and Word) |
Lync 2013/Skype for Business 2015 | Available now | TBD | Coming soon | Coming soon |
Outlook 2013/2016 | Available now | Available now* *Outlook 2016 uses ADAL for licensing and IRM, but still uses basic for syncing mail | Available now | Available now |
OneDrive for Business | Available now (app included in Office suite) | TBD | Available now | Available now |
Modern authentication provides single sign-on between all Office client applications (Word, Excel, PowerPoint, Outlook, OneNote, etc.). In other words, a user will not be required to sign in again to Office when i) they have already signed into another Office client application on same device, ii) Office is running on a domain-joined Windows device, or iii) Office is running on an Azure AD joined
Windows 10 device.
Modern authentication however does not provide single sign-on between client apps and web sites or across devices (or platforms). As far as the latter is concerned, an on-premises solution like AD FS greatly contributes to enhance the user experience avoiding users to sign-in again in some situations.
From a technical standpoint, modern authentication is a new OAuth-based authentication stack used by Office client applications against Office 365 where ADAL replaces for Windows clients the Microsoft Online Sign-in Assistant.
Note For more information, see the blog post Office 2013 modern authentication public preview announced.
Note The Microsoft Online Services Sign-In Assistant (SIA) 7.0 provides end user sign-in capabilities to Microsoft Online Services, such Office 365. In the context of this paper, the SIA is used to authenticate users to these services through a set of dynamic link library files (DLLs) and a Windows service as described in the community article Description of Microsoft Online Services Sign-In Assistant (SIA).
These together enable for Azure RMS a single sign-on authentication experience from Office client applications. This also allows additional authentication factors as per modern authentication.
This document provides information about configuring Azure RMS with federation on-premises for Office client applications thanks to the aforementioned technologies and building blocks.
It more particularly covers how to leverages the modern authentication to allow federated users to authenticate against Office 365 with their on-premises credentials, and illustrates in this context, thanks to Azure RMS, how persistent protection can be smoothly applied to the Office documents, and/or how RMS-protected documents can be consumed seamlessly in accordance to the applied usage rights.
For that purpose, it illustrates the deployment scenario where:
As far as the latter bullet is concerned, multi-factor authentication is indeed becoming the new standard for securing access and how businesses ensure trust in a multi-device, mobile, cloud world. Passwords can be easily compromised, and the consumerization of IT along with the Bring-Your-Own-Device (BYOD) trend have only increased the scope of vulnerability.
Note In order to enable multi-factor authentication in AD FS in Windows Server 2012 R2, you must select at least one additional authentication method. You can enable Microsoft and third-party authentication methods in AD FS. Once installed and registered with AD FS, you can enforce MFA as part of the global or per-relying-party authentication policy as described and instructed in this document with MFA Server.
You can configure in AD FS a MFA server authentication provider as well as other third-party external authentication providers. For additional information on the available ADFS-integrated solutions, see the Microsoft TechNet article Configure Additional Authentication Methods for AD FS.
Built on existing Microsoft documentation and knowledge base articles, this document provides a complete walkthrough to build a suitable test lab environment in Azure, test, and evaluate the above scenario. It also provides additional guidance.
To illustrate the various situations, you may encounter, based on such a scenario, the walkthrough will encompass the use of Office 365 ProPlus running on i) a domain-joined Windows device, ii) a non-domain joined Windows device, and eventually iii) an Azure AD joined
Windows 10 device.
This document doesn't provide a full description of Azure RMS. It rather focuses on key aspects that aims at providing the readers an understanding on how to leverage and deploy federation on-premises with Azure RMS for Office client applications.
This document also doesn't provide a full description of AD FS in Windows Server 2012 R2. It doesn't provide neither guidance for setting up and configuring AD FS in a production environment nor a complete technical reference for AD FS.
Note For information on AD FS, please refer to the product documentation, and the dedicated AD FS Q&A forum.
Moreover, it doesn't neither provide an understanding of the different single sign-on deployment options with Azure AD/Office 365, how to enable single sign-on using corporate Active Directory credentials and AD FS to Azure AD/Office 365, and the different configuration elements to be aware of for such deployment.
The current version of this document also doesn't cover the use of non-Windows devices. (A forthcoming addition will cover Office for iOS as well.)
To cover the aforementioned objectives, this document is organized in the following four sections:
These first two sections provide the information details necessary to (hopefully) successfully build a working environment for Azure RMS with an on-premises federation infrastructure. They must be followed in order.
This document is intended for system architects and IT professionals who are interested in understanding how to enable and configure Azure RMS with federation with their existing on-premises identity infrastructure.
As its title suggests, this section guides you through a set of instructions required to build a representative test lab environment that will be used in the next section to configure, test, and evaluate the new capabilities introduced by Azure RMS with an on-premises federation for Office ProPlus 365 client applications. As outlined in the objectives of this document, the on-premises federation infrastructure will be based on Active Directory Federation Services (AD FS), the version being illustrated is AD FS in Windows Server 2012 R2.
As we keep mentioning Office 365 from the beginning of this document, you won't be surprised by the need to have an Office 365 tenant provisioned. Let's start with that.
This test lab environment requires an Office 365 subscription for testing. If you don't have any, you can sign up for a free trial.
To sign up to a free 30-day Microsoft Office 365 Enterprise E3 trial, follow the instructions at http://go.microsoft.com/fwlink/p/?LinkID=403802.
Note For more information, see the article Sign in to Office 365.
For the course of this walkthrough, we've provisioned an Office 365 Enterprise (E3) tenant: litware369.onmicrosoft.com.
You will have to choose in lieu of it a tenant domain name of your choice whose name is currently not in use.
Whenever a reference to litware369.onmicrosoft.com is made in a procedure, it has been replaced by the tenant domain name of your choice to reflect accordingly the change in naming.
The on-premises test lab environment allows to test scenarios that pertains to Azure RMS with on-premises federation for Office client applications. By nature, implementing Azure RMS with federation implies a hybrid Active Directory environment, i.e. a cross-premises configuration between Windows Server Active Directory (WS AD) and Azure AD.
Considering the involved services, products, and technologies that encompass such a cross-premises configuration, the test configuration should feature:
The following diagram provides an overview of the overall test lab environment with the software and service components that need to be deployed / configured.
A challenge in creating a useful on-premises test lab environment is to enable their reusability and extensibility. Because creating a test lab can represent a significant investment of time and resources, your ability to reuse and extend the work required to create the test lab is important. An ideal test lab environment would enable you to create a basic lab configuration, save that configuration, and then build out multiple test lab scenarios in the future by starting with the base configuration.
Moreover, another challenge people is usually facing with relates to the hardware configuration needed to run such a base configuration that involves several (virtual) machines.
For these reasons and considering the above objectives, we have tried to streamline and to ease as much as possible the way to build a suitable test lab environment, to consequently reduce the number of instructions that tell you what servers to create, how to configure the operating systems and core platform services, and how to install and configure the required core services, products and technologies, and, at the end, to reduce the overall effort that is needed for such an environment. Thus, this document will leverage the Microsoft Azure environment along with the Azure PowerShell cmdlets to build the on-premises test lab environment to test and evaluate the above scenarios at the beginning of this section.
We hope that the provided experience will enable you to see all of the components and the configuration steps both on-premises and in the cloud that go into such a multi-products and services solution.
Adding an Azure trial to the Office 365 account
Once you have signed up and established your organization with an account in Office 365 Enterprise E3, you can then add an Azure trial subscription to your Office 365 account. This can be achieved by accessing the Azure Sign Up page at https://account.windowsazure.com/SignUp with your Office 365 global administrator account. You need to select Sign in with your organizational account for that purpose.
Note You can log into the Office 365 administrator portal and go to the Azure Signup page or go directly to the signup page, select sign in with an organizational account and log in with your Office 365 global administrator credentials.
Once you have completed your trial tenant signup you will be redirected to the Azure account portal
and can proceed to the Azure management portal by clicking Portal at the top right corner of your screen.
Note This notably enables you to empower your Office 365 subscription with the access management and security features that Azure AD is offering. While there are and will be ongoing investments in the Office 365 management portal, rich identity and access management capabilities are and will be exposed through the Active Directory section in the Azure management portal first. For example, the Application Access Enhancements for Azure AD, which provides a streamlined access to thousands of cloud SaaS pre-integrated applications like Box, GoToMeeting, Salesforce.com and others, (and even and more in the coming months,) can be only managed today by accessing the directory through the Azure management portal.
At this stage, you should have an Office 365 Enterprise E3 trial subscription with an Azure trial subscription.
Setting up the Azure-based lab environment
The whitepaper Azure AD/Office 365 Single Sign-On with AD FS in Windows Server 2012 R2 - Part 2bis fully depicts the setup of such an environment.
In order not to "reinvent the wheel", this document leverages the instrumented end-to-end walkthrough provided in the above whitepaper to rollout a working single sign-on configuration for Azure AD/Office 365 with AD FS by featuring the now generally available Azure Active Directory Connect (Azure AD Connect) tool.
By following the instructions outlined in these whitepapers along with the provided Azure/Windows PowerShell scripts, you should be able to successfully prepare your Azure-base lab environment based on virtual machines (VMs) running in Azure.
Important note Individual virtual machines (VMs) are needed to separate the services provided on the network and to clearly show the desired functionality. This being said, the suggested configuration to later evaluate Azure RMS with federation is neither designed to reflect best practices nor does it reflect a desired or recommended configuration for a production network. The configuration, including IP addresses and all other configuration parameters, is designed only to work on a separate test lab networking environment.
Any modifications that you make to the configuration details provided in the rest of this document may affect or limit your chances of successfully setting up the on-premises collaboration environment that will serve as the basis for the previously outlined scenarios.
Microsoft has successfully built the suggested environment with Azure IaaS, and Windows Server 2012 R2 virtual machines.
In addition, you will need to follow the walkthrough provided by the whitepaper Leverage Multi-Factor Authentication (MFA) Server on-premises.
By following the instructions outlined in this second whitepaper, you should be able to successfully deploy and configure Azure Multi-Factor Authentication Server (MFA Server) on top of the above Azure-based lab environment, and thus integrate it with the AD FS infrastructure already deployed in this context.
Once completed the aforementioned white papers' walkthrough, you'll have in place an environment with
a federated domain in the Azure AD/Office 365 tenant (e.g. litware369.onmicrosoft.com). As already outlined above, the whitepapers have opted to configure the domain litware369.com (LITWARE369). You will have to choose in lieu of a domain name of your choice whose DNS domain name is currently not in used on the Internet. For checking purpose, you can for instance use the domain search capability provided by several popular domain name registrars.
Whenever a reference to litware369.com is made in a procedure later in this document, it has to be replaced by the DNS domain name of your choice to reflect accordingly the change in naming. Likewise, any reference to LITWARE369 should be substituted by the NETBIOS domain name of your choice.
The Azure-based test lab infrastructure will constitute the base configuration for the walkthrough provided as part of this paper.
It consists of the following components:
Note Windows Server 2012 R2 offers businesses and hosting providers a scalable, dynamic, and multitenant-aware infrastructure that is optimized for the cloud. For more information, see the Microsoft TechNet Windows Server 2012 R2 homepage.
The above VMs expose one public endpoint for remote desktop (RDP) and another one for remote Windows PowerShell (WinRMHTTPS) as illustrated hereafter.
The EDGE1 VM exposes in addition a public endpoint for HTTPS (HttpsIn).
These VMs will enable you to create snapshots so that you can easily return to a desired configuration for further learning and experimentation.
The integrated test lab consists of:
For the sake of simplicity, the same password "pass@word1" is used throughout the configuration. This is neither mandatory nor recommended in a real world scenario.
To perform all the tasks in this guide, we will use the LITWARE369 domain Administrator account AzureAdmin for each Windows Server 2012 R2 VM, unless instructed otherwise.
The base configuration should now be completed at this stage if you've followed the whitepaper's walkthrough.
To avoid spending your credit when you don't work on the test lab, you can shut down the 3 VMs (DC1, ADFS1, and EDGE1) when you don't work on the test lab.
To shut down the VMs of the test lab environment, proceed with the following steps:
To resume working on the test lab, you will then need to start in order the DC1 computer, then the ADFS1 one, and finally EDGE1.
To start the VMs of the test lab environment, proceed with the following steps:
At this stage, the above Azure-based lab environment reflects the required hybrid Active Directory environment to allow testing scenarios that pertains to Azure RMS with federation on-premises for Office client applications.
This above Azure-based lab environment should now be updated to add three more Windows computers to test the user experience from i) a domain-joined computer, ii) a non-domain joined computer, and finally iii) an Azure AD joined computer, and respectively named LAPTOP1, LAPTOP2, and LAPTOP3.
This is the purpose of the next three sections.
Deploying Windows 8.1 and Windows 10 Enterprise clients to Microsoft Azure is available for MSDN subscribers to be used exclusively for application development and testing purposes,
Note Only Enterprise editions of the Windows clients are listed so that so the image can be activated when provisioned in Azure.
For the sake of brevity, this document will leverage this capability to add a Windows domain-joined computer to the above Azure-based test lab environment. This requires a MSDN subscription account.
Important note If you are not a MSDN subscriber – or you'd like to rather use your own image -, see the article Create and upload a Windows Server VHD to Azure to understand how to create your own Windows client VM.
To add a Windows 8.1 domain-joined computer to the test lab environment, proceed with the following steps:
Or FROM GALLERY, bring up the image gallery directly. A CREATE A VIRTUAL MACHINE dialog shows up.
Username: LAPTOP1\AzureAdmin
Password: pass@word1
Username: LITWARE369\AzureAdmin
Password: pass@word1
To add additional users to connect remotely, proceed with the following steps once the LAPTOP1 computer has rebooted:
Username: LITWARE369\AzureAdmin
Password: pass@word1
You're now in position to verify the single sign-on with the Azure AD/Office 365 tenant (e.g. litware369.onmicrosoft.com with the federated domain litware369.com) and potentially assess at this stage the configuration of your hybrid test lab environment if needed.
To verify the single sign-on with the Azure AD/Office 365 tenant, proceed with the following steps:
Username: LITWARE369\JanetS
Password: pass@word1
If single sign-on is correctly set up, you should be automatically redirected to the on-premises identity infrastructure, i.e. the ADFS1 computer (https://adfs.litware369.com) in our configuration for the test lab environment, and then redirected back to the portal after a successful seamless authentication with your local user credentials thanks to the Windows Integrated Authentication. At the end of the process, you should have a seamless access to the signed in user settings in Office 365.
Janet Schorr is not yet licensed to Office 365 Enterprise.
If you reproduce the above experience, your domain-joined machine is ready to use for the rest of this document. You can skip the next section on troubleshooting.
If you do not reproduce the above experience, you may encounter the following issues.
Note A quick guidance is provided to (try to) fix the situation. Please refer the Microsoft TechNet documentation if additional information is needed beyond the short explanation that is provided.
Fix: The AD FS site may not be trusted by the local Internet Explorer. You can avoid these prompts by adding the AD FS endpoint (for example https://adfs.litware369.com in our illustration) to the Internet Explorer's Local Intranet sites list on the local computer.
Fix: This indicates a problem accessing the AD FS endpoint. Try browsing directly to your AD FS sign-in page: https://<AdfsServerName>/adfs/ls/idpinitiatedsignon.htm, for example https://adfs.litware369.com/adfs/ls/idpinitiatedsignon.htm in our illustration)
This should display an AD FS sign-in page where you can sign in with the domain credentials.
Click Sign in to check if the user is successfully and seamlessly authenticated thanks to the Windows Integrated Authentication. You shouldn't see any Windows Security dialog if AD FS has been properly configured.
If that also fails, check the Event Viewer (eventvwr.msc) on the user's computer for errors.
If the Service Principal Name (SPN) is not registered for the group Managed Service Account (gMSA) account, you'll see a Security-Kerberos error in the System log. The fix is to register the SPN to the AD FS endpoint by running these commands from a command prompt with administrative privileges (or register using the ADSI Edit snap-in on the DC1 domain controller):
Setspn –U –S http/<AdfsServerName> <gMSAAccount>
Setspn –U –S https/<AdfsServerName> <gMSAAccount>
For example, in our configuration:
setspn –U –S http/adfs.litware369.com FsGmsa$
Setspn –U –S https/adfs.litware369.com FsGmsa$
Fix: Open the AD FS Management console to view the Authentication Policies settings for Global Primary Authentication. Windows Authentication should be enabled for the Intranet.
Fix: Open the AD FS Management console to view the Authentication Policies for Global Primary Authentication. Windows Authentication should be enabled for the Intranet.
Fix: Open the AD FS Management console to view the Authentication Policies settings for Global Multi-Factor Authentication.
Fix: Chrome does not support Integrated Windows Authentication, so single sign-on will not work on that browser. You will have to enter the password manually.
To deploy an additional Windows 8.1 non-domain joined computer to the test lab environment, repeat the steps 1 to 12 of the section Deploying a domain-joined computer along with the following adaptations:
As before, once provisioned and started, you can click CONNECT at the bottom of the tray, and then open the remote desktop .rdp file. The credentials of the above local account you specified should be used, for example in our configuration:
Username: LAPTOP2\AzureAdmin
Password: pass@word1
Once the computer has rebooted, you're now in position to verify the single sign-on with the Azure AD/Office 365 tenant (e.g. the federated domain litware369.com) and potentially assess the configuration of your hybrid test lab environment if needed.
To verify the single sign-on with the Azure AD/Office 365 tenant, proceed with the following steps:
Username: LAPTOP2\AzureAdmin
Password: pass@word1
If single sign-on is correctly set up, you should be automatically redirected to the on-premises identity infrastructure, i.e. the EDGE1 Web Application Proxy (WAP) computer (https://adfs.litware369.com) in our configuration for the test lab environment. The AD FS sign-in page is then displayed after a successful redirection.
Robert Hatley is not yet licensed to Office 365 Enterprise.
If you reproduce the above experience, your non-domain joined machine is ready to use for the rest of this document. You can skip the next section on troubleshooting.
If you do not reproduce the above experience, you may encounter the following issues.
Note A quick guidance is provided to (try to) fix the situation. Please refer the Microsoft TechNet documentation if additional information is needed beyond the short explanation that is provided.
Fix: The sign-in needs to contact your ADFS1 server (through the EDGE1 WAP server) and can't resolve that address. Register the ADFS URL in extranet DNS so that it resolves correctly to the WAP IP address. You will also need to allow traffic on port 443 through the firewall to the WAP.
Fix: Verify first the SSL/TLS certificate and make sure that the thumbprint corresponds to the one configured on the EDGE1 server. If the thumbprint matches:
Fix: Open the AD FS Management console to view the Authentication Policies setting for Global Primary Authentication. Forms Authentication should be enabled for the Extranet.
Fix: Open the AD FS Management console to view the Authentication Policies settings for Global Multi-Factor Authentication.
Another local user will be needed later in this document to test the IRM features of Office.
To add another local user, proceed with the following steps:
Windows 10 Pro, Windows 10 Enterprise, and Windows 10 Education editions enable a device to join an Azure AD tenant without needing the traditional WSAD domains on-premises if you want to. (Windows 10 mobile doesn't support this capacity as of this writing.)
This provides a series of benefits for the end-users like a seamless single sign-on experience to all the resources protected by your Azure AD tenant. In addition, from an IT professional perspective, this allows to set rules and policies that control who has access and under what conditions.
Note For additional information, see the whitepaper Azure AD & Windows 10: Better Together for Work or School.
To add a Windows 10 enterprise computer to the test lab environment and join it the LITWARE369 Azure AD domain, proceed with the following steps:
Username: LAPTOP3\AzureAdmin
Password: pass@word1
You are then automatically redirected to the on-premises identity infrastructure, i.e. the EDGE1 computer (https://adfs.litware369.com). In our configuration for the test lab environment, the AD FS sign-in page is then displayed after a successful redirection.
To verify the single sign-on with the Azure AD/Office 365 tenant, proceed with the following steps:
Like before, if single sign-on is correctly set up, you should be automatically redirected to the EDGE1 WAP computer (https://adfs.litware369.com) in our configuration for the test lab environment. The AD FS sign-in page is then displayed after a successful redirection.
Note As far as true SSO is concerned, AD FS in Windows Server 2016 is required here. As of this writing, Windows Server 2016 is a prerelease software. You can start investigating Windows Server 2016 Technical Preview 3.
If you reproduce the above experience, your Azure AD joined machine is ready to use for the rest of this document. You can skip the next section on troubleshooting.
If you do not reproduce the above experience, you can refer to the eponym subsection of the above section Adding a non-domain joined computer to the test lab environment.
You are now in a position to notably further configure the Azure Rights Management Service (RMS).
To enable Azure RMS for use in the context of our on-premises federated test lab environment for Office 365 ProPlus (or Office 2013 and Office 2016), you will need to do the following in this order:
The next sections guide you through these five additional steps.
Once you have signed up and established your organization with an account in Office 365 with a subscription that supports Rights Management, enabling the Azure RMS capabilities within the Office 365 just takes a few additional steps to enable and configure for use.
By default, Azure RMS is disabled when you sign up for your Office 365 account in Microsoft Office 365 Enterprise.
To enable the Azure Rights Management service for use your Office 365 tenant, you need to:
-or-
Note For more information, see the section Activating and configuring Rights Management of the Microsoft TechNet article What is Azure Rights Management.
Once activated, Azure RMS can be then administered via Windows PowerShell and/or through the Office 365 admin center.
Next sections describe how to active Azure RMS using either Windows PowerShell or the Office 365 admin center.
The first step consists in installing the Azure Rights Management Administration Tool.
To install the Azure Rights Management Administration module, proceed with the following steps:
Note For additional information, see the Microsoft TechNet article Installing Windows PowerShell for Azure Rights Management.
At this stage, the Azure Rights Management Administration Tool installs a set of cmdlets specifically designed for Azure RMS tenant-based administration.
Note For more information about Azure Rights Management Administration cmdlets, see the Microsoft TechNet articles Manage Azure AD using Windows PowerShell.
Each Azure Rights Management cmdlet has required and optional arguments, called parameters, that identify which objects to act on or control how the cmdlet performs its task. For more information about an Azure Rights Management cmdlet, at the Windows PowerShell command prompt, type "Get-help" and the name of the cmdlet.
Now, you need to proceed with a couple of configuration changes before being able to administer the Azure RMS settings for your Office 365 Enterprise tenant.
First connect Windows PowerShell to Azure RMS, using the following instructions:
PS C:\Windows\system32> Import-Module AADRM
PS C:\Windows\system32> Connect-AadrmService –Verbose
You will be prompted for your credentials.
Username: philber@litware369.onmicrosoft.com
Password: ****************
Note By default, global administrators are able to the Azure RMS.
Once connected, the Azure Rights Management administration module provides a set of Windows PowerShell cmdlets that provide administrative (advanced) capabilities for Azure RMS.
More especially, cmdlets enable configuring and viewing Azure RMS for an Office 365 tenant.
Note Each Azure Rights Management cmdlet has required and optional arguments, called parameters, that identify which objects to act on or control how the cmdlet performs its task. For more information about an Azure Rights Management cmdlet, at the Windows PowerShell command prompt, type "Get-help" and the name of the cmdlet.
For additional information, see the articles Administering Azure Rights Management by Using Windows PowerShell and Azure Rights Management Cmdlets.
To enable Azure RMS for your account from a Windows PowerShell command shell, proceed with the following steps:
PS C:\Windows\system32> Enable-Aadrm
PS C:\Windows\system32> Get-AadrmConfiguration
PS C:\WINDOWS\system32> Get-AadrmConfiguration BPOSId : 2971a9f9-454c-4be2-9b86-5b3513ecb22e RightsManagementServiceId : 6c8e9100-1168-4085-90f0-22293f9e5a0d LicensingIntranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensing LicensingExtranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensing CertificationIntranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/_wmcs/certification CertificationExtranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/_wmcs/certification AdminConnectionUrl : https://admin.eu.aadrm.com/admin/admin.svc/Tenants/6c8e9100-1168-4085-90f0-22293f9e5a0d AdminV2ConnectionUrl : https://admin.eu.aadrm.com/adminV2/admin.svc/Tenants/6c8e9100-1168-4085-90f0-22293f9e5a0d OnPremiseDomainName : Keys : {22327901-6fdd-4dfc-81c7-04a1eb3c1afb, a7dc9629-d474-41ff-8c1e-b17d73e3849e} CurrentLicensorCertificateGuid : a7dc9629-d474-41ff-8c1e-b17d73e3849e Templates : {72fb2c43-cc9d-43ba-a02a-3320b2a869be, 9567b5c8-217d-46d2-b529-28c3a0d1ca7d} FunctionalState : Enabled SuperUsersEnabled : Disabled SuperUsers : {} AdminRoleMembers : {} KeyRolloverCount : 0 ProvisioningDate : 20/12/2013 14:57:14 IPCv3ServiceFunctionalState : Enabled DevicePlatformState : {Windows -> True, WindowsStore -> True, WindowsPhone -> True, Mac -> True...} FciEnabledForConnectorAuthorization : True DocumentTrackingFeatureState : Enabled
For regions outside the European Union, .eu. will be replaced in the above URLs by .na. for North America, or .ap. for Asia, for instance:
e.g.: https://<RightsManagementServiceId>-rms.na.aadrm.com/_wmcs/licensing for North America
e.g.: https://<RightsManagementServiceId>-rms.ap.aadrm.com/_wmcs/licensing for Asia Pacific
PS C:\Windows\system32> Disconnect-AadrmService
After completing these steps, the tenant should be enabled.
Once activated, your Azure RMS tenant can be administered using the previous cmdlets in the Azure Rights Management Administration module and through the Office admin center.
To enable Azure RMS for your account from the Office 365 admin center (in-lieu of using the Windows PowerShell procedure described in previous section), proceed with the following steps:
After completing these steps, you tenant should be enabled.
Once activated, your Azure RMS tenant can be administered using the previous cmdlets in the Azure Rights Management Administration module and through the Office admin center.
Proceed with the following steps:
Note You can license all users at once by selecting the Unlicensed users view on the Users page, select checkboxes for all users, and then Activate synced users.
To install Office 365 ProPlus on the Windows devices, proceed with the following steps:
Username: LITWARE369\janets
Password: pass@word1
Username: LAPTOP2/AzureAdmin
Password; pass@word1
Username: LAPTOP3/AzureAdmin
Password; pass@word1
As of this writing, modern authentication is still in public preview for Office 365 and you MUST request your tenant be enabled for modern authentication so that the tenant will accept modern authentication connections.
As shortly discussed in the introduction of this document, modern authentication allows you to configure new security scenarios for sign in with Office 365. Some examples are as illustrated before:
Note The App passwords in Azure MFA - see the Microsoft TechNet article Managing your Azure Multi-Factor Authentication User Settings - were a way to exercise MFA before modern authentication. In other words, with modern authentication, you no longer need them. All Office apps using modern authentication can do "true MFA" (phone call, text etc).
Note Device Registration/Workplace Join and Azure AD Join also can be considered as a second factor and can be used as well as authentication for Azure RMS. For additional information, see the whitepaper Azure AD & Windows 10: Better Together for Work or School.
As you're aware of with the previous steps in building the test lab environment, this bullet is of special interest in the context of this document with AD FS and is and will be further illustrated with the already configured integration of MFA Server with AD FS.
The modern authentication, a.k.a. Active Directory Application Library (ADAL) based authentication stack, is available to any customer running Office 2013 and the March 2015 or later update for Office 2013, Office 2016 and Office 365 ProPlus. To benefit from RMS features and multi-factor authentication with Azure RMS, you must install the June 2015 update for Office 2013 or later.
Important note The Office 2013 March 2015 update or later update are fully production ready and supported.
Note Updates are automatically available for Office 365 ProPlus applications - users will see a pop-up screen in the product prompting them to apply the new updates. Office 2013 and Office 2016 Windows client applications are updated using Windows update.
Note For more information on feature updates, see the Office blog.
For the purpose of the document, you will need to join the program and enable your Azure AD/Office 365 tenant. To perform these operations, start by completing the Office 2013 Modern Authentication Public Preview survey.
The Guide to enrolling into Office 2013 modern authentication public preview provides a set of additional guidance.
As far as Windows devices are concerned, these new authentication features are available to you on Windows devices running:
Note OS X, iOS, and Android clients that support modern authentication are enabled by default.
Note For additional information, see the Microsoft TechNet article Requirements for Azure Rights Management.
Note With Windows 10, you may experience the issues described in the articles "Invalid provider specified" error when you use an Office 2016 application to access Office 365 resources
and "Background task activation is spurious" error when you use an Office 2016 application to access Office 365 resources.
So in our context, with Office 365 ProPlus, they MUST also be enabled on each Windows devices: LAPTOP1, LAPTOP2, and LAPTOP3. You will have to do that for the three Windows devices being used in the rest of this document.
To enable modern authentication for any Windows devices that have Office 365ProPlus or Office 2013 installed, you need to set specific registry keys on the above Windows devices:
Registry key |
Type |
Value |
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL |
REG_DWORD |
1 |
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version |
REG_DWORD |
1 |
Note For information on how to enable the feature on Windows client, see the article Enable Modern Authentication for Office 2013 on Windows devices.
To ease the configuration of the Windows devices with the above registry keys, create a modernauth.reg text file with the following content:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Common\Identity]
"EnableADAL"=dword:00000001
"Version"=dword:00000001
To set the above registry keys on the Windows devices in our configuration, proceed with the following steps:
Username: LITWARE369\roberth
Password: pass@word1
Username: LAPTOP2/AzureAdmin
Password; pass@word1
Username: LAPTOP2/User2
Password; pass@word1
Username: LAPTOP3/AzureAdmin
Password; pass@word1
The Rights Management sharing application for Windows (also known as just "the RMS sharing app") is a free, downloadable application for organizations that uses Azure RMS, and for organizations that don't have their own information protection infrastructure but want to consume content that has been protected by other organizations that use Azure RMS.
The RMS sharing app adds support for protection of any type of file. a built-in viewer for commonly used text and image file types, and more specifically in our context adds new buttons to the Microsoft Office toolbar for Word, PowerPoint, and Excel, allowing you to share RMS-protected files from within Office.
Note For more information, see the Microsoft TechNet article Rights Management Sharing Application for Windows.
You must have installed the minimum version of 1.0.1908.0, which can be confirmed by using Control Panel, Programs and Features.
This version and newer allows to use modern authentication and thus supports several multi-factor authentication solutions, for example MFA Server with AD FS as illustrated in this document.
Note For additional information, see the Microsoft TechNet article Requirements for Azure Rights Management.
To install the RMS sharing app on the Windows devices, proceed with the following steps:
Username: LITWARE369\roberth
Password: pass@word1
By downloading the software, you agree to the license terms provided at http://go.microsoft.com/fwlink/?LinkId=355394. If you do not agree to the license terms, do not download the software.
Username: LAPTOP2/AzureAdmin
Password; pass@word1
Username: LAPTOP3/AzureAdmin
Password; pass@word1
At this stage, you are finally in a position to test the Office IRM features with Azure RMS along with the modern authentication and the multi-factor authentication.
Now that we have the overall infrastructure in place for the hybrid environment, we're finally in a position to test Azure RMS with the various configuration that may relates to Windows devices with Office 365 ProPlus client applications.
So, you can test the IRM features of Office 365 ProPlus in the following configurations in any order:
The next sections guide you through these tests.
A sign-in to the Azure portal will automatically authenticate federated users with their AD FS infrastructure. For this to work, domain-joined computers will need the following:
If you successfully conducted all the previous steps as instructed, the above requirements should normally be fulfilled. You should also consider the issues outlined in the blog post Office Modern Auth & ADFS: Making it work along with their resolution path.
To test the Rights Management features on a domain-joined computer, proceed with the following steps:
Username: LITWARE369\roberth
Password: pass@word1
You should see a popup that says, "Retrieving templates from server…"
Username: LITWARE369\janets
Password: pass@word1
Et voila!
Fix: Close Word and then delete the %LocalAppData%\Microsoft\MSIPC directory. Reopen Word (which will re-bootstrap MSIPC) and the option should be there.
Fix: Open the AD FS Management console to view the Authentication Policies setting for Global Primary Authentication. Windows Authentication should be enabled for the Intranet. View the Authentication Policies settings for Global Multi-Factor Authentication. MFA should be unchecked for the Intranet.
A sign-in to the Azure portal will automatically authenticate federated users with their AD FS infrastructure. For this to work, non-domain computers will need the following:
If you successfully conducted all the previous steps as instructed, the above requirements should normally be fulfilled.
To test the Rights Management features on a non-domain joined computer, proceed with the following steps:
Username: LAPTOP2/AzureAdmin
Password; pass@word1
If not, select Connect to Rights Management Servers and get templates.
Username: LAPTOP2/User2
Password; pass@word1
Et voila!
Fix: Check that the non-domain computer has been configured to resolve the name/IP for ADFS and trust the ADFS certificate. (See the previous "Prepare the computer" section.)
Fix: Open the AD FS Management console to view the Authentication Policies setting for Global Primary Authentication. Forms Authentication should be enabled for the Extranet. View the Authentication Policies settings for Global Multi-Factor Authentication. MFA should be unchecked for the Extranet.
Fix: The user needs to do the Office sign-in (top right-hand corner) using the credentials of a federated domain user before restricting access.
Fix: The user needs to do the Office sign-in using the credentials of a federated domain user that has permissions to the document. After signing in with valid credentials, the document should open.
A sign-in to the Azure portal will automatically authenticate federated users with their AD FS infrastructure. For this to work, Azure AD joined computers will need the following:
If you successfully conducted all the previous steps as instructed, the above requirements should normally be fulfilled.
To test the Rights Management features on an Azure AD joined computer, proceed with the following steps:
Username: LAPTOP3/AzureAdmin
Password; pass@word1
Username: LAPTOP2/User2
Password; pass@word1
Et voila!
As earlier mentioned in this document, the modern authentication for Office 365 is a new authentication stack used by Office 365 ProPlus, Office 2013, and Office 2016 client applications against Office 365. This stack allows these client applications to engage in browser-based authentication with the organization's on-premises AD FS server or supported 3rd party federation server.
Important note As far as AD FS is concerned, AD FS in Windows Server 2012 R2 is required for mobile devices.
This diagram shows how these Office client applications enables user sign in.
Client applications use the ADAL-based stack to facilitate sign in with Azure AD behind Office365 services. When such an application makes a request to a services in Office 365 service, the target service in Office 365 instructs the application to visit Azure AD which speaks a simple standards based protocol: OAuth 2.0 .
Azure AD hosts for that purpose a web page where the user can sign in. An Office client application instructs ADAL to launch web browser control. The claims provider could be Azure AD or a federated claims provider like the AD FS server in the context of this paper or another supported STS (that uses for instance the SAML 2.0 protocol).
If the user is a federated user as covered in this document, Azure AD redirects the user to the sign in web page hosted by the AD FS server of record for the tenant. As already illustrated, this AD FS server is determined based on the domain as specified in the user's sign in name.
The sign in web page is shown to the user on their device and the user signs in. In the context of this paper, the AD FS server returns a SAML token to Azure AD when the user is successfully signed in. Azure AD returns a JWT token to the Office client application.
Note JWT is a compact token format (JavaScript Object Notation (JSON) Web Token). It describes a way of representing information about the user in the token that is especially apt for REST-based software. JWT use is growing, and products supporting the format are increasingly common in the industry. For additional information, see the eponym specification.
The Office client application gets back this simple JWT token that it caches for future communication with its services. It can then use this token with services in Office 365 on behalf of the user by sending it to these services.
In terms of troubleshooting, and as described in the above sections, the authentication flow of any Azure AD/Office 365 single sign-on communication is predictable. The expected authentication flow pattern can be compared to or contrasted with a capture of the actual authentication flow that occurs during a failing single sign-on attempt to determine what might be wrong with the process.
First of all, the Microsoft Remote Connectivity Analyzer can help diagnose and troubleshoot the authentication flows.
Note For more information on the tools and diagnostics available for Office 365, see the Office 365 community wiki article Tools and Diagnotics.
The Microsoft Remote Connectivity Analyzer (RCA) web site enables IT professionals to pinpoint connectivity issues by simulating connectivity from a location outside the customer environment.
To use the RCA web site to test the single sign-on authentication, proceed with the following steps:
You can then refer to the Microsoft TechNet article How to use Remote Connectivity Analyzer to troubleshoot single sign-on issues for Office 365, Azure, or Windows Intune that describes how to diagnose single sign-on (SSO) logon issues in Azure AD/Office 365 by using the RCA. It also contains information about causes of common SSO failures and lists links to resources for how to troubleshoot the issue.
The Microsoft Connectivity Analyzer tool (client)
is a downloadable companion client tool from the RCA web site. It lets both email users and IT professionals run the same tests within the user's environment. It simulates several client logon and mail flow scenarios (unless the Remote Connectivity Analyzer it helps troubleshooting specific scenarios, and provides additional capabilities of testing the on-premises AD FS infrastructure from with the corporate network as a Web application – such as OWA - would using this infrastructure for gathering the authentication token). When a test fails, many of the errors message provide troubleshooting tips to help the user or IT professional to resolve the problem.
To run the Connectivity Analyzer client to test SSO authentication, proceed with the following steps:
This conclude this whitepaper.