configuring azure rms with federation on-premises for ... web view2 configuring azure rms with...

Configuring Azure RMS with federation on-premises for Office client applicationsOverview Technical ArticleMicrosoft FrancePublished: October 2015Version: 1.0Authors: Philippe Beraud (Microsoft France)Contributors/Reviewers: Philippe Maurent, Sergey Simakov (Microsoft Corporation)

For the latest information on RMS, please see www.microsoft.com/rms

Copyright © 2015 Microsoft Corporation. All rights reserved.

Abstract: Due to increased regulation, the Consumerization of IT (CoIT), and the “Bring Your Own Device” (BYOD), the explosion of information with dispersed enterprise data, the Social Enterprise, etc. organizations of all sizes are facing growing needs to protect sensitive information. At the same time, organizations have a need to securely share that same information amongst appropriate employees and other individuals within and outside the corporate network. In such a context, the Microsoft Azure Rights Management (RMS) service technology provides the capability to create and consume protected content such as e-mail and documents. Such a capability is notably part of the Office 365 Enterprise and Education subscriptions, natively integrated 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.In addition, thanks to the modern authentication in Office 365, Azure RMS can now work better hand by hand with federation on-premises for Office client applications. This new capability also allows to perform a multi-factor authentication if you want to. This document is intended to help you evaluating this newly introduced capability. For that purpose, it provides step-by-step information on how to configure and use Azure RMS to perform content protection on your corporate Office document in conjunction with federation on-premises, as well as other details and requirements you would need to successfully evaluate Azure RMS in a federated environment like this.

This document is intended for system architects and IT professionals who are interested in understanding and evaluating this interesting new capability.

Table of ContentsFEEDBACK.........................................................................................................3INTRODUCTION..................................................................................................4

OBJECTIVES OF THE PAPER.................................................................................................8NON-OBJECTIVES OF THE PAPER..........................................................................................9ORGANIZATION OF THIS PAPER............................................................................................9ABOUT THE AUDIENCE.....................................................................................................10

BUILDING A TEST LAB ENVIRONMENT................................................................11PROVISIONING AN OFFICE 365 SUBSCRIPTION......................................................................11BUILDING AN ON-PREMISES TEST LAB ENVIRONMENT..............................................................11ADDING A DOMAIN-JOINED COMPUTER TO THE TEST LAB.........................................................17ADDING A NON-DOMAIN JOINED COMPUTER TO THE TEST LAB..................................................30ADDING AN AZURE AD JOINED COMPUTER TO THE TEST LAB...................................................35

PREPARING AZURE RMS....................................................................................44ACTIVATING AZURE RMS................................................................................................44LICENSING USERS FOR AZURE RMS...................................................................................51INSTALLING OFFICE 365 PROPLUS ON THE WINDOWS DEVICES...............................................52ENABLING THE MODERN AUTHENTICATION FOR OFFICE 365....................................................55INSTALLING THE RMS SHARING APP ON THE WINDOWS DEVICES.............................................58

TESTING AZURE RMS........................................................................................62TESTING RIGHTS MANAGEMENT IN OFFICE (DOMAIN-JOINED COMPUTER)...................................62TESTING RIGHTS MANAGEMENT IN OFFICE (NON-DOMAIN JOINED COMPUTER).............................68TESTING RIGHTS MANAGEMENT IN OFFICE (AZURE AD JOINED COMPUTER)...............................75

UNDERSTANDING AND TROUBLESHOOTING THE AUTHENTICATION FLOWS..........83TROUBLESHOOTING THE AUTHENTICATION FLOWS.................................................................84

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

FeedbackFor any feedback or comment regarding this document, please send a mail to [email protected].


mailto:[email protected]

IntroductionThe 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 section1 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)2 for directory synchronization as well as single sign-on, a.k.a. federation, with Active Directory Federation Services (AD FS) if you want to.

1 REQUIREMENTS FOR AZURE RIGHTS MANAGEMENT: https://technet.microsoft.com/en-us/library/dn655136.aspx#BKMK_SupportedSubscriptions2 Azure Active Directory Connect: http://www.microsoft.com/en-us/download/details.aspx?id=47594


http://www.microsoft.com/en-us/download/details.aspx?id=47594

https://technet.microsoft.com/en-us/library/dn655136.aspx#BKMK_SupportedSubscriptions

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 server3 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)4 cloud based service in the Azure Preview Portal5 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 6.

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.

3 AZURE ACTIVE DIRECTORY FEDERATION COMPATIBILITY LIST: THIRD-PARTY IDENTITY PROVIDERS THAT CAN BE USED TO IMPLEMENT SINGLE SIGN-ON: http://technet.microsoft.com/en-us/library/jj679342.aspx4 AZURE ACTIVE DIRECTORY CONNECT HEALTH: https://msdn.microsoft.com/en-us/library/azure/dn906722.aspx5 Azure Preview Portal: https://portal.azure.com/6 MONITOR YOUR ON-PREMISES IDENTITY INFRASTRUCTURE IN THE CLOUD: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-health/


https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-health/

https://portal.azure.com/

https://msdn.microsoft.com/en-us/library/azure/dn906722.aspx

https://msdn.microsoft.com/en-us/library/azure/dn906722.aspx

http://technet.microsoft.com/en-us/library/jj679342.aspx

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

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

7 CLOUD SECURITY CONTROLS SERIES: MULTI-FACTOR AUTHENTICATION: https://blogs.microsoft.com/cybertrust/2015/07/20/cloud-security-controls-series-multi-factor-authentication/


https://blogs.microsoft.com/cybertrust/2015/07/20/cloud-security-controls-series-multi-factor-authentication/https:/blogs.microsoft.com/cybertrust/2015/07/20/cloud-security-controls-series-multi-factor-authentication/

https://blogs.microsoft.com/cybertrust/2015/07/20/cloud-security-controls-series-multi-factor-authentication/https:/blogs.microsoft.com/cybertrust/2015/07/20/cloud-security-controls-series-multi-factor-authentication/

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

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

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.

8 OFFICE 2013 MODERN AUTHENTICATION PUBLIC PREVIEW ANNOUNCED: http://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/9 DESCRIPTION OF MICROSOFT ONLINE SERVICES SIGN-IN ASSISTANT (MOS SIA): https://community.office365.com/en-us/w/sso/534


https://community.office365.com/en-us/w/sso/534

https://community.office365.com/en-us/w/sso/534

http://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/

http://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/

Objectives of the paperThis 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 10.

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

10 CONFIGURE ADDITIONAL AUTHENTICATION METHODS FOR AD FS: https://technet.microsoft.com/en-us/library/dn758113.aspx


https://technet.microsoft.com/en-us/library/dn758113.aspx


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 documentation11, and the dedicated AD FS Q&A forum12.

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 paperTo 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 audienceThis 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.

11 ACTIVE DIRECTORY FEDERATION SERVICES OVERVIEW: http://technet.microsoft.com/en-us/library/hh831502.aspx12 AD FS Q&A forum: http://social.msdn.microsoft.com/Forums/en-US/Geneva/threads


http://social.msdn.microsoft.com/Forums/en-US/Geneva/threads

Building a test lab environmentAs 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 subscriptionThis 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 13.

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

13 SIGN IN TO OFFICE 365: http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff637600.aspx


Windows Azure AD/Office 365 tenant

DC1

EDGE1

ADFS1

Active Directory Domain Services (AD DS)Domain Name Services (DNS)

Active Directory Certificates Services (AD CS)Active Directory Federation Services (AD FS)

Azure Active Directory Connect Tool (Azure AD Connect)Multi-Factor Authentication Server

Multi-Factor Authentication SDK

Web Application Proxy (WAP)Multi-Factor Authentication Users portalMulti-Factor Authentication Server mobile app web service

Internal Virtual Network SwitchCorpnet

External Virtual Network SwitchInternet

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 accountOnce you have signed up14 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 p ortal 15 and can proceed to the Azure management portal by clicking Portal at the top right corner of your screen.

14 Office 365 Enterprise E3 Trial: http://office.microsoft.com/en-us/business/redir/XT104175934.aspx15 Azure account portal: https://account.windowsazure.com/Subscriptions


Note This notably enables you to empower16 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 portal17, rich identity and access management capabilities are and will be exposed through the Active Directory section in the Azure management portal18 first. For example, the Application Access Enhancements for Azure AD19, which provides a streamlined access to thousands20 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 environmentThe whitepaper AZURE AD/OFFICE 365 SINGLE SIGN-ON WITH AD FS IN WINDOWS SERVER 2012 R2 - PART 2BIS 21 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)22 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 23. 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

16 USING YOUR OFFICE 365 AZURE AD TENANT WITH APPLICATION ACCESS ENHANCEMENTS FOR WINDOWS AZURE AD: http://blogs.technet.com/b/ad/archive/2013/09/10/empower-your-office-365-subscription-identity-management-with-application-access-enhancements-for-windows-azure-ad.aspx17 Office 365 management portal: https://portal.microsoftonline.com18 Azure management portal: https://manage.windowsazure.com19 APPLICATION ACCESS ENHANCEMENTS FOR AZURE AD: http://technet.microsoft.com/en-us/library/dn308588.aspx20 WINDOWS AZURE ACTIVE DIRECTORY APPLICATIONS: http://azure.microsoft.com/en-us/marketplace/active-directory/21 AZURE AD/OFFICE 365 SINGLE SIGN-ON WITH AD FS IN WINDOWS SERVER 2012 R2 – PART 2BIS: http://www.microsoft.com/en-us/download/details.aspx?id=3639122 Azure Active Directory Connect: http://www.microsoft.com/en-us/download/details.aspx?id=4759423 LEVERAGE MULTI-FACTOR AUTHENTICATION (MFA) SERVER ON-PREMISES: http://www.microsoft.com/en-us/download/details.aspx?id=36391



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

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.

24 WINDOWS SERVER 2012 R2: http://technet.microsoft.com/en-US/windowsserver/hh534429


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.

4. Verify under quick glance that the INTERNAL IP ADDRESS is set to 10.0.2.4 in our configuration.

5. Select adfs1 on the left and then click START at the tray of the bottom.6. 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 labDeploying a domain-joined computerDeploying 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 25 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.

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

25 CREATE AND UPLOAD A WINDOWS SERVER VHD TO AZURE: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-create-upload-vhd-windows-server/


https://manage.windowsazure.com/

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-create-upload-vhd-windows-server/

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

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


7. Specify the VM configuration:a. In VIRTUAL MACHINE NAME, specify a name for the VM, for example in our

illustration “laptop1”.b. 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.

c. In NEW USER NAME, specify a name, for instance in our illustration “AzureAdmin”.

d. In NEW PASSWORD and CONFIRM, specify a password for the account, for example in our illustration “Pass@word1”.

8. Click the arrow icon at the bottom right.


9. In CLOUD SERVICE, select mfalabsvc. You can then select the Subnet2 of the test lab environment.

10. In VIRTUAL NETWORK SUBNETS, select mfalabvnet-subnet2(10.0.2.0/24).

11. Click the arrow icon at the bottom right.

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

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


14. Enter the credentials of the above local account you specified, for example in our configuration:Username: LAPTOP1\AzureAdminPassword: pass@word1

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

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

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


18. Select Domain, type “LITWARE369”, and then click OK. A Windows Security dialog pops up.

19. Enter the credentials of a LITWARE369 domain administrator, for example in our configuration:Username: LITWARE369\AzureAdminPassword: pass@word1

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

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

22. Click OK to restart.


Allowing additional users to connect remotelyTo 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\AzureAdminPassword: 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.

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


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

5. Click Add…

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

7. Click OK three times to close all the open dialogs.8. 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 capabilitiesTo 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

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

3. Type “[email protected]” 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.


https://adfs.litware369.com/

https://portal.office.com/

Janet Schorr is not yet licensed to Office 365 Enterprise.9. 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 neededIf 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.


https://adfs.litware369.com/adfs/ls/idpinitiatedsignon.htm


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 computerTo 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\AzureAdminPassword: 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.



1. Open a remote desktop connection on the LAPTOP2 computer as a local user:Username: LAPTOP2\AzureAdmin Password: pass@word1

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

3. Type “[email protected]” 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.




4. Type the password of the user, for example, in our illustration “pass@word1”.5. 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.


6. 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.7. 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 neededIf 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 userAnother 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.

a. In User name, type “User2”.b. In Password and Confirm password, type “pass@word1”.c. Uncheck User must change password at next logon.d. Click Create, and then Close.

5. Right-click the newly created user and select Properties. A User2 Properties dialog opens up.

6. Click Member Of, and then select Add… A Select Groups dialog opens up.


a. Type “Administrators”, and then click Check Names. b. Click OK.

7. Click OK.

Adding an Azure AD joined computer to the test labWindows 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 26.

Deploying an Azure AD joined computerTo 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:

a. In step 5, select Windows 10 Enterprise (x64).

26 AZURE AD & WINDOWS 10: BETTER TOGETHER FOR WORK OR SCHOOL: http://www.microsoft.com/en-us/download/details.aspx?id=36391




b. In step 7, for the VM configuration:i. In VERSION RELEASE DATA, select 7/30/2015.ii. In VIRTUAL MACHINE NAME, specify a name for the VM, for example

in our illustration “laptop3”.

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

2. 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\AzureAdminPassword: pass@word1

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

4. Select Settings > System > About.


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

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


7. For the purpose of this document, type “[email protected]” 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.



8. Type the password of the user, for example, in our illustration “pass@word1”.9. Click Sign in. As before with the Robert Hatley account, a screen appears inviting you

to do a multi-factor authentication using MFA Server.

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


11. Click Join to confirm.

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

13. Click Finish.



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.



2. Type “[email protected]” 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.

3. 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 327.

4. Click Sign in. Like before, a screen appears inviting you to do a multi-factor authentication.

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

27 Windows Server 2016 Technical Preview 3: https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview


https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview


6. 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 neededIf 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 . You are now in a position to notably further configure the Azure Rights Management Service (RMS).


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

1. Activating Azure RMS.2. Licensing users for Azure RMS.3. Installing Office 365 ProPlus on the Windows devices.4. Enabling the modern authentication for Office 365.5. Installing the RMS sharing app on the Windows devices.

The next sections guide you through these five additional steps.

Activating Azure RMSOnce 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:

Use the Office 365 admin center and follow the steps outlined in the Microsoft TechNet article QUICK START TUTORIAL FOR AZURE RIGHTS MANAGEMENT 28.

-or- Use the Azure RMS from Windows PowerShell.

a. First connect to the Azure RMS from Windows PowerShell with the Azure Rights Management Administration Tool29. This tool installs the Azure Rights Management module that provides cmdlets to enable an administrator to manage and configure Azure RMS features.

b. 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 30 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.

28 QUICK START TUTORIAL FOR AZURE RIGHTS MANAGEMENT: https://technet.microsoft.com/en-us/library/mt126254.aspx29 Azure Rights Management Administration Tool: http://www.microsoft.com/en-us/download/details.aspx?id=3033930 ACTIVATING AND CONFIGURING RIGHTS MANAGEMENT: https://technet.microsoft.com/en-us/library/jj585026.aspx#BKMK_Example_ManagementPortal


https://technet.microsoft.com/en-us/library/jj585026.aspx#BKMK_Example_ManagementPortal



https://technet.microsoft.com/en-us/library/mt126254.aspx

https://technet.microsoft.com/en-us/library/dn655136.aspx#BKMK_SupportedSubscriptions

Activating Azure RMS using Windows PowerShellThe first step consists in installing the Azure Rights Management Administration Tool.

Installing Windows PowerShell for Azure RMSTo 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 31.

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.

a. 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 RTW32.

b. Click Run to install. The wizard Microsoft Online Services Sign-in Assistant Setup pops up. Follow the steps of the wizard.

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

3. 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 33. 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 RMSNow, 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.

31 INSTALLING WINDOWS POWERSHELL FOR AZURE RIGHTS MANAGEMENT: https://technet.microsoft.com/library/jj585012.aspx32 Microsoft Online Services Sign-In Assistant for IT Professionals RTW: http://www.microsoft.com/en-us/download/details.aspx?id=4195033 MANAGE AZURE AD USING WINDOWS POWERSHELL: https://technet.microsoft.com/library/jj151815.aspx


https://technet.microsoft.com/library/jj151815.aspx






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 AADRMPS C:\Windows\system32> Connect-AadrmService –Verbose

You will be prompted for your credentials.

3. 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: [email protected]: ****************

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 34 and AZURE RIGHTS MANAGEMENT CMDLETS 35.

Enabling Azure RMSTo 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

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

PS C:\Windows\system32> Get-AadrmConfiguration

34 ADMINISTERING AZURE RIGHTS MANAGEMENT BY USING WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/jj585027.aspx35 AZURE RIGHTS MANAGEMENT CMDLETS: https://msdn.microsoft.com/library/azure/dn629398.aspx


https://msdn.microsoft.com/library/azure/dn629398.aspx

https://technet.microsoft.com/en-us/library/jj585027.aspx

https://technet.microsoft.com/en-us/library/jj585027.aspx

PS C:\WINDOWS\system32> Get-AadrmConfiguration

BPOSId : 2971a9f9-454c-4be2-9b86-5b3513ecb22eRightsManagementServiceId : 6c8e9100-1168-4085-90f0-22293f9e5a0dLicensingIntranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensi ngLicensingExtranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/_wmcs/licensi ngCertificationIntranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/_wmcs/certifi cationCertificationExtranetDistributionPointUrl : https://6c8e9100-1168-4085-90f0-22293f9e5a0d.rms.eu.aadrm.com/_wmcs/certifi cationAdminConnectionUrl : https://admin.eu.aadrm.com/admin/admin.svc/Tenants/6c8e9100-1168-4085-90f0- 22293f9e5a0dAdminV2ConnectionUrl : https://admin.eu.aadrm.com/adminV2/admin.svc/Tenants/6c8e9100-1168-4085-90f 0-22293f9e5a0dOnPremiseDomainName :Keys : {22327901-6fdd-4dfc-81c7-04a1eb3c1afb, a7dc9629-d474-41ff-8c1e-b17d73e3849e}CurrentLicensorCertificateGuid : a7dc9629-d474-41ff-8c1e-b17d73e3849eTemplates : {72fb2c43-cc9d-43ba-a02a-3320b2a869be, 9567b5c8-217d-46d2-b529-28c3a0d1ca7d}

FunctionalState : Enabled

SuperUsersEnabled : DisabledSuperUsers : {}AdminRoleMembers : {}KeyRolloverCount : 0ProvisioningDate : 20/12/2013 14:57:14IPCv3ServiceFunctionalState : EnabledDevicePlatformState : {Windows -> True, WindowsStore -> True, WindowsPhone -> True, Mac -> True...}FciEnabledForConnectorAuthorization : TrueDocumentTrackingFeatureState : 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 Americae.g.: https://<RightsManagementServiceId>-rms.ap.aadrm.com/_wmcs/licensing for Asia Pacific

4. 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 centerTo 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.a. If the Office 365 admin center is not visible, open the apps launcher in the top

left corner.

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

Management.


https://portal.microsoftonline.com/

4. Under Protect your information, click Manage.

5. Under rights Management, click activate.

6. 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 RMSProceed 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.

5. 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 devicesTo 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\janetsPassword: pass@word1

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



https://portal.microsoftonline.com/

3. Click [email protected] to sign in as the Janet Schorr account name.

4. Next to Install Office on your PC, click Install now. You’re redirected to a new page.

5. Under Install the latest version of Office, click Install.


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

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

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

10. After the installation completes, sign out of the portal and close the remote desktop connection.

11. Open a new remote desktop connection on the LAPTOP2 non-domain joined computer as a local user, for example in our configuration: Username: LAPTOP2/AzureAdminPassword; pass@word1

12. Repeat steps 2 to 10 with the Robert Hatley account.13. Open a new remote desktop connection on the LAPTOP3 Azure AD joined computer as

a local user, for example in our configuration: Username: LAPTOP3/AzureAdminPassword; pass@word1

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


Enabling the modern authentication for Office 365As of this writing, modern authentication is still in public preview36 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 Settings37 - 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 38.

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 201339 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 applications40 - 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 update41.

36 OFFICE 2013 MODERN AUTHENTICATION PUBLIC PREVIEW: http://aka.ms/publicpreview37 MANAGING YOUR AZURE MULTI-FACTOR AUTHENTICATION USER SETTINGS: https://msdn.microsoft.com/library/azure/dn270518.aspx#apppassword38 AZURE AD & WINDOWS 10: BETTER TOGETHER FOR WORK OR SCHOOL: http://aka.ms/aadpapers39 JUNE 9, 2015, UPDATE FOR OFFICE 2013 (KB3054853): https://support.microsoft.com/kb/305485340 OVERVIEW OF THE UPDATE PROCESS FOR OFFICE 365 PROPLUS: http://technet.microsoft.com/en-us/library/dn761709(v=office.15).aspx41 Windows Update: http://windows.microsoft.com/en-US/windows7/products/features/windows-update


http://windows.microsoft.com/en-US/windows7/products/features/windows-update

http://technet.microsoft.com/en-us/library/dn761709(v=office.15).aspx

https://support.microsoft.com/kb/3054853


http://aka.ms/aadpapers

https://msdn.microsoft.com/library/azure/dn270518.aspx#apppassword

https://msdn.microsoft.com/library/azure/dn270518.aspx#apppassword

http://aka.ms/publicpreview

Note For more information on feature updates, see the Office blog42.

Enabling the modern authentication on your tenantFor 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 43 survey. The GUIDE TO ENROLLING INTO OFFICE 2013 MODERN AUTHENTICATION PUBLIC PREVIEW 44 provides a set of additional guidance.

Enabling the new authentication features on the Windows devicesAs 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 201345 or later.

Note For additional information, see the Microsoft TechNet article REQUIREMENTS FOR AZURE RIGHTS MANAGEMENT 46.

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 47 and "BACKGROUND TASK ACTIVATION IS SPURIOUS" ERROR WHEN YOU USE AN OFFICE 2016 APPLICATION TO ACCESS OFFICE 365 RESOURCES 48.

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.

42 Office blog: http://blogs.office.com/43 OFFICE 2013 MODERN AUTHENTICATION PUBLIC PREVIEW: http://aka.ms/publicpreview44 GUIDE TO ENROLLING INTO OFFICE 2013 MODERN AUTHENTICATION PUBLIC PREVIEW: http://aka.ms/PreviewHowTo45 JUNE 9, 2015, UPDATE FOR OFFICE 2013 (KB3054853): https://support.microsoft.com/kb/305485346 REQUIREMENTS FOR AZURE RIGHTS MANAGEMENT: https://technet.microsoft.com/en-us/library/dn655136.aspx47 "INVALID PROVIDER SPECIFIED" ERROR WHEN YOU USE AN OFFICE 2016 APPLICATION TO ACCESS OFFICE 365 RESOURCES: https://support.microsoft.com/en-us/kb/309608048 "BACKGROUND TASK ACTIVATION IS SPURIOUS" ERROR WHEN YOU USE AN OFFICE 2016 APPLICATION TO ACCESS OFFICE 365 RESOURCES: https://support.microsoft.com/en-us/kb/3097938


https://support.microsoft.com/en-us/kb/3097938







http://aka.ms/PreviewHowTo

http://aka.ms/publicpreview

http://blogs.office.com/

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

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\roberthPassword: 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.

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

5. Click Yes. Another dialog pops up.

49 ENABLE MODERN AUTHENTICATION FOR OFFICE 2013 ON WINDOWS DEVICES: http://aka.ms/authadminhowto


http://aka.ms/authadminhowto

http://aka.ms/authadminhowto

6. Click OK and close the session.7. Repeat steps 1 to 6 with the Robert Hatley account.8. Open a new remote desktop connection on the LAPTOP2 non-domain joined computer

as a local user, for example in our configuration: Username: LAPTOP2/AzureAdminPassword; pass@word1

9. Repeat steps 2 to 6.10. Open a new remote desktop connection on the LAPTOP2 non-domain joined computer

as a local user, for example in our configuration: Username: LAPTOP2/User2Password; pass@word1

11. Repeat steps 2 to 6.12. Open a new remote desktop connection on the LAPTOP3 Azure AD joined computer as


13. Repeat steps 2 to 6.

Installing the RMS sharing app on the Windows devicesThe 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 50.

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.

50 Rights Management Sharing Application for Windows:




Note For additional information, see the Microsoft TechNet article REQUIREMENTS FOR AZURE RIGHTS MANAGEMENT 51.

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\roberthPassword: 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.

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

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

5. Click Next.

51 REQUIREMENTS FOR AZURE RIGHTS MANAGEMENT: https://technet.microsoft.com/en-us/library/dn655136.aspx


http://go.microsoft.com/fwlink/?LinkId=355394

http://www.microsoft.com/en-US/download/details.aspx?id=40857



6. Click Restart.7. Open a new remote desktop connection on the LAPTOP2 non-domain joined computer

as a local user, for example in our configuration: Username: LAPTOP2/AzureAdminPassword; pass@word1

8. Repeat steps 2 to 6.9. Open a new remote desktop connection on the LAPTOP3 Azure AD joined computer as


10. 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 RMSNow 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:

1. Office 365 ProPlus running on a domain-joined Windows device.2. Office 365 ProPlus running on a non-domain joined Windows device.3. 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 computerA 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 52 along with their resolution path.

Testing Rights ManagementTo 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\roberthPassword: pass@word1

2. Launch Word. A First things first dialog shows up.52 OFFICE MODERN AUTH & ADFS: MAKING IT WORK: http://blogs.msdn.com/b/samueld/archive/2015/06/05/office-modern-auth-amp-adfs-making-it-work.aspx


http://blogs.msdn.com/b/samueld/archive/2015/06/05/office-modern-auth-amp-adfs-making-it-work.aspx

https://adfs.liware369.com/

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

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


5. Click Blank document to create a new document.6. Enter some text, for example enter “=lorem(12)” and press ENTER. Save the

document to the local Users\Public\Public Documents folder.7. If an exclamation mark appears before Robert Hatley’s name in the top right-hand

corner),a. Click Robert Hatley, and then select Switch Account.b. Click SIGN OUT and close the dialog.c. Select Sign-in (in the top right-hand corner).


d. Enter Robert Hatley’s email address ([email protected]) and click Next.

e. Enter Robert Hatley’s password and click Sign in.

f. Click Continue. You’re signed in.8. 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…”

9. Re-select Protect Document >> Restrict Access. You should see a list of restricted access options that includes a couple of templates:

a. ‘Restricted Access’.b. ‘Litware369 – Confidential’.c. ‘Litware369 – Confidential View Only’.

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

11. Save the file and log off.12. Open a new remote desktop connection on the same LAPTOP1 computer with the

Janet Schoor account credentials: Username: LITWARE369\janetsPassword: pass@word1

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


14. 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 computerA 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 ManagementTo 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/AzureAdminPassword; pass@word1

2. Launch Word.




document to the local Users\Public\Public Documents folder.5. Select Sign-in (in the top right-hand corner).

6. Enter Robert Hatley’s email address ([email protected]) and click Next.



7. Enter Robert Hatley’s password and click Sign in.

8. Click Continue. You’re signed in.9. 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.


11. Save the file and log off.12. Open a new remote desktop connection on the same LAPTOP1 computer as another

local user, for example in our configuration:Username: LAPTOP2/User2Password; pass@word1

13. Launch Word. A First things first dialog shows up.14. Select Use recommended settings and then click Accept. A Welcome to your

new Office shows up.


15. Click Next.

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


17. Enter Janet Schorr’s email address ([email protected]) and click Next.

18. Enter Janet Schorr’s password and click Sign in.19. Back to the wizard, complete (the steps of) the wizard. Click All done! at the end to

close the wizard.20. 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.




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 computerA 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 ManagementTo 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/AzureAdminPassword; pass@word1

2. Launch Word.




document to the local Users\Public\Public Documents folder.5. Select Sign-in (in the top right-hand corner).

6. Enter Robert Hatley’s email address ([email protected]) and click Next.



7. Enter Robert Hatley’s password and click Sign in.

8. Click Continue. You’re signed in.9. 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.



11. Save the file.12. Launch Outlook. A Welcome to Outlook 2013 wizard opens up.

13. Click Next.

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


15. In the Auto Account Setup page: a. Keep E-mail Account selected.b. In Your Name, type “Robert Hatley”.c. In E-mail Address, type “[email protected]”d. In Password and Retype Password, type “pass@word1”.e. Click Next.

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


a. In To, type “[email protected]”.b. In Subject and in the body of the mail, type some text.c. Select MESSAGE > Attach File and attached the previously created

document in step 11.d. 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’.

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


18. Click Send.19. Once sent, close Outlook and log off.20. Open a new remote desktop connection on the same LAPTOP1 computer as another

local user, for example in our configuration:Username: LAPTOP2/User2Password; pass@word1

21. Launch Outlook.22. Repeat steps 12 to 16 for Janet Schoor.23. Now in Outlook, open the message received from Robert Hatley.24. Janet Schorr’s password (“pass@word1”) and click Sign in. Once authenticated,

you’re redirected back to your mailbox.

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



Et voila!


Understanding and troubleshooting the authentication flowsAs 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.053 54. 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).

53 RFC 6749 THE OAUTH 2.0 AUTHORIZATION FRAMEWORK: http://tools.ietf.org/html/rfc674954 RFC 6750 THE OAUTH 2.0 AUTHORIZATION FRAMEWORK: BEARER TOKEN USAGE: http://tools.ietf.org/html/rfc6750


http://tools.ietf.org/html/draft-ietf-oauth-v2

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

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 flowsIn 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 56.

The Microsoft Remote Connectivity Analyzer (RCA) 57 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.

55 JSON WEB TOKEN (JWT): http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-3056 TOOLS AND DIAGNOSTICS: http://community.office365.com/en-us/w/diagnostic_tools/default.aspx57 Microsoft Remote Connectivity Analyzer (RCA): http://testexchangeconnectivity.com/


https://www.testconnectivity.microsoft.com/?testid=SingleSignOn

http://go.microsoft.com/fwlink/?LinkId=154308

http://community.office365.com/en-us/w/diagnostic_tools/default.aspx

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-30

2. 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 58 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)59 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.

58 HOW TO USE REMOTE CONNECTIVITY ANALYZER TO TROUBLESHOOT SINGLE SIGN-ON ISSUES FOR OFFICE 365, AZURE, OR WINDOWS INTUNE: http://support.microsoft.com/kb/265071759 Microsoft Remote Connectivity Analyzer tool (client): http://technet.microsoft.com/library/feba32b0-b7eb-4b1b-ba3d-99e20ba82a8c


https://www.testconnectivity.microsoft.com/

http://technet.microsoft.com/library/feba32b0-b7eb-4b1b-ba3d-99e20ba82a8c

http://support.microsoft.com/kb/2650717

http://support.microsoft.com/kb/2650717

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

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

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


http://go.microsoft.com/fwlink/?LinkID=313782

This conclude this whitepaper.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.This white paper is for informational purposes only. Microsoft makes no warranties, express or implied, in this document.Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.© 2015 Microsoft Corporation. All rights reserved.The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Microsoft, list Microsoft trademarks used in your white paper alphabetically are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
