Configuring Azure RMS with federation on-premises for Office client applications

Introduction

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:

  • Rights Management sharing application on all platforms: Windows desktop, iOS, Android, Mac OS X, and Windows Phone.
  • Office 365 ProPlus client applications.
  • Office 2013 Windows client applications (requires an update via usual update channels).
  • Office 2016 Windows client applications.
  • Office 2016 client applications on Mac OS X.
    • Office client applications on iOS and Android mobile devices.

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:

  • Multi-factor authentication (MFA) for Office client applications. With the new ADAL-based modern authentication in the Rights Management client applications, your users can sign in using true MFA.

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.

  • SAML-based supported STS sign in. Now, with the modern ADAL-based authentication flow, your users can sign in even when using an identity provider that uses SAML 2.0, for example, one of supported third party federation servers previously mentioned.
  • Smart card and certificate-based authentication. With AD FS or one of the supported third-party federation servers) on-premises, you may elect to configure your users to sign in with smart card/certificate-based authentication. In this configuration, your users are not required to enter their user name and password. Instead, they use smart cards (physical or virtual) for authentication.

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.

Objectives of the paper

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:

  • An AD FS-based federation identity infrastructure will be used on-premises for the single sign-on with Office 365.
  • The aforementioned Azure AD Connect tool will be used to configure such an AD FS infrastructure.
  • And this infrastructure will then use Azure Multi-Factor Authentication Server (MFA Server) to enable multi-factor authentication, and demonstrate how Azure RMS supports it.

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.

Non-objectives of the paper

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.)

Organization of this paper

To cover the aforementioned objectives, this document is organized in the following four sections:

  • Building a test lab environment.
  • Preparing Azure RMS.
  • Testing Azure RMS.
  • Understanding and troubleshooting the authentication flows.

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.

About the audience

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.

Building a test lab environment

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.

Provisioning an Office 365 subscription

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.

Building an on-premises test lab environment

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:

  • In the cloud, an Azure AD/Office 365 tenant that you've already provisioned as per previous section,
  • In the on-premises, Windows Server Active Directory (WS AD), Active Directory Certificate Services (AD CS), Active Directory Federation Services (AD FS), and Internet Information Services (IIS), to name a few - and the related required configuration.

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:

  • One computer running Windows Server 2012 R2 (named DC1 by default) that is configured as a domain controller with a test user and group accounts, and Domain Name System (DNS) server.
  • One intranet member server running Windows Server 2012 R2 (named ADFS1 by default) that is configured as an enterprise root certification authority (PKI server), the synchronization engine and an AD FS federation server. The MFA Server and MFA SDK are also installed on the AD FS federation server.
  • One Internet-facing member server running Windows Server 2012 R2 (named EDGE1 by default) that is configured as a Web Application Proxy (WAP) server for the intranet ADFS1 federation server. The MFA User portal and the MFA Server Mobile App Web service are also installed on the WAP server.

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:

  • A first subnet (10.0.1.0/24) that will expose the test lab resources that require Internet connectivity/endpoint(s). It is separated from a second subnet that hosts the corporate intranet resources. The computer on this subnet is EDGE1.
  • A second subnet (10.0.2.0/24) that simulates a private intranet. Computers on the Subnet2 subnet are DC1 and ADFS1.

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:

  1. From within the Azure management portal, select VIRTUAL MACHINES on the left pane.
  2. Under VIRTUAL MACHINE INSTANCES, select edge1 and then click SHUTDOWN at the tray of the bottom.
  3. Repeat step 2 with adfs1, and then dc1.
  4. Once all the allocated resources will be deallocated, the status of the VMs will then change to Stopped (Deallocated).

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:

  1. From within the Azure management portal, select VIRTUAL MACHINES on the left pane.
  2. Under VIRTUAL MACHINE INSTANCES, select dc1 and then click START at the tray of the bottom.
  3. Click dc1, and then select DASHBOARD.

  1. Verify under quick glance that the INTERNAL IP ADDRESS is set to 10.0.2.4 in our configuration.
  2. Select adfs1 on the left and then click START at the tray of the bottom.
  3. Repeat step 5 with edge1.

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.

Adding a domain-joined computer to the test lab

Deploying a domain-joined computer

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:

  1. Open a browsing session and navigate to the Azure management portal at https://manage.windowsazure.com.
  2. Sign in with your MSDN subscription account.
  3. Click VIRTUAL MACHINE workspace on the left pane, and then click NEW to start the process of deploying a VM interactively.

  1. Click either QUICK CREATE or FROM GALLERY. With QUICK CREATE, pick IMAGE and click More images… at the bottom to bring up the image gallery.

Or FROM GALLERY, bring up the image gallery directly. A CREATE A VIRTUAL MACHINE dialog shows up.


  1. From the image gallery, select MSDN and scroll down to select Windows 8.1 Enterprise N (x64).

  1. Click the arrow icon at the bottom right to proceed with the deployment process.

  1. Specify the VM configuration:
    1. In VIRTUAL MACHINE NAME, specify a name for the VM, for example in our illustration "laptop1".
    2. In SIZE, select for instance A0 (shared core, 768 MB memory) or A1 (1 core, 1.75 GB memory) to minimize your credit consumption that relates to the VM.
    3. In NEW USER NAME, specify a name, for instance in our illustration "AzureAdmin".
      1. In NEW PASSWORD and CONFIRM, specify a password for the account, for example in our illustration "Pass@word1".
  2. Click the arrow icon at the bottom right.

  1. In CLOUD SERVICE, select mfalabsvc. You can then select the Subnet2 of the test lab environment.
  2. In VIRTUAL NETWORK SUBNETS, select mfalabvnet-subnet2(10.0.2.0/24).

  1. Click the arrow icon at the bottom right.

  1. VM AGENT, CONFIGURATION EXTENSIONS, and SECURITY EXTENSIONS are available. Ensure Install the VM agent is checked, and then click the checkmark icon at the bottom right to start the deployment.
  2. Once provisioned and started, click CONNECT at the bottom of the tray, and then open the remote desktop .rdp file. A Windows Security dialog pops up.
  1. Enter the credentials of the above local account you specified, for example in our configuration:

    Username: LAPTOP1\AzureAdmin

    Password: pass@word1

    1. On the taskbar of the Windows 8.1 Desktop, click the File Explorer icon, right-click This PC, and then select Properties. A System window shows up.

  1. Under Computer name, domain, and workgroup settings, click Change settings. A classic System Properties dialog pops up.

  1. Click Change... A classic Computer Name/Domain Changes dialog pops up.

  1. Select Domain, type "LITWARE369", and then click OK. A Windows Security dialog pops up.

  1. Enter the credentials of a LITWARE369 domain administrator, for example in our configuration:

Username: LITWARE369\AzureAdmin

Password: pass@word1

  1. Click OK to join the machine to the LITWARE369 domain. A Computer Name/Domain Changes dialog pops up.

  1. Click OK. Another Computer Name/Domain Changes dialog pops up.

  1. Click OK to restart.

Allowing additional users to connect remotely

To add additional users to connect remotely, proceed with the following steps once the LAPTOP1 computer has rebooted:

  1. Open a new remote desktop connection on the LAPTOP1 computer with the AzureAdmin account credentials:

    Username: LITWARE369\AzureAdmin

    Password: pass@word1

  2. On the taskbar of the Windows 8.1 Desktop, click File Explorer icon, right-click This PC, and then select Properties. A System window shows up.

  1. Click Remote settings. A System Properties dialog opens up.

  1. Click Select Users… A Remote Desktop Users dialog opens up.

  1. Click Add…

  1. In Enter the object names to select, type "Roberth; JanetS", and the click Check Names. These two alias should respectively resolve to Robert Hatley and Janet Schorr.

  1. Click OK three times to close all the open dialogs.
  2. Close the remote session on LAPTOP1.

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.

Verifying the single sign-on capabilities

To verify the single sign-on with the Azure AD/Office 365 tenant, proceed with the following steps:

  1. Open a remote desktop connection on the LAPTOP1 computer as the Janet Schorr account credentials:

Username: LITWARE369\JanetS

Password: pass@word1

  1. Open a browsing session and navigate to the Office 365 portal at https://portal.office.com.

  1. Type "janets@litware369.com" to sign in as the Janet Schorr account name, and press ENTER.

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.

  1. Close the remote desktop connection.

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.

Troubleshooting the experience if needed

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.

  • Issue: During sign-in, a Windows Security prompt asks for a password for the Janet Schorr account name.

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.

  • Issue: Sign-on fails with HTTP 400 bad request (unable to connect to the web server, the webpage could not be found because of a problem with the address).

    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$

  • Issue: Sign-in fails with "An error occurred. Contact your administrator for more details." The error details refer to the relying party Azure AD.

    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.

    • Issue: When signing in using Internet Explorer, the sign-on prompts for a password.

      Fix: Open the AD FS Management console to view the Authentication Policies for Global Primary Authentication. Windows Authentication should be enabled for the Intranet.

    • Issue: After entering the password, you see this: "For security reasons, we require additional information to verify your account. Select a certificate that you want to use for authentication. If you cancel this operation, please close your browser and try again."

      Fix: Open the AD FS Management console to view the Authentication Policies settings for Global Multi-Factor Authentication.

    • Issue: When signing on using Chrome in lieu Internet Explorer as illustrated above, the sign-in prompts for a password.

      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.

Adding a non-domain joined computer to the test lab

Deploying a non-domain joined computer

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:

  1. In step 7, specify a name for the virtual machine, for example "laptop2".
  2. In step 8, specify a name in CLOUD SERVICE DNS NAME, for example in our configuration "mfalab-laptop2". Leave the other fields as they are.

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.

Verifying the single sign-on capabilities

To verify the single sign-on with the Azure AD/Office 365 tenant, proceed with the following steps:

  1. Open a remote desktop connection on the LAPTOP2 computer as a local user:

Username: LAPTOP2\AzureAdmin

Password: pass@word1

  1. Open a browsing session and navigate to the Office 365 portal at https://portal.office.com.


  1. Type "roberth@litware369.com" to sign in as the Robert Hatley account name, and press ENTER.

    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.

  1. Type the password of the user, for example, in our illustration "pass@word1".
  2. Click Sign in. If you followed the suggested steps to build the test lab environment, you configured the Robert Hatley account to require a multi-factor authentication. A screen appears inviting you to do so. This is where the MFA Server integration with AD FS kicks in.

  1. Click Continue and proceed with the multi-factor authentication. Once successfully authenticated, you're then redirected back to the portal. At the end of the process, you should have a seamless access to the signed in user settings in Office 365.

Robert Hatley is not yet licensed to Office 365 Enterprise.

  1. Close the remote desktop connection.

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.

Troubleshooting the experience if needed

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.

  • Issue: Sign-in fails with "This page can't be displayed. Make sure the web address https://adfs.litware369.com is correct."

    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.

  • Issue: Sign-in fails with "There is a problem with this website's security certificate. The security certificate presented by this website was not issued by a trusted certificate authority."

    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:

    • Click Continue to this website (not recommended) to continue the sign-in.
    • To avoid this error when signing on, add the root certificate of this SSL/TLS certificate to the Trusted Root certificates store on the non-domain joined computer.
  • Issue: Sign-in fails with "An error occurred. Contact your administrator for more details." The error details refer to the relying party, Azure AD.

    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.

  • Issue: After entering the password, you see this: "For security reasons, we require additional information to verify your account. Select a certificate that you want to use for authentication. If you cancel this operation, please close your browser and try again."

    Fix: Open the AD FS Management console to view the Authentication Policies settings for Global Multi-Factor Authentication.

Adding another local user

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:

  1. Right-click This PC, and then select Manage. A Computer Management windows opens up
  2. Expand Local Users and Groups.
  3. Click Users.
  4. In the Actions pane, click More Actions, and then select New User… A New User dialog opens up.

  1. In User name, type "User2".
  2. In Password and Confirm password, type "pass@word1".
  3. Uncheck User must change password at next logon.
    1. Click Create, and then Close.
  1. Right-click the newly created user and select Properties. A User2 Properties dialog opens up.
  2. Click Member Of, and then select Add… A Select Groups dialog opens up.

  1. Type "Administrators", and then click Check Names.
  2. Click OK.

  1. Click OK.

Adding an Azure AD joined computer to the test lab

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.

Deploying an Azure AD joined computer

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:

  1. Repeat the steps 1 to 12 of the section Deploying a domain-joined computer along with the following adaptations:
    1. In step 5, select Windows 10 Enterprise (x64).
      1. In step 7, for the VM configuration:
        1. In VERSION RELEASE DATA, select 7/30/2015.
          1. In VIRTUAL MACHINE NAME, specify a name for the VM, for example in our illustration "laptop3".

  1. In step 8, specify a name in CLOUD SERVICE DNS NAME, for example in our configuration "mfalab-laptop3". Leave the other fields as they are.
  1. Once provisioned and started, 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: LAPTOP3\AzureAdmin

Password: pass@word1

  1. Once you arrive at the desktop with the local account, you need to join Azure AD. Open the Start menu, and then select Settings. The Settings dialog opens up.
  2. Select Settings > System > About.

  1. Click Join Azure AD. An eponym dialog opens up.

  1. Click Next. Allow it to spin and move to the next eponym page.

  1. For the purpose of this document, type "roberth@litware369.com" to sign in as the Robert Hatley account name, and then press ENTER.

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.

  1. Type the password of the user, for example, in our illustration "pass@word1".
  2. Click Sign in. As before with the Robert Hatley account, a screen appears inviting you to do a multi-factor authentication using MFA Server.

  1. Click Continue and proceed with the multi-factor authentication. Once successfully authenticated, the computer is now about to be enrolled. A Make sure this is your organization dialog pops up.

  1. Click Join to confirm.

  1. Once enrolled, the device has joined the organization.

  1. Click Finish.

Verifying the single sign-on capabilities

To verify the single sign-on with the Azure AD/Office 365 tenant, proceed with the following steps:

  1. From the above current remote desktop connection on the LAPTOP3 computer as the Robert Hatley account name, open a browsing session and navigate to the Office 365 portal at https://portal.office.com.

  1. Type "roberth@litware369.com" to sign in as the Robert Hatley account name, and press ENTER.

    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.

  2. Type the password of the user, for example, in our illustration "pass@word1".

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.

  1. Click Sign in. Like before, a screen appears inviting you to do a multi-factor authentication.
  2. Click Continue and proceed with the multi-factor authentication. Once successfully authenticated, you're then redirected back to the portal. At the end of the process, you should have a seamless access to the signed in user settings in Office 365.

  1. Close the remote desktop connection.

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.

Troubleshooting the experience if needed

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).

Preparing Azure 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:

  • Activating Azure RMS.
  • Licensing users for Azure RMS.
  • Installing Office 365 ProPlus on the Windows devices.
  • Enabling the modern authentication for Office 365.
  • Installing the RMS sharing app on the Windows devices.

The next sections guide you through these five additional steps.

Activating Azure RMS

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-

  • Use the Azure RMS from Windows PowerShell.
    • First connect to the Azure RMS from Windows PowerShell with the Azure Rights Management Administration Tool. This tool installs the Azure Rights Management module that provides cmdlets to enable an administrator to manage and configure Azure RMS features.
    • And then enable it for use by using the Enable-Aadrm cmdlet provided by the above Azure Rights Management module.

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.

Activating Azure RMS using Windows PowerShell

The first step consists in installing the Azure Rights Management Administration Tool.

Installing Windows PowerShell for Azure RMS

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.

  1. If not running on Windows 10, the Microsoft Online Services Sign-In Assistant (SIA) 7.0 must be prior installed in order to use the Azure AD Module for Windows PowerShell.
    1. Open a browsing session and download the SIA package (msoidcli_64bit.msi) from the following link: Microsoft Online Services Sign-In Assistant for IT Professionals RTW.

  1. Click Run to install. The wizard Microsoft Online Services Sign-in Assistant Setup pops up. Follow the steps of the wizard.
  1. Download the Azure Rights Management Administration Tool 64-bit package (WindowsAzureADRightsManagementAdministration_x64.exe) from the following link: http://www.microsoft.com/en-us/download/details.aspx?id=30339.

  1. Click Run to install. The Azure Rights Management Administration Setup wizard pops up. Follow the steps of the wizard.

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.

Connecting Windows PowerShell to the Azure RMS

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:

  1. Open a 64-bit elevated Windows PowerShell command prompt.
  2. Then import the module and connect to the Azure Rights Management service for your Office 365 Enterprise tenant by typing the following commands:

PS C:\Windows\system32> Import-Module AADRM

PS C:\Windows\system32> Connect-AadrmService –Verbose

You will be prompted for your credentials.

  1. Enter your Office 365 Enterprise credentials (the set of credentials should have Global Administrator privilege) and wait to be authenticated. In the Windows PowerShell Credential Request window that opens up, provide the credentials for the Office 365 Enterprise global administrator account such as:

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.

Enabling Azure RMS

To enable Azure RMS for your account from a Windows PowerShell command shell, proceed with the following steps:

  1. Connect Windows PowerShell to Azure Rights Management as previous section.
  2. In the elevated Windows PowerShell command prompt window, type the following command for enabling Azure RMS with the Office 365 Enterprise tenant.

PS C:\Windows\system32> Enable-Aadrm

  1. View the current configuration for the tenant by running Get-AadrmConfiguration cmdlet:

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

  1. Close the connection with Azure RMS.
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.

Activating Azure RMS from the Office 365 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:

  1. Open a browsing session and navigate to the Office 365 admin center at https://portal.microsoftonline.com.
  2. Sign-in with as an administrator of the subscription to configure.
    1. If the Office 365 admin center is not visible, open the apps launcher in the top left corner.

  1. Select Admin.
  1. In the left pane of the admin center, expand SERVICE SETTING and select Rights Management.

  1. Under Protect your information, click Manage.

  1. Under rights Management, click activate.

  1. When prompted Do you want to activate Rights Management?, click activate. Azure RMS is being activated.

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.

Licensing users for Azure RMS

Proceed with the following steps:

  1. Log into Office 365 at https://portal.microsoftonline.com with your admin credentials.
  2. If the admin center is not visible, open the apps launcher in the top left corner and select Admin.
  3. Still in the left pane of the admin center, expand USERS and select Active Users. You should see your two domain users Janet Schoor and Robert Hatley listed as "Synced with Active Directory."
  4. Select a Janet Schorr's checkbox and then select Edit under Assigned license to give her a Microsoft Office 365 Plan E3 license and Save.

  1. Repeat above step to license Robert Hatley.

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.

Installing Office 365 ProPlus on the Windows devices

To install Office 365 ProPlus on the Windows devices, proceed with the following steps:

  1. Open a new remote desktop connection on the LAPTOP1 domain-joined computer with the Janet Schorr account credentials:

    Username: LITWARE369\janets

    Password: pass@word1

  2. As before, open a browsing session and navigate to the Office 365 portal at https://portal.office.com.

  1. Click janets@litware369.com to sign in as the Janet Schorr account name.

  1. Next to Install Office on your PC, click Install now. You're redirected to a new page.
  2. Under Install the latest version of Office, click Install.

  1. Click Run to start the setup. A User Account Control dialog pops up.

  1. Click Yes. The Office installation starts in the background.
  2. A Welcome to your new Office shows up.

  1. Click Next and complete (the steps of) the wizard. Click All done! at the end to close the wizard.
  2. After the installation completes, sign out of the portal and close the remote desktop connection.
  3. Open a new remote desktop connection on the LAPTOP2 non-domain joined computer as a local user, for example in our configuration:

    Username: LAPTOP2/AzureAdmin

    Password; pass@word1

  4. Repeat steps 2 to 10 with the Robert Hatley account.
  5. Open a new remote desktop connection on the LAPTOP3 Azure AD joined computer as a local user, for example in our configuration:

    Username: LAPTOP3/AzureAdmin

    Password; pass@word1

  6. Repeat steps 2 to 10 with the Robert Hatley account.

Enabling the modern authentication for Office 365

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:

  • Multi-factor authentication (MFA) in the cloud with Azure MFA or with on-premises solutions when single sign-on, a.k.a. federation, is used with Office 365.

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.

  • Smart card and certificate-based authentication.

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.

Enabling the modern authentication on your tenant

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.

Enabling the new authentication features on the Windows devices

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.

  • Office 365 ProPlus, but is disabled by default.
  • The March 2015 or later update for Office 2013 but is disabled by default. To benefit from RMS features and multi-factor authentication with Azure RMS, you must install the June 2015 update for Office 2013 or later.

Note     For additional information, see the Microsoft TechNet article Requirements for Azure Rights Management.

  • Office 2016 and later is enabled by default.

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:

  1. As before, open a new remote desktop connection on the LAPTOP1 domain-joined computer with the Janet Schorr account credentials:

    Username: LITWARE369\roberth

    Password: pass@word1

  2. Copy the modernauth.reg file to the desktop.
  3. Double-click the file to modify the Registry. A User Account Control dialog pops up.

  1. Click Yes. A Registry Editor dialog pops up.

  1. Click Yes. Another dialog pops up.

  1. Click OK and close the session.
  2. Repeat steps 1 to 6 with the Robert Hatley account.
  3. Open a new remote desktop connection on the LAPTOP2 non-domain joined computer as a local user, for example in our configuration:

    Username: LAPTOP2/AzureAdmin

    Password; pass@word1

  4. Repeat steps 2 to 6.
  5. Open a new remote desktop connection on the LAPTOP2 non-domain joined computer as a local user, for example in our configuration:

    Username: LAPTOP2/User2

    Password; pass@word1

  6. Repeat steps 2 to 6.
  7. Open a new remote desktop connection on the LAPTOP3 Azure AD joined computer as a local user, for example in our configuration:

    Username: LAPTOP3/AzureAdmin

    Password; pass@word1

  8. Repeat steps 2 to 6.

Installing the RMS sharing app on the Windows devices

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:

  1. As before, open a new remote desktop connection on the LAPTOP1 domain-joined computer with the Janet Schorr account credentials:

    Username: LITWARE369\roberth

    Password: pass@word1

  2. Open a browsing session and download the RMS sharing app (version 1.0.1908.0) (setup.exe)
    from the following link: http://www.microsoft.com/en-US/download/details.aspx?id=40857.

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.

  1. Click Run to install the RMS sharing app. A User Account Control dialog pops up.

  1. Click Yes. A Setup Microsoft RMS wizard pops up.

  1. Click Next.

  1. Click Restart.
  2. Open a new remote desktop connection on the LAPTOP2 non-domain joined computer as a local user, for example in our configuration:

    Username: LAPTOP2/AzureAdmin

    Password; pass@word1

  3. Repeat steps 2 to 6.
  4. Open a new remote desktop connection on the LAPTOP3 Azure AD joined computer as a local user, for example in our configuration:

    Username: LAPTOP3/AzureAdmin

    Password; pass@word1

  5. Repeat steps 2 to 6.

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.

Testing Azure RMS

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:

  • Office 365 ProPlus running on a domain-joined Windows device.
  • Office 365 ProPlus running on a non-domain joined Windows device.
  • Office 365 ProPlus running on an Azure AD joined
    Windows 10 device.

The next sections guide you through these tests.

Testing Rights Management in Office (domain-joined computer)

Preparing the computer

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:

  • Name/IP resolution for the AD FS server(s). This is likely provided by your organization's DNS. If not, map the AD FS IP address to the AD FS endpoint name (for example adfs.litware369.com in our illustration) in the hosts file on the local Windows computer.
  • Trust of the AD FS SSL/TLS certificate. Confirm that the root CA certificate that the SSL/TLS certificate chains to has been added to the Trusted Root certificates store on the local Windows computer.
  • IE trust of the AD FS endpoint. Add the endpoint (for example https://adfs.liware369.com in our illustration) to the Intranet sites list in Internet Explorer.

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.

Testing Rights Management

To test the Rights Management features on a domain-joined computer, proceed with the following steps:

  1. Open a new remote desktop connection on the LAPTOP1 Windows 8.1 domain-joined computer with the Robert Hatley account credentials:

    Username: LITWARE369\roberth

    Password: pass@word1

  2. Launch Word. A First things first dialog shows up.

  1. Select Use recommended settings and then click Accept. A Welcome to your new Office shows up.

  1. Click Next and complete (the steps of) the wizard. Click All done! at the end to close the wizard.

  1. Click Blank document to create a new document.
  2. Enter some text, for example enter "=lorem(12)" and press ENTER. Save the document to the local Users\Public\Public Documents folder.
  3. If an exclamation mark appears before Robert Hatley's name in the top right-hand corner),
    1. Click Robert Hatley, and then select Switch Account.
    2. Click SIGN OUT and close the dialog.
      1. Select Sign-in (in the top right-hand corner).

  1. Enter Robert Hatley's email address (roberth@litware369.com) and click Next.

  1. Enter Robert Hatley's password and click Sign in.

  1. Click Continue. You're signed in.
  1. Select FILE > Info > Protect Document > Restrict Access > Connect to Rights Management Servers and get templates.

You should see a popup that says, "Retrieving templates from server…"

  1. Re-select Protect Document >> Restrict Access. You should see a list of restricted access options that includes a couple of templates:
    1. 'Restricted Access'.
    2. 'Litware369 – Confidential'.
    3. 'Litware369 – Confidential View Only'.

  1. Select one of the templates, for example 'Litware369 – Confidential'. The document should indicate that it is now protected.

  1. Save the file and log off.
  2. Open a new remote desktop connection on the same LAPTOP1 computer with the Janet Schoor account credentials:

    Username: LITWARE369\janets

    Password: pass@word1

  3. Launch Word and select to open the document created by Robert Hatley. The document should open automatically, displaying Robert Hatley's text and indicating that it is protected with the template that Robert Hatley selected.

  1. Click View Permission…

Et voila!

Troubleshooting the experience if needed

  • Issue: When I select the Restrict Access menu, the Connect to Rights Management Servers and get templates is not there.

    Fix: Close Word and then delete the %LocalAppData%\Microsoft\MSIPC directory. Reopen Word (which will re-bootstrap MSIPC) and the option should be there.

  • Issue: A warning appears on the Sign-in option in Word that says: "ACCOUNT ERROR. Sorry we can't get to your account right now. To fix this, please sign in again." When I sign in again, another error says: "We can't sign you into your company portal because something on the server isn't configured correctly. Please contact your network administrator."

    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.

Testing Rights Management in Office (non-domain joined computer)

Preparing the computer

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:

  • Name/IP resolution for the AD FS server(s). Azure will send authentication requests from non-domain computers to your Internet-facing WAP server. WAP will then redirect these requests to your internal AD FS servers.
    • Register the AD FS URL in your extranet DNS so that it resolves correctly. (Short-term workaround: Map the WAP server's IP address to the AD FS endpoint in the hosts file on the non-domain computer.
    • You will also need to allow traffic on port 443 through the firewall to the WAP.
  • Trust of the AD FS SSL/TLS certificate. Add the root CA certificate that the SSL/TLS certificate chains to the Trusted Root certificates store on the local computer.
  • IE trust of the AD FS endpoint. Add the endpoint (for example https://adfs.litware369.com in our illustration) to the Local intranet sites list in Internet Explorer.

If you successfully conducted all the previous steps as instructed, the above requirements should normally be fulfilled.

Testing Rights Management

To test the Rights Management features on a non-domain joined computer, proceed with the following steps:

  1. Open a new remote desktop connection on the LAPTOP2 Windows 8.1 non-domain computer as a local user, for example in our configuration:

    Username: LAPTOP2/AzureAdmin

    Password; pass@word1

  2. Launch Word.

  1. Click Blank document to create a new document.
  2. Enter some text, for example enter "=lorem(12)" and press ENTER. Save the document to the local Users\Public\Public Documents folder.
  3. Select Sign-in (in the top right-hand corner).

  1. Enter Robert Hatley's email address (roberth@litware369.com) and click Next.

  1. Enter Robert Hatley's password and click Sign in.

  1. Click Continue. You're signed in.
  2. Select FILE > Info > Protect Document > Restrict Access. You should see a list of restricted access options that includes templates, for example in our illustration: 'Litware369 – Confidential'.

If not, select Connect to Rights Management Servers and get templates.

  1. Select one of the templates, for example 'Litware369 – Confidential'. The document should indicate that it is now protected.

  1. Save the file and log off.
  2. Open a new remote desktop connection on the same LAPTOP1 computer as another local user, for example in our configuration:

Username: LAPTOP2/User2

Password; pass@word1

  1. Launch Word. A First things first dialog shows up.
  2. Select Use recommended settings and then click Accept. A Welcome to your new Office shows up.

  1. Click Next.

  1. Click Sign in. A Sign in dialog opens up.

  1. Enter Janet Schorr's email address (janets@litware369.com) and click Next.

  1. Enter Janet Schorr's password and click Sign in.
  2. Back to the wizard, complete (the steps of) the wizard. Click All done! at the end to close the wizard.
  3. Select to open the document created by Robert Hatley. The document should open automatically, displaying Robert Hatley's text and indicating that it is protected with the template that Robert Hatley selected.

  1. Click View Permission…

Et voila!

Troubleshooting the experience if needed

  • Issue: When I enter my username and password for the Office sign-in, I get this error: "We are unable to connect right now. Please check your network and try again later."

    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.)

  • Issue: When I enter my username and password for the Office sign-in, I get this error: "We can't sign you into your company portal because something on the server isn't configured correctly. Please contact your network administrator."

    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.

  • Issue: An error occurs when Connect to Rights Management Servers and get templates is selected: "Your machine isn't set up for Information Rights Management (IRM). To set up IRM, sign in to Office, open an existing IRM protected message or document, or contact your help desk."

    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.

  • Issue: An error occurs when opening the protected document: "You do not have permission to open this document. Do you want to open it using a different set of credentials?"

    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.

Testing Rights Management in Office (Azure AD joined computer)

Preparing the computer

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:

  • Name/IP resolution for the AD FS server(s). Azure will send authentication requests from Azure AD joined computers to your Internet-facing WAP server. WAP will then redirect these requests to your internal AD FS servers.
    • Register the AD FS URL in your extranet DNS so that it resolves correctly. (Short-term workaround: Map the WAP server's IP address to the AD FS endpoint in the hosts file on the Azure AD joined computer.
    • You will also need to allow traffic on port 443 through the firewall to the WAP.
  • Trust of the AD FS SSL/TLS certificate. Add the root CA certificate that the SSL/TLS certificate chains to the Trusted Root certificates store on the local computer.
  • IE trust of the AD FS endpoint. Add the endpoint (for example https://adfs.litware369.com in our illustration) to the Local Intranet list in Internet Explorer.

If you successfully conducted all the previous steps as instructed, the above requirements should normally be fulfilled.

Testing Rights Management

To test the Rights Management features on an Azure AD joined computer, proceed with the following steps:

  1. Open a new remote desktop connection on the LAPTOP3 Windows 10 Azure AD joined computer as a local user, for example in our configuration:

    Username: LAPTOP3/AzureAdmin

    Password; pass@word1

  2. Launch Word.

  1. Click Blank document to create a new document.
  2. Enter some text, for example enter "=lorem(12)" and press ENTER. Save the document to the local Users\Public\Public Documents folder.
  3. Select Sign-in (in the top right-hand corner).

  1. Enter Robert Hatley's email address (roberth@litware369.com) and click Next.

  1. Enter Robert Hatley's password and click Sign in.

  1. Click Continue. You're signed in.
  2. Select FILE > Info > Protect Document > Restrict Access. You should see a list of restricted access options that includes templates, for example in our illustration: 'Litware369 – Confidential'. If not, select Connect to Rights Management Servers and get templates.

  1. Select one of the templates, for example 'Litware369 – Confidential'. The document should indicate that it is now protected.

  1. Save the file.
  2. Launch Outlook. A Welcome to Outlook 2013 wizard opens up.

  1. Click Next.

  1. In the Add an Email Account page, keep Yes selected and click Next.

  1. In the Auto Account Setup page:
    1. Keep E-mail Account selected.
    2. In Your Name, type "Robert Hatley".
    3. In E-mail Address, type "roberth@litware369.com"
    4. In Password and Retype Password, type "pass@word1".
      1. Click Next.

  1. In the Searching for your email server settings… page, click Finish.
  2. Now in Outlook, in HOME, click New Email. A new window opens up.

  1. In To, type "janets@litware369.com".
  2. In Subject and in the body of the mail, type some text.
  3. Select MESSAGE > Attach File and attached the previously created document in step 11.
    1. Select OPTIONS > Permission. You should see the same list of restricted access options that includes the above templates, for example in our illustration: 'Litware369 – Confidential'.

  1. Select one of the templates, for example 'Litware369 – Confidential'. The document should indicate that it is now protected.

  1. Click Send.
  2. Once sent, close Outlook and log off.
  3. Open a new remote desktop connection on the same LAPTOP1 computer as another local user, for example in our configuration:

Username: LAPTOP2/User2

Password; pass@word1

  1. Launch Outlook.
  2. Repeat steps 12 to 16 for Janet Schoor.
  3. Now in Outlook, open the message received from Robert Hatley.
  4. Janet Schorr's password ("pass@word1") and click Sign in. Once authenticated, you're redirected back to your mailbox.

  1. Open the attached document created by Robert Hatley. The document should open automatically, displaying Robert Hatley's text and indicating that it is protected with the template that Robert Hatley selected.

  1. Click View Permission…

Et voila!

Understanding and troubleshooting the authentication flows

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.

Troubleshooting the authentication flows

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:

  1. Open a browsing session and navigate to https://www.testconnectivity.microsoft.com/?testid=SingleSignOn.

  1. Enter your credentials, click to select the security acknowledgement check box, type the verification code, and then click Perform Test.

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:

  1. Open a browsing session and navigate to the RCA web site at https://www.testconnectivity.microsoft.com.
  2. Click Client.

  1. Click Install Now to launch the Click-Once installation (http://go.microsoft.com/fwlink/?LinkID=313782). The Microsoft Connectivity Analyzer dialog opens up.

  1. Click I can't set up federation with Office 365, Azure, or other services that use Azure Active Directory.

  1. Enter your credentials, and then click next to start running the diagnostics.

This conclude this whitepaper.