Leverage the Mobile Device Extension for AD RMS Web view20 Leverage the Mobile Device Extension for ... the Mobile Device Extension for AD RMS enables to expose rights management service

Leverage the Mobile Device Extension for AD RMSOverview Technical Article

Microsoft FrancePublished: October 2014 (updated: March 2016)Version: 1.0cAuthors: Philippe Beraud (Microsoft France)Contributors/Reviewers: Martin Sieber (Microsoft Switzerland), Enrique Saggese, Sergey Simakov (Microsoft Corporation)

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

Copyright © 2016 Microsoft Corporation. All rights reserved.

Abstract: Due to increased regulation, Consumerization of IT (CoIT) tendencies and “Bring Your Own Device” (BYOD) initiatives, the explosion of information with dispersed enterprise data, the Social Enterprise and its applications enabling new collaboration and other trends, organization of all sizes are facing growing needs to protect and control sensitive information on all important devices (smartphones, slates, tablets, and laptops).This document provides information about the Mobile Device Extension for AD RMS, and how it can be deployed on top of existing Windows Server 2012 and Windows Server 2012 R2-based AD RMS clusters to support the important devices with mobile RMS-enlightened applications. By following the steps outlined in this document you should be able to successfully prepare your environment to deploy the Mobile Device Extension, and start using it within your organization to create and consume protected content on all the important devices.

Table of ContentsNOTICE................................................................................................................

3FEEDBACK.........................................................................................................3INTRODUCTION..................................................................................................4

OBJECTIVES OF THIS PAPER................................................................................................6NON-OBJECTIVES OF THIS PAPER.........................................................................................6ORGANIZATION OF THIS PAPER............................................................................................6ABOUT THE AUDIENCE.......................................................................................................7

OVERVIEW OF THE MOBILE DEVICE EXTENSION FOR AD RMS................................8PREREQUISITES FOR THE MOBILE DEVICE EXTENSION..............................................................9HOW MOBILE APPS USE THE NEW SERVICE ENDPOINTS...........................................................10UNDERSTANDING HOW THE SERVICE ENDPOINTS ARE LOCATED................................................12UNDERSTANDING HOW AUTHENTICATION WORKS WITH THE SERVICE ENDPOINTS.........................19REVIEWING THE SUPPORTED TOPOLOGIES FOR THE MOBILE DEVICE EXTENSION..........................22

BUILDING AN EVALUATION ENVIRONMENT.........................................................28BUILDING AN AZURE-BASED LAB ENVIRONMENT....................................................................28PREPARING THE LOCAL ENVIRONMENT FOR AZURE................................................................32

SETTING UP THE WINDOWS SERVER 2012 R2 BASE CONFIGURATION TEST LAB....38DEPLOYING THE BASE WORKLOADS IN AZURE......................................................................41CONFIGURING THE DOMAIN CONTROLLER............................................................................45CONFIGURING THE ROOT ENTERPRISE CA...........................................................................55DEPLOYING THE FEDERATION SERVER.................................................................................60PREPARING THE INTERNET-FACING COMPUTER......................................................................63DEPLOYING THE DATABASE SERVER...................................................................................73DEPLOYING THE RIGHTS MANAGEMENT SERVER....................................................................78

TESTING AND EVALUATING THE MOBILE DEVICE EXTENSION FOR AD RMS...........90CONFIGURING AD FS FOR THE MOBILE DEVICE EXTENSION FOR AD RMS................................90SPECIFYING THE SERVICE DISCOVERY RECORDS FOR THE MOBILE DEVICE EXTENSION FOR AD RMS93DEPLOYING THE MOBILE DEVICE EXTENSION FOR AD RMS....................................................99PUBLISHING THE MOBILE DEVICE EXTENSION ENDPOINTS OVER THE INTERNET.........................102TESTING THE MOBILE DEVICE EXTENSION.........................................................................102TROUBLESHOOTING THE MOBILE DEVICE EXTENSION...........................................................103

APPENDIX......................................................................................................107SETTING UAC BEHAVIOR OF THE ELEVATION PROMPT FOR ADMINISTRATORS............................107SIMULATING AN ANDROID DEVICE....................................................................................107

2 Leverage the Mobile Device Extension for AD RMS

NoticeFor the latest information that pertains the Mobile Device Extension for AD RMS (MDE) as covered in this document, please refer to the Microsoft TechNet article ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES MOBILE DEVICE EXTENSION 1. This article constitutes the reference source on this extension for AD RMS.

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

1 ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES MOBILE DEVICE EXTENSION: http://technet.microsoft.com/library/Dn673574.aspx


mailto:[email protected]

http://technet.microsoft.com/library/Dn673574.aspx

http://technet.microsoft.com/library/Dn673574.aspx

Introduction Every day, information workers use email messages to exchange sensitive information such as financial reports and data, legal contracts, confidential product information, sales reports and projections, competitive analysis, research and patent information, customer records, employee information, etc.With time, the type, volume and sensitivity of information that is exchanged has changed significantly. Mailboxes have transformed into repositories containing large amounts of potentially sensitive information.Ever more powerful and more affordable devices (smartphones, slates, tablets, and laptops), converging technologies, and the widespread use of the Internet have replaced what were only (controlled and managed) laptops in past years. Today, information workers are highly interconnected interacting with each other in new ways using social networks (Facebook, Google+, Yammer, etc.), and expect “always on” connectivity, and more of them are using the device of their choice to access emails and work-related documents from just about anywhere: at home, at work and everywhere in between… up to the point where personal and work communication can become indistinguishable. CoIT is the current phenomenon whereby consumer technologies and consumer behavior are in various ways driving innovation for information technology within the organization. As people become more comfortable with technology innovation in their personal lives, they expect it in their professional lives. While CoIT has remarkable potential for improving collaboration and productivity, this raises new challenges for security, privacy, and industry and regulatory compliance.

Note To help figure out how to face security, compliance and compatibility issues you might deal with and to give users access to corporate intellectual property from ubiquitous devices, both managed and unmanaged, you can refer to a series of documents on CoIT, i.e. Test Lab Guides (TLGs) available on the Microsoft Download Center2. The TLGs illustrate key CoIT scenarios with current Microsoft technologies and allow you to get hands-on experience using a pre-defined and tested methodology that results in working configurations.

Where information workers are more mobile, share information, and collaborate more than ever before, information leakage can be thus a serious threat to organizations. Leaks of confidential information can result in lost revenue, compromised ability to compete, unfairness in purchasing and hiring decisions, diminished customer confidence, and more. The proliferation of consumer devices and ubiquitous information access is driving the organization to define a new model in which information workers use their (own) devices to access sensitive corporate data. The model must be flexible enough to meet their users’ needs while at the same time guarantee that sensitive corporate data are protected from unauthorized access regardless of whether the user’s device is completely managed and individually secured. To increase productivity, users also ask for a secure and consistent way to access and share sensitive information from their devices. To tackle the issues described above, Microsoft has delivered a cloud-based digital information rights management solution on all important devices through the Azure Rights Management service (Azure RMS) offerings. This service enables users on all important devices to access and use sensitive information. As a transport and storage agnostic solution, it operates on all types of files. Dispersed enterprise data can be protected in a consistent way dictated by the policy no matter where it goes.2 CONSUMERIZATION OF IT TEST LAB GUIDES: http://www.microsoft.com/en-us/download/details.aspx?id=29574


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

Note For an overview of Azure RMS, see the whitepaper AZURE RIGHTS MANAGEMENT SERVICES 3, and the online documentation4.

However, such a support for all important devices was not available in the on-premises counterpart to Azure RMS, Microsoft Active Directory Right Management Services (AD RMS). First shipped for Windows Server 2003 and later evolved into a component of Windows Server 2008/2012, AD RMS is designed for organizations that need to protect sensitive and proprietary information and that are not ready to or cannot subscribe for any specific requirement or reason to a cloud service.The Mobile Device Extension for AD RMS now enables Windows Server 2012 and Windows Server 2012 R2-based AD RMS clusters to support important mobile devices with mobile RMS-enlightened applications in the same way as Azure RMS does.

Note You don’t need the Mobile Device Extension for AD RMS to consume or author protected email on devices if they use mobile mail apps that support Exchange ActiveSync (EAS) Information Rights Management (IRM). This native support for AD RMS and mobile devices was introduced with Exchange 2010 Service Pack 1 (SP1).

Note The Microsoft Exchange ActiveSync (EAS)5 protocol provides synchronization of mailbox data between mobile devices and Exchange Online, so users can access their email, calendar, contacts, and tasks on the go. EAS is licensed by Microsoft to mobile device manufacturers, original equipment manufacturers (OEMs), and mail client applications, and is thus supported by a wide range of mobile devices, including Windows Phone devices, Palm devices, Apple iPhone and iPad, and many Android phones. Implementation of specific EAS features may vary by device and manufacturer. A community-maintained comparison of how Exchange ActiveSync features are implemented by various mobile clients is available at this COMPARISON OF EXCHANGE ACTIVESYNC CLIENTS 6 page on Wikipedia.

Note Devices supporting version 14.1 and above of the protocol can leverage the above EAS IRM capability. The mobile mail app on a device must support the RightsManagementInformation tag defined in this protocol version and above.To learn more about EAS IRM for protecting mail messages and attachments and how to deploy it in Exchange 2010 SP1 and above, see the Microsoft TechNet article UNDERSTANDING INFORMATION RIGHTS MANAGEMENT IN EXCHANGE ACTIVESYNC 7.

The Mobile Device Extension for AD RMS is particularly intended for any mobile RMS-enlightened applications based on the latest Microsoft Rights Management (RMS) SDK, i.e. the RMS SDK 4.0, such as the RMS Sharing app. These applications generally need to be installed through the corresponding app stores for the device.

3 AZURE RIGHTS MANAGEMENT SERVICES: http://blogs.technet.com/b/rms/archive/2013/07/31/the-new-microsoft-rights-management-services-whitepaper.aspx4 Azure Rights Management services: http://www.microsoft.com/rms5 UNDERSTANDING EXCHANGE ACTIVESYNC: http://technet.microsoft.com/en-us/library/aa998357.aspx6 COMPARISON OF EXCHANGE ACTIVESYNC CLIENTS: http://en.wikipedia.org/wiki/Comparison_of_Exchange_ActiveSync_Clients7 UNDERSTANDING INFORMATION RIGHTS MANAGEMENT IN EXCHANGE ACTIVESYNC: http://technet.microsoft.com/en-us/library/ff657743.aspx


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

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

http://en.wikipedia.org/wiki/Comparison_of_Exchange_ActiveSync_Clients

http://en.wikipedia.org/wiki/Comparison_of_Exchange_ActiveSync_Clients

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

http://www.microsoft.com/rms

http://blogs.technet.com/b/rms/archive/2013/07/31/the-new-microsoft-rights-management-services-whitepaper.aspx

Note For more information on the RMS Sharing app, see the RMS sharing app guides (administration guide8 and user guide9) and the FAQ10 for mobile platforms on Microsoft TechNet.

Objectives of this paperThis document provides information about the Mobile Device Extension for AD RMS, and how it can be deployed on top of existing Windows Server 2012 and Windows Server 2012 R2-based AD RMS clusters to support devices with mobile RMS-enlightened applications. By following the steps outlined in this document you should be able to successfully prepare your environment to deploy the Mobile Device Extension, and start using it within your organization to create and consume protected content on your devices. Please note that the detailed step by step guidance in this paper covers not only the deployment of the Mobile Device Extension, but also the installation and configuration of AD RMS, the domain controllers that support the environment, Active Directory Federation Services (AD FS) servers, the virtual machines to host those components and other required components. If this guide is used to support the deployment of MDE in an existing environment, only specific sections of the detailed procedures will apply, while others will have to be modified.

Non-objectives of this paperThis document doesn’t provide a full description of AD RMS. It rather focuses on key aspects that aims at providing the readers an understanding on how to leverage and deploy the Mobile Device Extension on their existing on-premises corporate AD RMS infrastructure.

Note For additional information on AD RMS, see the Microsoft TechNet article ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES OVERVIEW 11, as well as the several posts of the AD RMS Team Blog12.

It doesn’t provide neither guidance for setting up and configuring AD RMS in a production environment nor a complete technical reference for AD RMS.

Organization of this paperTo cover the aforementioned objectives, this document is organized in the following four sections:

OVERVIEW OF THE MOBILE DEVICE . BUILDING AN EVALUATION ENVIRONMENT. SETTING UP THE WINDOWS SERVER 2012 R2 BASE CONFIGURATION TEST LAB. TESTING AND EVALUATING THE MOBILE DEVICE EXTENSION FOR AD RMS.

These sections provide the information details necessary to (hopefully) successfully build a working environment with the Mobile Device Extension for AD RMS. They must be followed in order.8 RIGHTS MANAGEMENT SHARING APPLICATION ADMINISTRATOR GUIDE: http://technet.microsoft.com/library/dn3390039 RIGHTS MANAGEMENT SHARING APPLICATION USER GUIDE: http://technet.microsoft.com/library/dn33900610 FAQ FOR MICROSOFT RIGHTS MANAGEMENT SHARING APPLICATION FOR MOBILE PLATFORMS: http://technet.microsoft.com/dn45124811 ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES OVERVIEW: http://go.microsoft.com/fwlink/?LinkId=8472612 AD RMS Team Blog: http://blogs.technet.com/b/rms/


http://blogs.technet.com/b/rms/

http://blogs.technet.com/b/rms/

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


http://technet.microsoft.com/dn451248

http://technet.microsoft.com/library/dn339006

http://technet.microsoft.com/library/dn339003

About the audienceThis document is intended for system architects and IT professionals who are interested in understanding how to enable and configure the Mobile Device Extension for AD RMS on their existing on-premises AD RMS infrastructure.


Overview of the Mobile Device Extension for AD RMSAs introduced before, the Mobile Device Extension for AD RMS lets users who have mobile devices protect and consume sensitive data when their device supports the latest RMS client (also known as the mobile client) and uses RMS-enlightened apps. For example, users on these devices can do the following:

Use the RMS sharing app to consume protected text files in different formats (including .txt, .csv, and .xml).

Use the RMS sharing app to consume protected image files (including .jpg, .gif, and .tif).

Use the RMS sharing app to open any file that have been generically protected (.pfile format).

Use the RMS sharing app to open an Office or PDF file encoded in PPDF format (to learn more about the PPDF format see the relevant section in the RMS Sharing app documentation).

Use the RMS sharing app to protect image files on the device. Use an RMS-enlightened PDF viewer for mobile devices to open PDF files that were

protected with the RMS sharing app for Windows, or another RMS-enlightened application.

Use other apps from software vendors who provide RMS-enlightened apps that support file types that natively support RMS.

Use your internally developed RMS-enlightened apps that were written by using the lightweight Microsoft Rights Management SDK (RMS SDK) 4.0.

The first mobile client that was based on the RMS SDK 3.0 was initially intended to work only in conjunction with Azure RMS. More specifically, it was designed to interact with the highly abstracted and simplified REST APIs exposed by Azure RMS through rights management service endpoints - along with a service discovery process - for authoring of new content and for consumption of protected content on mobile devices. To enable the above usage scenario, the Mobile Device Extension for AD RMS enables an on-premises AD RMS clusters to expose similar service endpoints as the ones exposed by Azure RMS.Such an approach leverages a common logic to locate via a service discovery process the REST service endpoints of the RMS service, whether it is an on-premises AD RMS cluster with the Mobile Device Extension or Azure RMS.The newly introduced RMS SDK 4.0 for creating rights-enabled applications integrates this common logic and abstracts all access to service endpoints in a platform agnostic manner for the REST APIs. This version of the RMS SDK thus enables to develop RMS-enlightened apps on mobile devices with the new AD RMS server's Mobile Device Extension.

Important note The RMS SDK 4.0 supersedes the RMS SDK 3.0, which is now deprecated.


http://technet.microsoft.com/en-us/library/dn574738(v=ws.10).aspx#BKMK_PPDF

http://technet.microsoft.com/en-us/library/dn574738(v=ws.10).aspx#BKMK_PPDF

Note The RMS SDK 4.0 is a simplified, next-generation API that enables a lightweight development experience in building or upgrading device apps with information protection via the RMS service, whether it is an on-premises AD RMS cluster with the Mobile Device Extension or Azure RMS. Its APIs support standard programming languages and models for each operating system so, they are easy and familiar to work with. The RMS SDK 4.0 provides support in mobile devices (Android13, iOS14, Mac OS X15, Windows Phone, and Windows RT). For additional information on the RMS SDK 4.0, see the eponym MSDN page MICROSOFT RIGHTS MANAGEMENT SDK 4.0 16.

Prerequisites for the Mobile Device ExtensionThe Mobile Device Extension supports the following RMS clients:

Android phones and tablets. Minimum version of Android 4.0.3 iPhone and iPad. Minimum version of iOS 7.0 Mac OS X. Versions 10.8 and 10.9 Windows Phone. Minimum version of Windows Phone 8.1 Windows RT tablets. Windows 8 RT, Windows 8.1 RTNote The availability of the RMS client and SDK on an operating system does not necessarily imply the availability of the RMS Sharing app on that platform. In particular, the RMS Sharing app has not yet been released for Windows RT devices at the time of this writing.

These clients must use the latest version of the RMS sharing app for the devices as available for download at the Microsoft Rights Management page17.Beyond an existing on-premises AD RMS deployment on Windows Server 2012 or Windows Server 2012 R2, the following dependencies must be in place before using the Mobile Device Extension for AD RMS:

DNS SRV records to help locate the service endpoints provided by the Mobile Device Extension.

Both AD RMS internal (e.g., intranet) and external (e.g., extranet) FQDN URLs populated. (In a split brain DNS configuration, only the Intranet URLs are populated.)

Use of SSL/TLS with a trusted X.509 certificate for the AD RMS internal and external URLs.

AD FS deployed on Windows Server 2012 R2 to sustain the authentication required by the service endpoints.

Note For information on AD FS in Windows Server 2012 R2, see the Microsoft TechNet article WINDOWS SERVER 2012 R2 AD FS DEPLOYMENT GUIDE 18.

Some secure publishing mechanism such as the Web Application Proxy (WAP) deployed on Windows Server 2012 R2 to publish the service endpoints on the Internet.

13 SDK 4.0 for Android: http://www.microsoft.com/en-ie/download/details.aspx?id=4367314 SDK 4.0 for iOS: http://www.microsoft.com/en-us/download/details.aspx?id=4367415 SDK 4.0 for OS X: http://www.microsoft.com/en-za/download/details.aspx?id=4367516 MICROSOFT RIGHTS MANAGEMENT SDK 4.0: http://msdn.microsoft.com/en-us/library/dn758244(v=vs.85).aspx17 RMS sharing app for the devices: https://portal.aadrm.com/home/download18 WINDOWS SERVER 2012 R2 AD FS DEPLOYMENT GUIDE: http://technet.microsoft.com/en-us/library/dn486820.aspx


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


http://msdn.microsoft.com/en-us/library/dn758244(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/dn758244(v=vs.85).aspx

http://www.microsoft.com/en-za/download/details.aspx?id=43675


http://www.microsoft.com/en-ie/download/details.aspx?id=43673

If the AD RMS server is deployed behind a firewall or published by using a reverse proxy, in addition to publishing the service endpoints on the Internet, you must also publish the /my folder, for example https://adrms.litware369.com/my.

The next sections provide additional information on the service endpoints and depict how the above dependencies are being used by the Mobile Device Extension for AD RMS.

How mobile apps use the new service endpoints Note This section discusses how the Mobile Device Extension works under the hood to support mobile apps based on the RMS SDK 4.x. This section is included here for a deeper understanding of the technology, but this level of knowledge is not essential to be able to deploy the AD RMS Mobile Device Extension. If you are not interested in the details of how this technology works, you can skip directly to the section Building an evaluation environment below.

The Mobile Device Extension exposes the following endpoints in the form of REST APIs: Mobile Device Extension for AD RMS

Service discovery endpointRights management service endpoints

http

s://<

Clus

terU

RL>/

my/

v1/se

rvice

disc

over

y

REST

API

Tem

plates

requ

est

http

s://<

Clus

terU

RL>/

my/

v1/te

mpl

ates

REST

API

End

User

Lice

nse r

eque

stht

tps:/

/<Cl

uste

rURL

>/m

y/v1

/end

user

licen

ses

REST

API

Publ

ishing

Lice

nse r

eque

stht

tps:/

/<Cl

uste

rURL

>/m

y/v1

/pub

lishi

ng li

cens

es

In addition to the above REST service endpoints, the Mobile Device Extension provides a DNS-based service discovery mechanism in order to enable mobile devices to discover these endpoints based on the identity of the user or the source of the protected content. This will be further discussed below.

Publishing License requestWhen a mobile client has to protect content it calls the service to obtain the Publishing License to use for the document. This differs from Windows clients, where protection can be performed offline by the client by using keys contained in the Client Licensor certificate and other artifacts obtained during activation. In mobile devices such activation process does not exist, and all calls performed to the service are handled independently.

The Publishing License request takes either a template ID or a custom policy and returns a serialized Publishing License (PL) that is generated from the template or policy.

HTTP Method

Request URL HTTP Version

POST https://<ClusterURL>/my/v1/publishinglicenses HTTP 1.1


Where <ClusterURL> is the FQDN of an AD RMS cluster on top of which the Mobile Device Extension has been installed. This value will be obtained by calling the service discovery so that mobile devices can discover the endpoints based on the identity of the user.The request body includes a JSON-encoded template ID that corresponds to one of the templates that are configured for the tenant or custom (ad-hoc) policy. A successful request returns HTTP 200 OK with a body that contains the Publishing License (in base64 encoded form) in a JSON object.

End User License requestThe End User License request takes the publishing license of the protected content as a parameter and returns the end user license (EUL) for the calling user.

HTTP Method


POST https://<ClusterURL>/my/v1/enduserlicenses HTTP 1.1

Where <ClusterURL> is the FQDN of an AD RMS cluster on top of which the Mobile Device Extension has been installed. This value will be obtained by calling the service discovery so that mobile devices can discover the endpoints based on the identity of the user and the URL of the server that was used to protect the content.

The request body is a JSON object that contains the serialized publishing license (PL) (in base64 encoded form) that applies to the protected content. A successful request returns HTTP 200 OK with a body that contains the end user license (EUL).

Templates requestThe Templates request returns the list of templates that are available for the user in the server.

HTTP Method


GET https://<ClusterURL>/my/v1/templates HTTP 1.1

Where <ClusterURL> is the FQDN of an AD RMS cluster on top of which the Mobile Device Extension has been installed. There is no body for this request. A successful request returns HTTP 200 OK with a body that contains the list of templates that are available.

REST API errorsThis section describes the errors that can be returned by the aforementioned REST APIs and their format.The following table shows the HTTP error codes that the REST APIs can return.

HTTP Error Code

Description

200 OK Standard response for successful HTTP requests.400 Bad Request The request cannot be fulfilled because of bad syntax or set of


HTTP Error Code

Description

parameters.401 Unauthorized Returned when authentication is required and has failed or has not

yet been provided.500 Internal Server Error

Returned when something happened on the server and the client is not at fault.

When the REST API explicitly returns HTTP 400 and 500 errors (but not HTTP 401 errors), it also returns a message body that contains information about the error. The response body contains the following fields:

code. The fully qualified name of the exception that caused the error. message. A descriptive message that explains the error.

Understanding how the service endpoints are locatedUnlike with the cloud RMS service (Azure RMS) there is no universal location a client must go to deal with an AD RMS server deployed on-premises, so a service discovery mechanism is required. Windows clients can use the Service Connection Point (SCP) in Active Directory or, alternatively, registry-based overrides, to locate the RMS server in their environment. Mobile devices typically do not support being members of an Active Directory domain, nor can support registry-based configurations, so a different mechanism is used.

As mentioned before, the Mobile Device Extension provides a service discovery mechanism based on DNS SRV records in order to enable mobile devices to locate the necessary service endpoints. Such mechanism works in two steps:

Mobile Device Extension for AD RMS

Service discovery endpointRights management service endpoints

DNS SRV lookup

DNS

Service discovery call

1. The RMS client performs a DNS lookup for a SRV record corresponding to the user’s email domain (for authoring or template acquisition operations) or the content source server’s FDQN (for consumption operations), and processes the response from the DNS service to build the service discovery URL to call.

2. The client then contacts the URL obtained in the previous step and obtains the final REST APIs endpoints to call.


This two-step process allows mobile clients to identify the organization’s infrastructure in the first step and then locate the exact server desired for the user in the second step. This allows for very flexible configurations in which different users are directed to different servers, or in which clients are directed to servers that replace the ones used in the past to protect the content. Similar capabilities are provided in Windows clients through the use of registry values.

The second operation is implemented as an HTTP GET call to the REST APIs in MDE as follows:

HTTP Method


GET https://<ClusterURL>/my/v1/servicediscovery HTTP 1.1

Where <ClusterURL> is the FQDN of an AD RMS cluster built by the RMS client based on the DNS SRV lookup response. The response body will then contain the list of the aforementioned service endpoints and corresponding URLs in JSON format in the context of the request. The following JSON example illustrates a sample response body:

[{ "Name": "enduserlicenses", "Uri": "https://adrms.contoso.com/my/v1/enduserlicenses"},{ "Name": "templates", "Uri": "https://adrms.contoso.com/my/v1/templates"},{ "Name": "publishinglicenses", "Uri": "https://adrms.contoso.com/my/v1/publishinglicenses"}]

Since the first step of the endpoint discovery uses DNS and relies for that purposes on specific SRV service discovery records, the Service Connection Point (SCP) declared in the Active Directory is not used by the Mobile Device Extension.

Note The SCP is an object in the Active Directory configuration partition that holds the Web address of the AD RMS cluster. RMS-enlightened applications built with RMS SDKs whose version is prior to 3.0 use the SCP to discover the AD RMS service; it is the first connection point for users to discover the AD RMS SOAP-based web service endpoints. Only one SCP can exist in your Active Directory forest.

A SCP can be viewed using ADSI Edit for instance. To view the SCP, connect to the configuration container in ADSI Edit and navigate the following nodes: CN=Configuration [server name], CN=Services, CN=RightsManagementServices, CN=SCP.

From a practical standpoint, the RMS client uses DNS SRV records to find the right location for the services used for:

1. Authoring, i.e. protecting a file.2. The consumption of a protected file.

Different DNS SRV records must be consequently created in the authoritative DNS for the organization’s domain(s) to support these processes. The next sections cover the DNS SRV records required for a fully functional RMS service discovery mechanism for mobile devices.


Understanding the DNS SRV service discovery records to createTo operate and enable the aforementioned scenarios, the Mobile Device Extension requires the creation in the DNS service one or more DNS SRV service discovery records in the organization’s domain(s) as per RFC 6763 DNS-BASED SERVICE DISCOVERY19:

One record for each email domain suffix that users will use. One record for every FQDN used by the AD RMS clusters in place to protect content.

Service discovery record for the email domain suffixDuring first use of the mobile applications to protect content, users will be asked for their email address. The domain part of this address will be used to locate the right RMS infrastructure to handle the user’s operations.The service discovery record that relates to the email domain suffix for the user has the following format:

_rmsdisco._http._tcp.<email suffix><port number><AD RMS cluster FQDN>Where:

<email suffix> is the email domain suffix that users will use, <port number>is the port number used by an on-premises AD RMS cluster, <AD RMS cluster FQDN> is the FQDN used by an on-premises AD RMS cluster.

When users supply their email address from their mobile device, the domain suffix is used to identify whether they should use an on-premises AD RMS cluster or Azure RMS. When the SRV record is found, the RMS client redirects to the RMS service that responds to this record (see below).

Important note If all the users of the organization use child domains from a single parent domain, and all users from this contiguous namespace use the same AD RMS cluster, only one SRV record in the parent domain is needed, and the RMS client will find the appropriate DNS records (see below).

For example, if an organization has users with the following email addresses: <user alias>@contoso.com <user alias>@europe.contoso.com <user alias>@fabrikam.com

And if there are no other child domain(s) for contoso.com and no other parent domain(s) that use a different AD RMS cluster than the one named adrms.contoso.com, the following two DNS SRV records must be created in DNS:

_rmsdisco._http._tcp.contoso.com 443 adrms.contoso.com_rmsdisco._http._tcp.fabrikam.com 443 adrms.contoso.com

19 RFC 6763 DNS-BASED SERVICE DISCOVERY: http://www.ietf.org/rfc/rfc6763.txt


Service discovery record for the FQDN used by the AD RMS clusters in place When consuming protected content, the mobile apps will use the URL in the Publishing License in the content to identify the right server to reach out to. Since it is possible that the original server has been replaced by another server with a different URL, a DNS-based service discovery call is performed based on the URL in the PL. The service discovery record that relates to the FQDN used by an AD RMS cluster in place to protect content has the following format:

_rmsdisco._http._tcp.< AD RMS cluster FQDN><port number><AD RMS cluster FQDN>Where:

<AD RMS cluster FQDN> is the FQDN used by an on-premises AD RMS cluster, <port number>is the port number used by an on-premises AD RMS cluster.

For example, if an AD RMS cluster deployed on-premises is adrms.contoso.com and it is desired that the same cluster, which has MDE installed, is used to consume content with mobile devices, a DNS SRV record that has the following value must be created in DNS:

_rmsdisco._http._tcp.adrms.contoso.com 443 adrms.contoso.comNote that since this organization also has users using the same domain in their email addresses, this DNS entry is already included in those used for email domain-based service discovery. Thus, the organization used in this example would only need two DNS SRV records for RMS service discovery. The next sections depict how these SRV records are queried by mobile devices to dynamically discover the endpoints for authoring and consuming content thanks to the above service discovery mechanism.

Understanding the basic flow for authoring contentThe process for a mobile RMS-enlightened app to author content is as follows. The app uses the RMS SDK 4.0 and thus the related RMS client:

AD FS

1: Query for user subdomain and iterate up

Active Directory

AD RMS w/ Mobile Device Extension

DNS

2: Pointer to service discovery endpoint

8: Access token with user claims5: Authentication

7: User attributes

6: Authenticate and query user attributes

3: Query REST URL for user·s email address*

4: Redirect to AD FS9: Request REST URL with access token

10: Return same cluster·s REST endpoint11: Request PL

12: PL


1. For the initial domain resolution, the user specifies their email address in the app. The RMS client calls the DNS service and queries for the service discovery record which corresponds to the user’s email domain suffix.If not found, the RMS client repeats the call for the user’s email address domain’s parent and iterates the process until a match is found or it reaches the second level domain. As previously noted, this allows to use only one DNS SRV record in the parent domain if all of all the users of the organization use child domains from a single parent domain, and all users from this contiguous namespace use the same AD RMS cluster.

2. This record points to the on-premises AD RMS cluster.The response from the DNS service is processed by the RMS client to build the service discovery URL to call.

3. The RMS client then makes a service discovery call to the endpoint URL discovered previously.

4. On initial access the call to this endpoint will return a 401 error code and will redirect the client to the environment’s federation server where the authentication process will be performed as described in section § UNDERSTANDING HOW AUTHENTICATION WORKSWITH THE SERVICE ENDPOINTS below in this document. Steps 5-8 of the authentication process are explained in that section.

5. Once the client has obtained an access token, it passes the token to the service discovery URL to which it tried to authenticate

6. Upon acceptance of the token received from the service the URL of the RMS cluster is used by this user. The service discovery endpoint returns a list of rights management services (publish license, end user license, and templates) and corresponding endpoint URLs. These endpoints may be in the same RMS cluster (i.e. under the same FQDN) or in a different cluster if RMS is configured to direct the calling user to a different server. This may be done in the case where Licensing-Only clusters are deployed in the environment to handle different groups of users.Note that in this example, this is the same RMS cluster.

7. The client contacts the URLs obtained in the previous step in order to obtain from the service the templates, and then the publishing license (PL).

8. The app can finally protect the content.As illustrated above, the publishing licenses (PL) are built by the AD RMS server and embedded by the RMS client, and all the transactions are atomic:

The client trusts the service endpoint URLs, and SSL/TLS is mandatory. There is no Server Licensor Certificate (SLC). The SLC is issued to licensing servers and grants them the right to issue PL, end use licenses (UL), client licensor certificates (CLC), and rights policy templates.

The client authenticates and acquires PL in one operation. There is no Rights Account Certificate (RAC). The RAC identifies a user in the context of a specific computer or device.) Consequently, there is no machine certificate either.

The client builds the policy and gets the PL from the server. There is no CLC. The CLC grants a user the right to publish (offline) AD RMS-protected content.


Note For introduction on the AD RMS certificates and licenses, see the post LICENSES AND CERTIFICATES, AND HOW AD RMS PROTECTS AND CONSUMES DOCUMENTS 20 on the AD RMS Team Blog.

The Mobile Device Extensions do not support offline publishing from mobile devices at the time of publishing of this document.

Understanding the basic flow for consuming contentWhen a user consumes protected content with a mobile device, the process for the mobile RMS-enlightened app to activate is as follows. The app uses the RMS SDK 4.0 and thus the related RMS client:

AD FSActive Directory

DNS

2: Pointer to service discovery endpoint

8: Access token with user claims5: Authentication

7: User attributes

6: Authenticate and query user attributes

3: Query REST URL for Licenisng URL for the users email address

4: Redirect to AD FS9: Request licensing URL with access token

10: Return same cluster·s REST endpoint11: Request EUL

12: EUL

1. For the initial domain resolution, the RMS client looks in DNS for a service discovery record that matches the FQDN in the URL of the RMS service that protected the content. This URL is specified in the publishing license.

2. The response from the DNS service is processed by the RMS client to build the discovery service URL to call.

3. The RMS client then makes a call to the service discovery endpoint in the URL discovered previously.

4. On initial access the call to this endpoint will return a 401 error code and will redirect the client to the environment’s federation server where the authentication process will be performed as described in section § UNDERSTANDING HOW AUTHENTICATION WORKSWITH THE SERVICE ENDPOINTS below in this document. Steps 4-7 in this authentication process are explained in that section. Once the client has obtained an access token it passes the token to the service discovery URL to which it tried to authenticate.

5. Upon acceptance of the token received from the service the URL of the RMS cluster is used by this user.

6. The service discovery endpoint returns the list of rights management services (publish license, end use license, and templates) and corresponding endpoint URLs is provided to the client in the response (as described before). These endpoints may be in the same RMS cluster (i.e. under the same FQDN) or in a different cluster if RMS is configured to direct the calling user to a different server. This may be done in the

20 UNDERSTANDING INFORMATION RIGHTS MANAGEMENT: http://technet.microsoft.com/en-us/library/dd638140.aspx


http://blogs.technet.com/b/rms/archive/2012/04/16/licenses-and-certificates-and-how-ad-rms-protects-and-consumes-documents.aspx

http://blogs.technet.com/b/rms/archive/2012/04/16/licenses-and-certificates-and-how-ad-rms-protects-and-consumes-documents.aspx

case where Trusted Publishing Domains are exchanged between RMS clusters to have one cluster handle the load for some or all users for content protected in another cluster.

7. The RMS client then makes a call to the endpoint discovered previously passing the access token in order to acquire an end use license (EUL) to open the content.

8. Once a EUL has been issued the mobile RMS-enlightened app finally renders the content.

As illustrated above, the EULs are delivered by the AD RMS server to the RMS client every time and, likewise the previous flow, all the transactions are atomic. As previously outlined:

The client trusts the service endpoint URLs, and SSL/TLS is mandatory. There is no SLC.

The client authenticates and acquires EUL in one operation. There is neither RAC nor machine certificate.

Understanding how authentication works with the service endpointsAs discussed above, the Mobile Device Extension for AD RMS enables to expose rights management service endpoints on top of the RMS service for consumption of protected content and for authoring of new content. Most mobile devices do not support the NTLM or Kerberos protocols for authentication and thus need to use a different mechanism to authenticate to the different interfaces in the RMS server, including connecting to the service discovery endpoint. For that purpose, the Mobile Device Extension for AD RMS leverages the OAuth 2.021 open standard protocol for authentication and authorization. The above step 3 more specifically uses the OAuth 2.0 authorization code grant flow: a public client (e.g. the RMS-enlightened app) receives consent (in the form of an authorization code) from a resource owner (e.g. the user) to access a protected resource (e.g. the RMS service) on their behalf. The client then redeems the authorization code for an access token and a refresh token, to access the protected resource.ADFS in Windows Server 2012 R2 exposes the following two endpoints in order to sustain the above OAuth 2.0 grant flow:

1. Authorization endpoint: https://<ServerURL>/adfs/oauth2/authorize The authorization endpoint is used to interact with the RMS client and obtain an authorization code which will be issued to the app. AD FS authenticates the user before granting the authorization code. This authorization code will be exchanged by the app for an access token.

2. Token endpoint: https://<ServerURL>/adfs/oauth2/tokenThe token endpoint is used by the app to obtain an access token by presenting its authorization code.

Where <ServerURL> is the FQDN of the ADFS server/farm specified during the installation of the Mobile Device Extension for AD RMS.

21 RFC 6749 THE OAUTH 2.0 AUTHORIZATION FRAMEWORK: http://www.ietf.org/rfc/rfc6749.txt


http://www.ietf.org/rfc/rfc6749.txt

The overall flow to obtain an access token is as follows:

AD FS

AD RMS w/ Mobile Device Extension

2

3 4

1

5

1. The RMS client makes a call to a service endpoint to perform an operation on the RMS service by making a call to the URL obtained thanks to one of the created DNS SRV records.

2. The RMS service finds out that the authentication has not happened yet. It returns back an OAuth 2.0 challenge. More specifically, it returns back a HTTP 401 with two fields in the HTTP body. One is the resource name that identifies the service endpoint, and the other is the URL to the local AD FS server/farm to interact with to obtain an access token. This URL is set during the installation of the Mobile Device Extension for AD RMS.

3. The RMS client takes this response and goes to the URL identified in the response from the RMS service.

a. In accordance to the OAuth 2.0 authorization code grant flow, it makes an authorization request to AD FS for the resource (again in the response from the RMS service) to get an authorization code. This call comprises the service endpoint the app wants to access, an app client identifier, and an app redirection URI in accordance with RFC 6749.

Note In order to allow access from OAuth 2.0 clients to REST resources secured by AD FS, the app has to be registered beforehand with AD FS by using the cmdlet Add-AdfsClient22. AD FS will not allow access to a REST resource to clients that specify a client identifier or redirection URI that is not registered with AD FS. For additional information, see Microsoft MDSN article DEVELOPING MODERN APPLICATIONS USING OAUTH AND ACTIVE DIRECTORY FEDERATION SERVICES 23.

b. AD FS authenticates the user and issues an authorization code.c. The app gets the authorization code, and then does a post to the AD FS token

endpoint to get an access token, passing the app client identifier, the redirection URI (this just has to match up with what was sent previously and isn’t used as a redirect), and the authorization code received in the previous step.

4. AD FS issues an access token for the user.5. The RMS client gets the access token and makes the request again but this time with

the access token it got from AD FS. The RMS service validates the access token and if authorized responds to the request appropriately.

22 ADD-ADFSCLIENT: http://technet.microsoft.com/en-us/library/dn479319.aspx23 DEVELOPING MODERN APPLICATIONS USING OAUTH AND ACTIVE DIRECTORY FEDERATION SERVICES: http://msdn.microsoft.com/en-us/library/dn633593.aspx


http://msdn.microsoft.com/en-us/library/dn633593.aspx



The follow diagram synthetizes the OAuth 2.0 authorization code grant flow in the above step 3:

Note The Active Directory Authentication Library (ADAL) library offers a simple programming model in client applications for AD FS in Windows Server 2012 R2 and for Azure Active Directory (AAD). Its main purpose is to help developers easily obtain access tokens from AD FS in Windows Server 2012 R2 or from AAD, which can then be used for requesting access to protected resources like the Mobile Device Extension for AD RMS REST APIs in the context of this document. ADAL provides supports in mobile devices (Android24, iOS25, Windows Phone, and Windows RT), and Mac OS X26. ADAL is available as Open Source code on GitHub so that you can participate in the development process. A full suite of sample applications and documentation is provided on GitHub27 to help you get started. This includes tutorials for the above mobile devices and full walkthroughs for authentication flows such as OAuth2 in the context of this paper.

The RMS service expects that ADFS provides the following claims in the access token: Primary email address of the user, User principal name (UPN) of the user, Proxy email addresses of the user if present.

The format used for the access token is JSON Web Token (JWT)28, a compact JSON-encoded security token bearing claims. As such, JWT is especially apt for REST-based development. JWT use is growing, and products supporting the format are increasingly common in the industry.

24 Microsoft Azure Active Directory Authentication Library (ADAL) for Android: https://github.com/AzureAD/azure-activedirectory-library-for-android25 Microsoft Azure Active Directory Authentication Library (ADAL) for iOS: https://github.com/AzureAD/azure-activedirectory-library-for-objc26 Microsoft Azure Active Directory Authentication Library (ADAL) for OSX: https://github.com/AzureAD/azure-activedirectory-library-for-objc:27 Microsoft Azure Active Directory Samples and Documentation: https://github.com/AzureADSamples28 JSON Web Token (JWT): http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-24


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

https://github.com/AzureADSamples

https://github.com/AzureAD/azure-activedirectory-library-for-objc

https://github.com/AzureAD/azure-activedirectory-library-for-objc

https://github.com/AzureAD/azure-activedirectory-library-for-android

Reviewing the supported topologies for the Mobile Device ExtensionWhilst IT professionals can deploy AD RMS in a myriad of possible topologies - combining multiple clusters of different types with different trusts – to accommodate requirements that vary significantly from one organization to another, the Mobile Device Extension is designed to operate in the most common topologies used by organizations. While it may be possible for AD RMS to work in other topologies it is not the scope of this paper, and the Mobile Device Extension may not support some specific configurations. These supported topologies for the Mobile Device Extension can be grouped and listed as follows:

Single forest with a single cluster. Multiple forests with multiple certification clusters and a single licensing point. Multiple forests with multiple certification clusters used for licensing. Single or multiple forest with licensing-only clusters. Cross-organization with federated trusts. Trusted Publishing Domain (TPD) key imported from existing or deprecated AD RMS

server.While other topologies may be possible with AD RMS, they are NOT supported with the Mobile Device Extension for AD RMS at the time of publishing.The next sections provide a short depiction of the considered topologies along with the considerations that apply to each.

Single forest with as single clusterIn this topology, an organization has only a single forest in which AD RMS can be used. All users and servers that interact with RMS are hosted in that forest. This topology is the most commonly one deployed. Consequently, the deployment of the Mobile Device Extension for AD RMS will be illustrated later in this document using this topology.One AD RMS cluster is installed in that forest and typically the aforementioned service connection point (SCP) is configured in Active Directory. Since all licensing and certification URLs point to the same cluster, and all users in the organization, regardless of their email domain or sub-domain, use the same cluster, the DNS SRV records for the discovery service mechanism point to that cluster’s URL as follows:

Service discovery record for email domain suffix RMS service FQDN Service discovery record for AD RMS cluster licensing URL RMS service FQDN

No additional redirection is needed at the AD RMS cluster.

Multiple forests with multiple certification clusters, all using the same cluster for licensingIn multi-forest organizations where users are scattered around domains in multiple forests, AD RMS architectural design requires that one AD RMS cluster is deployed in each forest to enable certification of the different users.


To simplify logging, troubleshooting, configuration and deployment most organizations configure the licensing ULRs in all the different certification clusters to point to the licensing location of one of the clusters, in essence making this cluster the only cluster that will be utilized to protect content. (This cluster may be either the certification cluster in one of the forests or a licensing-only cluster installed in one of the forests in addition to that forest’s certification cluster). This so-called "centralized licensing" cluster is populated with trusted user domains (TUD) from all other clusters, and domain or forest trusts between the different forests are usually configured to enable cross-forest authentication and group expansion.

Note For information on Trusted User Domains (TUD), see the eponym Microsoft TechNet article TRUSTED USER DOMAIN 29.

As a consequence, while Rights Account Certificates containing different certification URLS and signed by different clusters are issued to rich clients in different forests, all clients receive a Client Licensor Certificate from the same cluster, and all Publishing Licenses will be encrypted with the same key pair and will be stamped with the same URL.

Important Note Since in mobile devices working with the Mobile Device Extension for AD RMS all transactions are atomic and there’s no use for Rights Account Certificates, clients only interact with the RMS cluster used for licensing. The existence of an RMS cluster in a forest that is only used for certification is of no consequence to the mobile clients, and as a results Trusted User Domains are not used for mobile devices. This, in turn, means that only cluster actively used for licensing need to have the Mobile Device Extension installed, and clusters only used for certification in their respective forests don’t need to be configured for mobile devices directly.

In this environment, users may have email addresses under the same or different domains. All publishing licenses contain the same URL.

Protecting content in this topologyWhen a user tries to protect content with a mobile device, the service discovery records for the user’s email address domain or, recursively, a parent domain of that domain will point the user to the single licensing cluster. Authentication will be triggered when trying to acquire a Publishing License to protect content and the federation flow will involve authentication in the user’s source forest as needed. Authentication for users in a forest different from the one used for licensing may be achieved through a federated trust between AD FS servers in the different forests, or via a single AD FS server in the forest where licensing is being performed by using AD trusts established between the forests to authenticate users in their respective forests.Aside from the underlying requirements of setting up such a federation topology, the details of the authentication flow between the different forests are abstracted by the federation server platform, and all that matters to the Mobile Device Extension is that, once authenticated in its own forest, the user will be granted a valid access token with the necessary claims to connect to the service endpoints in the RMS cluster. One that happens, the user trying to protect content will be issued a Publishing License as required. When the RMS client tries to protect content, the service discovery mechanism has to return to the client the licensing URL in the organization which is the same for all users. Once the user has entered their email the licensing URL of the organization is returned and the user starts the authentication process against that URL which will be performed using AD FS and the multiple directories involved, but ultimately will lead to the user being connected to the Publishing URL in MDE in the cluster used for licensing.

29 TRUSTED USER DOMAIN: http://technet.microsoft.com/en-us/library/dd983944(v=WS.10).aspx


http://technet.microsoft.com/en-us/library/dd983944(v=WS.10).aspx

Consuming content in this topologyLikewise, when a user tries to consume protected content with a mobile device, the service discovery records for the URL in the Publishing License in the document will point the client to the URL of the cluster used to protect the content. Authentication will be triggered when trying to acquire a EUL and there the federation flow will proceed just as for the authoring scenario and involve authentication in the user’s source forest as needed. Once authenticated, the user is able to acquire a EUL from the cluster that protected the content.If the PL indicates groups as recipients of rights that are defined in any other forest, AD RMS will perform remote group expansion by utilizing the remote clusters group expansion services, but this will be completely transparent to the mobile device client and the REST related implementation.

Multiples forests with multiple licensing and certification clustersSometimes, organizations deploy multiple certification clusters with different licensing URLs in their multi-forest environment. In this case, MDE needs to be installed in each cluster utilized for licensing, and each of them needs to be configured to use AD FS in a way that supports authenticating all users that will be using that cluster to protect or consume content.

Protecting content in this topologyWhen a user tries to protect content with a mobile device, the email domain of the user will be used to find the corresponding server and the service discovery mechanism will direct the user to the right cluster. As in the previous topology authentication might involve Federation across the different forests depending on the forest to which the user belongs. If all users in the organization use email domains specific to the forest to which each user belongs, then different records for each domain will point the user directly to the RMS cluster in the right forest. In this case the user will be authenticated via AD FS locally in the same forest. If all users and organization share the same email domain or there isn’t a one to one mapping between email domains and forests, the user will be directed to the RMS cluster in one of the forests by the service discovery record corresponding to the email domain, and the post-authentication service discovery process will be used to direct the user to the RMS cluster that the user should use to protect content. This process uses information in a table associating Active Directory groups to the corresponding RMS FQDN to direct the user to the right cluster. As in the previous topology, authentication might involve federation across the different forests depending on the forest to which the user belongs. A properly configured federation environment will be then required to authenticate the user against their source forest.

Consuming content in this topologyIn this configuration there will be content protected with different URLs depending on where the author was located. This means that the service discovery records for consumption will include entries for each of the clusters in the organization that are used for licensing as indicated before.


When content is consumed by a mobile device user, the RMS client will use the service discovery record for the URL indicated in the PL in the protected document which typically will lead the user to the cluster that was used by the author to protect the content. The client authentication will be triggered by access to the URLs in the authors cluster. As in the previous topology authentication might involve federation across the different forests depending on the forest to which the user belongs. A properly configured federation environment will be then required to authenticate the user against their source forest. If the federation setup can identify the user’s source forest and authenticate it accordingly (which is possible at least if there are forest trusts in place) the user should be authenticated properly and the necessary claims extracted. Once the necessary tokens are obtained including the claims for the user’s email address the user may be redirected to a different RMS cluster for obtaining an End User License. This is done in cases in which it is desired that the user consume content using a different cluster with an Imported Trusted Publishing domain from the source cluster. In most cases, the cluster used to consume content is the same used to protect it. After the user reaches the licensing URL in the right cluster, an End Use License will be issued by the cluster in the document author’s forest.

Single or multiple forest with a licensing-only clusterSometimes, organizations deploy multiple licensing-only clusters in their environment. A Licensing-Only cluster is a cluster deployed in the same forest as a certification cluster. The Licensing-Only cluster is subordinated to the certification cluster, which will handle all certification requirements in the forest.In these organizations some individual users need to be pointed to different service URL to protect content than other users with the same or different email domain. For example a group of high-level executives might need to use a special AD RMS cluster, which is different from the one used by all the other users at the company. In most environments where this is the case, different licensing clusters are thus assigned to different users via registry overrides. This will not be possible with the mobile RMS clients since mobile devices do not support registry overrides or any other kind of manageable persistent application configuration.

Protecting content in this topologyWhen content is protected in this topology, the DNS-based service discovery will point the user to the default cluster for the user’s email domain. If the users assigned to a licensing only cluster share the same email domain with users assigned to different cluster then after authentication group membership-based redirection based on a table in the RMS configuration database associating Active Directory groups with RMS clusters will point the user to the licensing only cluster that corresponds to them.

Consuming content in this topologyConversely, when content is consumed in this topology, the DNS-based service discovery will point the user to the cluster that was used to protect the content. Authentication at this cluster might involve federation between forests or it might be performed within a single forest. Once the user is authenticated a EUL will be issued by the licensing only cluster just as in the single cluster case.


Cross-organization with federated trustSome organizations collaborate with other organizations via federated trusts. In these cases, rich clients are activated, obtain CLC’s, and consume content with the same AD RMS cluster. Since authentication is performed on the mobile device clients through a federation flow, the fact that these partners are external users should be opaque to the clients and to the service, and this topology looks exactly like the single cluster, single forest scenario topology for implementation purposes. As long as the federation platform is correctly configured and is able to authenticate the external users they will receive the right artifacts and be able to acquire licenses from the organization’s AD RMS cluster. If an organization wants their federated partners to be able to protect content against their cluster, the organization will need to configure the DNS-based service discovery for their email domains to point to the controlling organization’s AD RMS cluster.

TPD Imported from existing or deprecated AD RMS serverIn some organizations with special requirements, multiple clusters are deployed (possibly at different times) and trusted publishing domains (TPD) are exchanged between them. Clients are then configured to consume content from one cluster even though it has been protected with another cluster. The typical reasons for such environments are related to network topologies, isolated environments, and decommissioned clusters in migrations or merger scenarios.

Note For information on trusted publishing domains (TPD), see the eponym Microsoft TechNet article TRUSTED PUBLISHING DOMAIN 30.

This redirection is typically implemented via registry overrides on rich clients. As already noticed, the mobile device clients do not support registry overrides.

Protecting content in this topologyA user is directed to whatever URL is registered for the user’s email domain name in DNS in accordance to the service discovery record(s). The user may or may not be redirected to a different cluster for acquiring a PL based on the group-cluster mapping table in the configuration database, just as in the regular multi-forest environment.

Consuming content in this topologyFor consumption, the RMS client would look up in DNS the service discovery record for the domain in the PL. This may point the user to the same cluster that was used to protect the content (the default single-forest behavior) if that cluster is still available, or to a cluster with an imported TPD if that cluster is not available or not intended to be used by this user. In either case, the user may be redirected based on group membership to a different cluster (the original one or another one with a TPD) for a variety of reasons (e.g. geographical affinity). Once the client reaches the right cluster successfully, the server can use the imported Trusted Publishing Domain to issue an End User License for the content.

30 TRUSTED PUBLISHING DOMAIN: http://technet.microsoft.com/en-us/library/dd996639(v=ws.10).aspx


http://technet.microsoft.com/en-us/library/dd996639(v=ws.10).aspx

Building an evaluation environmentThis section guides you through a set of instructions required to build a representative lab environment to evaluate the Mobile Device Extension.For the sake of simplicity and in order to focus on the key aspects that relate to the Mobile Device Extension deployment, the chosen test topology is a single cluster in a single forest.The guidance in this lab can also be utilized to deploy the Mobile Device Extension in a production environment, but adjustments to the process will be necessary depending on the target environment’s topology, configuration and state.It must be noted that this guide not only covers the deployment of the Mobile Device Extension, but also that of AD RMS and its databases, the Active Directory domain, AD FS and other pre-requisite software. When applying this guide to a preexisting environment most of the detailed steps have to be adapted or omitted accordingly.Beyond the AD RMS cluster with its SQL Server database, the environment includes:

A single AD FS server integrated with Active Directory for authentication, A single WAP proxy to publish on the Internet the Mobile Device Extension service

endpoints, A single Active Directory Certificate Services (AD CS) based certification authority to

issue the required certificates, The following diagram provides an overview of the overall test lab environment with the software and service components that need to be deployed / configured.

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)

Web Application Proxy

Internal Virtual Network SwitchCorpnet

External Virtual Network SwitchInternet

Internet

ADRMS1

Active Directory Rights Management Services (AD RMS)Mobile Device Extensions for AD RMS

SQL1 SQL Server 2012

In this environment we have simplified as much as possible the environment to reduce the number of actions needed.

Building an Azure-based lab environment A challenge in creating a useful lab environment is to enable its 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. For that reason and considering the above objectives, this guide will use for the corporate on-premises infrastructure the Microsoft Test Lab Guides (TLGs) available on Microsoft TechNet to build the lab environment.

The Microsoft Test Lab Guides (TLGs) allow you to get valuable hands-on experience with new products and technologies using a pre-defined and tested methodology that results in a working configuration. Microsoft Test Lab Guides (TLGs) are a set of documents that step you through the configuration and demonstration of a Microsoft technology or product in a standardized test lab environment, which starts with a common base configuration that mimics a simplified intranet and the Internet. TLGs are designed to be modular, extensible, and stackable to configure complex, multi-product solutions. TLGs make learning about products, technologies, and solutions easier by providing that crucial hands-on, “I built it out myself” experience.

Note For more information, see Test Lab Guides31 on Microsoft TechNet.

Moreover, another potential challenge relates to the hardware needed to run such a base configuration that involves several (virtual) machines. For these reasons and considering the above objectives, this guide will leverage Microsoft Azure environment with Azure-based virtual machines (VM). Consequently, the setup of the on-premises environment for this evaluation of the Mobile Device Extension will be based on the TEST LAB GUIDE: BASE CONFIGURATION IN AZURE 32. It will also leverage the TEST LAB GUIDE: DEPLOYING AN AD RMS CLUSTER 33.Finally, to streamline as much as possible the setup of this Azure-based test lab environment, and to test and evaluate the Mobile Device Extension for AD RMS, this guide will also leverage the Microsoft Azure PowerShell and Windows PowerShell cmdlets to configure the required services.

Introducing virtual machines in AzureAzure Virtual Machines34 provides support for virtual machines (VMs) provisioned from the cloud. At a glance, a VM consists of a piece of infrastructure available to deploy an operating system and an application. Specifically, this includes a persistent operating system (OS) disk, possibly some persistent data disks, and internal/external networking “glue”/connectivity to hold it all together. With these infrastructure ingredients, it enables the creation of a platform where you can take advantage of the reduced cost and ease of deployment offered by Azure.To mimic an on-premises deployment with a multi-VM workload as needed here, virtual networks are also required. This is where Azure Virtual Networks come into play. Azure 31 Microsoft TechNet Test Lab Guides: http://www.microsoft.com/testlabguides32 TEST LAB GUIDE: BASE CONFIGURATION IN AZURE: http://www.microsoft.com/download/details.aspx?id=4168433 TEST LAB GUIDE: DEPLOYING AND AD RMS CLUSTER: http://technet.microsoft.com/en-us/library/adrms-test-lab-guide-base34 Azure Virtual Machines: https://www.windowsazure.com/en-us/services/virtual-machines/


https://www.windowsazure.com/en-us/services/virtual-network/

https://www.windowsazure.com/en-us/services/virtual-machines/

http://technet.microsoft.com/en-us/library/adrms-test-lab-guide-base

http://technet.microsoft.com/en-us/library/adrms-test-lab-guide-base

http://www.microsoft.com/download/details.aspx?id=41684

http://microsoft.com/testlabguides

Virtual Network35 let you provision and manage virtual networks (VNET) in Azure. A VNET provides the ability to create a logical boundary and place VMs inside it. VNET also provides the capability of connecting Azure Cloud Services36 (VMs, web roles, and worker roles) that are in the same affinity group directly with them.

Note An affinity group is a container where you choose the location (Azure region) where you place your Azure resources. An affinity group represents also a convenient way to designate an Azure data center region with the name of your choice. (As of this writing, Azure Cloud Services can be added to an affinity group only at the time of creation of the service.).

Azure Virtual Network provides control over network topology, including configuration of IP addresses, routing tables and security policies. A VNET has its own private address space. The address space is IPv4 only (but could be extended to IPv6 in a future release).

Note Azure Virtual Network also allows to securely extend on-premises networks into the cloud. With the ability to assign a private address range for its VNET, you can indeed treat it as an extension of your own corporate private network address space by establishing appropriate gates (VPN gateway) between your on-premises corporate private network and virtual network(s) in Microsoft Azure. For that purpose, Azure Virtual Network enables to set up secure site-to-site connectivity between the organization’s corporate VPN gateway and Azure, and then to connect the organization’s on-premises corporate network to the organization’s Azure tenant by using a VPN gateway along with the industry-standard IPsec protocol.

With such a capability, IT administrators can easily create a logically isolated private environment in Azure, and connect it to the organization’s on-premises IT infrastructure by using a secure VPN tunnel. Once set up, the isolated Azure environment can be viewed as a natural extension of the on-premises corporate network.

To synthetize, Azure Virtual Network allows you to create private network(s) of VMs in your Azure tenant environment that you can assign IP addresses to (and then optionally connect to your data center through a VPN gateway). Using this method, you can seamlessly connect on-premises (virtual) machines to VMs running in your Azure tenant.The fundamental requirements for deploying AD DS on VM(s) in Azure differ very little from deploying it in VMs (and, to some extent, physical machines) on-premises. For example, if the domain controller that you deploy on VMs are replicas in an existing on-premises corporate domain/forest, then the Azure deployment can largely be treated in the same way as you might treat any other additional AD DS site. That is, subnets must be defined in AD DS, a site created, the subnets linked to that site, and connected to other sites using appropriate site-links. There are, however, a number of differences that are common to all Azure deployments and some that vary according to the specific deployment scenario.

35 Azure Virtual Networks: https://www.windowsazure.com/en-us/services/virtual-network/36 Azure Cloud Services: https://www.windowsazure.com/en-us/services/cloud-services/


http://www.windowsazure.com/en-us/home/scenarios/cloud-services/

https://www.windowsazure.com/en-us/services/virtual-network/

Note For more information, see the Microsoft TechNet articles INSTALL A NEW ACTIVE DIRECTORY FOREST IN WINDOWS AZURE 37 and GUIDELINES FOR DEPLOYING WINDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE VIRTUAL MACHINES 38 that cover the fundamental differences and explain in great detail how successfully deploy and operate AD DS in Azure. The former deals with a standalone configuration in the cloud as we will deploy later in this document whereas the latter highlights the requirements for deploying AD in a hybrid scenario in which AD DS is partly deployed on-premises and partly deployed on VMs in Azure.

Understanding the ongoing costs of virtual machines in AzureVirtual machines in Azure incur an ongoing monetary cost when they are running. This cost is billed against your free trial, MSDN subscription, or paid subscription.

Note For more information about the costs of running Azure virtual machines, see VIRTUAL MACHINES PRICING DETAILS 39 and AZURE PRICING CALCULATOR 40 on the Azure Web site.

To minimize the cost of running the test lab virtual machines, you can do one of the following:

Create the test lab environment and perform your needed testing and demonstration as quickly as possible. When complete, delete the test lab virtual machines from the VIRTUAL MACHINES page of the Azure management portal.

Shut down your test lab virtual machines into a de-allocated state from the VIRTUAL MACHINES page of the Azure management portal as covered later in this document. However, you should start your virtual machines in a specific order.

Signing up for an Azure trialIf you do not already have an Azure account, you can sign up for a free one month trial41. If you have an MSDN Subscription, see AZURE BENEFIT FOR MSDN SUBSCRIBERS 42 on the Azure Web site.

Note Once you have completed your trial tenant signup, you will be redirected to the Azure account p ortal 43 and can proceed to the Azure management portal by clicking Portal at the top right corner of your screen.

At this stage, you should have an Azure trial subscription to proceed with the steps in this guide.

Preparing the local environment for AzureMicrosoft Azure PowerShell is the module for Windows PowerShell that you can use to control and automate the deployment and management of the workloads in Azure.

37 INSTALL A NEW ACTIVE DIRECTORY FOREST IN WINDOWS AZURE: http://www.windowsazure.com/en-us/manage/services/networking/active-directory-forest/38 GUIDELINES FOR DEPLOYING WINDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE VIRTUAL MACHINES: http://msdn.microsoft.com/en-us/library/windowsazure/jj15609039 VIRTUAL MACHINES PRICING DETAILS: http://azure.microsoft.com/en-us/pricing/details/virtual-machines/40 AZURE PRICING CALCULATOR: http://azure.microsoft.com/en-us/pricing/calculator/?scenario=virtual-machines41 FREE ONE MONTH TRIAL: http://azure.microsoft.com/en-us/pricing/free-trial/42 AZURE BENEFIT FOR MSDN SUBSCRIBERS: http://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-details/43 Windows Azure account portal: https://account.windowsazure.com/Subscriptions


https://account.windowsazure.com/Subscriptions

https://account.windowsazure.com/Subscriptions

http://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-details/

http://azure.microsoft.com/en-us/pricing/free-trial/

http://www.windowsazure.com/en-us/pricing/calculator/?scenario=virtual-machines

http://azure.microsoft.com/en-us/pricing/details/virtual-machines/

http://azure.microsoft.com/en-us/pricing/details/virtual-machines/

http://msdn.microsoft.com/en-us/library/windowsazure/jj156090

http://msdn.microsoft.com/en-us/library/windowsazure/jj156090

http://www.windowsazure.com/en-us/manage/services/networking/active-directory-forest/

http://www.windowsazure.com/en-us/manage/services/networking/active-directory-forest/

Installing and configuring Azure PowerShellThe configuration of Azure PowerShell on a local computer consists of:

Installing Azure PowerShell, Verifying that Azure PowerShell can run scripts, and enabling scripts to run in

Windows PowerShell, Verifying that WinRM allows Windows PowerShell to connect, and configuring WinRM

to support basic authentication.Note that this local computer must have Internet connectivity.

Installing Azure PowerShell To install the Azure PowerShell module, proceed with the following steps:

1. Open a browsing session and navigate to the Azure Downloads44 page. 2. Scroll down to Command line tools.

3. Under Windows downloads, click Windows Azure PowerShell.

4. When prompted to run or save the .exe installation file (WindowsAzurePowerShell.3f.3.3fnew.exe), choose the Run button.

5. A User Account Control dialog brings up. Click Yes. This launches the Web Installer Platform 5.0 as of this writing.

44 Windows Azure Downloads: http://go.microsoft.com/fwlink/?LinkID=294711


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

6. Click Install and follow the online instructions to complete the installation.

7. Click I Accept. The package is downloaded and installed.


8. Click Finish.9. Click Exit.

You can run then the cmdlets from the Azure PowerShell console.To connect to your Azure subscription with the Azure PowerShell console, proceed with the following steps:

1. Open an Azure PowerShell command prompt.

2. Run the following command.

PS C:\> Add-AzureAccount

3. A Sign in to Azure dialog brings up.

4. Type the email address and click Continue. You’re redirected to a Sign In page5. Type the password associated with your account and click Sign in.6. Azure authenticates you, saves the credential information, and then closes the dialog.

A message states that your subscription is now selected has the default subscription.


PS C:\> VERBOSE: Account "your email address" has been added.PS C:\> VERBOSE: Subscription "xxx" is selected as the default subscription.PS C:\> VERBOSE: To view all the subscriptions, please use Get-AzureSubscription.PS C:\> VERBOSE: To switch to a different subscription, please use Select-AzureSubscription.help azurePS C:\>

7. Once connected to your default subscription, you can use the built-in Help system to list and get help about the cmdlets in the Azure PowerShell module. To list the available cmdlets, run the following command:

PS C:\> help azure

You can then display help about a specific cmdlet by typing help followed by the name of the cmdlet, for example “help New-AzureVM”.


Note For instructions, see the Microsoft TechNet articles HOW TO INSTALL AND CONFIGURE WINDOWS AZURE POWERSHELL 45 and GET STARTED WITH WINDOWS AZURE CMDLETS 46.

Note For more information about the cmdlets in the Azure PowerShell module, see the Microsoft MSDN article WINDOWS AZURE MANAGEMENT CMDLETS 47.

Enabling Windows PowerShell scriptsTo verify that Azure PowerShell can run scripts, proceed with the following steps;

1. Open an elevated Azure PowerShell command prompt, and run the following command:

PS C:\> Get-ExecutionPolicy

2. If the value returned is anything other than RemoteSigned, you need to change the value to RemoteSigned.

Note A digital signature is required from a trusted publisher on scripts and configuration files that are downloaded from the Internet (including email and instant messaging programs) so that they can run. However, a digital signature isn’t required on scripts that you have written on the local computer (not downloaded from the Internet). Finally, you can run scripts that are downloaded from the Internet and not signed, if the scripts are unblocked, such as by using the Unblock-File cmdlet. For more information, see the Microsoft TechNet article ABOUT_EXECUTION_POLICIES .48.

Run the following command if needed:

PS C:\> Set-ExecutionPolicy RemoteSigned

When asked, press “Y” to confirm the operation.

Enabling WinRM for remote PowerShell shellTo verify that WinRM allows Windows PowerShell to connect, proceeds as follows:

1. In the above elevated Azure PowerShell session, run the following command to check the status of the WinRM service:

PS C:\> sc query winrm

2. If the WinRM service isn’t running, start it with the following command:

PS C:\> net start winrm

3. Run the following command:

PS C:\> winrm get winrm/config/client/auth

45 HOW TO INSTALL AND CONFIGURE WINDOWS AZURE POWERSHELL: http://www.windowsazure.com/en-us/manage/install-and-configure-windows-powershell/46 GET STARTED WITH WINDOWS AZURE CMDLETS: http://msdn.microsoft.com/en-us/library/windowsazure/jj554332.aspx47 WINDOWS AZURE MANAGEMENT CMDLETS: http://msdn.microsoft.com/en-us/library/jj152841.aspx48 ABOUT_EXECUTION_POLICIES: http://technet.microsoft.com/library/hh847748.aspx


http://technet.microsoft.com/library/hh847748.aspx

http://msdn.microsoft.com/en-us/library/jj152841.aspx

http://msdn.microsoft.com/en-us/library/windowsazure/jj554332.aspx

http://www.windowsazure.com/en-us/manage/install-and-configure-windows-powershell/

http://www.windowsazure.com/en-us/manage/install-and-configure-windows-powershell/

4. In the results, look for the value “Basic =”. If the value is “Basic = false”, you must change the value to “Basic = true”.If the value has to be changed, run the following command:

PS C:\> winrm set winrm/config/client/auth @{Basic="true"}

The value between the braces { } is case-sensitive. In the command output, verify the value “Basic = true”.

5. If you started the WinRM service in step 2, run the following command to stop it:

PS C:\> net stop winrm

You are now ready to setup the Windows Server 2012 R2 Base Configuration needed for the test lab.This is the purpose of the next section.


Setting up the Windows Server 2012 R2 Base Configuration test labBy following the instructions outlined hereafter, you should be able to successfully prepare your test lab environment based on virtual machines (VMs) running in Azure to later deploy and configure the mobile Device Extension environment, install and configure it with AD RMS along with Active Directory Federation Services (AD FS) in Windows Server 2012 R2 that is a prerequisite, etc. and start evaluating/using it.

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 the Mobile Device Extension for AD RMS 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 test lab environment. We recommend following this guide as-is first to familiarize yourself with the steps involved, before attempting a deployment on an environment with a different configuration.

In order to complete the document’s walkthrough, you need an environment that consists of the following components for the Azure-based test lab infrastructure:

One Azure virtual machine running Windows Server 2012 R2 (named DC1) that is configured as a domain controller with a test user and group accounts, and Domain Name System (DNS) server.

One Azure virtual machine running Windows Server 2012 R2 (named ADFS1) that is configured as an enterprise root certification authority and as an AD FS federation server.

One Azure virtual machine running Windows Server 2012 R2 (named ADRMS1) that is configured as an AD RMS cluster.

Note For more information about the system requirements for installing AD RMS, see the Microsoft TechNet article PRE-INSTALLATION INFORMATION FOR ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES 49.

One Azure virtual machine running Windows Server 2012 R2 (named SQL1) that is configured as a SQL Server 2012 computer, which will be used to support the AD RMS configuration and logging databases.

Important note The Mobile Device Extension for AD RMS requires that the AD RMS deployment uses a full Microsoft SQL Server-based database on a separate server and not the Windows Internal Database that is often used for testing on the same server.

One Azure virtual machine running Windows Server 2012 R2 (named EDGE1) that is configured as a Web server.

49 PRE-INSTALLATION INFORMATION FOR ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES: http://go.microsoft.com/fwlink/?LinkId=84733)




Important note The configuration of the Azure virtual machines and the related Azure virtual network (see below) in this guide is designed to give you hands-on practice in creating an AD RMS test environment suitable for testing and evaluating the Mobile Device Extension for AD RMS. The design decisions made in this guide were geared toward increasing your hands-on experience and to some degree reflect AD RMS best practices configuration. For full best practices and design and planning information related to AD RMS, see the Microsoft TechNet articles AD RMS PREREQUISITES 50, AD RMS PERFORMANCE AND LOGGING BEST PRACTICES 51, and AD RMS ARCHITECTURE DESIGN AND SECURE COLLABORATION SCENARIOS 52.

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

These Azure VMs will enable you to: Connect to the Internet to install updates, and access Internet resources in real time. Remotely managed those using Remote Desktop connections by your computer that

is connected to the Internet or your organization network.

Note You must be logged on as a member of the Domain Admins group or a member of the Administrators group on each computer to complete the tasks described in this guide. If you cannot complete a task while you are logged on with an account that is a member of the Administrators group, try performing the task while you are logged on with an account that is a member of the Domain Admins group.

Create snapshots so that you can easily return to a desired configuration for further learning and experimentation.

For that purpose, these VMs notably expose one public endpoint for Remote Desktop Protocol (RDP) and another one for remote Windows PowerShell (WinRMHTTPS) as illustrated hereafter.

The EDGE1 VM exposes in addition a public endpoint for HTTPS (HttpsIn).

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, ADRMS1, ADFS1, and SQL1.

50 AD RMS PREREQUISITES: http://technet.microsoft.com/library/dd772659(v=WS.10).aspx51 AD RMS PERFORMANCE AND LOGGING BEST PRACTICES: http://technet.microsoft.com/library/dd941633(v=ws.10).aspx52 AD RMS ARCHITECTURE DESIGN AND SECURE COLLABORATION SCENARIOS: http://technet.microsoft.com/library/dd941633(v=ws.10).aspx53 WINDOWS SERVER 2012 R2: http://technet.microsoft.com/en-US/windowsserver/hh534429


http://technet.microsoft.com/en-US/windowsserver/hh534429

http://technet.microsoft.com/library/dd941633(v=ws.10).aspx



http://technet.microsoft.com/library/dd772659(v=WS.10).aspx

Important Note Azure assigns IP addresses dynamically, which may seem inconvenient when you have the habit to set static IP addresses, especially for domain controllers. More specifically, static IP addresses are NOT supported. For more information, see section IP Addressing and DNS54 of the MSDN article GUIDELINES FOR DEPLOYING WINDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE VIRTUAL MACHINES.

Within a subnet, the first 3 addresses are reserved and, in the case of Subnet2 above, the first address that is assigned by the Azure DHCP will be 10.0.2.4. However, it is guaranteed that the first address will remain constant, which is not the case for the addresses that belong to the rest of the range. Such a behavior must be taken into account if you want that a specific VM will have the same IP address allocated over the time, which will be the case of our domain controller DC1 that will also host the DNS server for the test lab environment.

For illustration purposes, we have opted to configure the domain litware369.com (LITWARE369). Since the lab depends on you using a unique name for your domain, you will have to choose a domain name of your own. For checking purposes, you can use the domain search capability provided by popular domain name registrars. Alternatively, you can use a subdomain of a domain you already control in lieu of Litware369.com. Whenever a reference to litware369.com is made in a procedure, 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.Furthermore, for the sake of simplicity, the same password “pass@word1” is used throughout the procedures of the above TLGs as well as the ones detailed in this document. 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 Azure VM, unless instructed otherwise.

Note When you configure Windows Server 2012 R2, you are required to click Continue or Yes in the User Account Control (UAC) dialog box for some tasks. Several of the configuration tasks require UAC approval. When you are prompted, always click Continue or Yes to authorize these changes. Alternatively, see the Appendix of this guide for instructions about how to set the UAC behavior of the elevation prompt for administrators.

The following five steps must be followed in order to set up the on-premises core infrastructure of our test lab:

1. Deploying the base workloads in Azure. 2. Configuring the domain controller.

54 GUIDELINES FOR DEPLOYING WINDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE VIRTUAL MACHINES: http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx


http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx#BKMK_IPAddressDNS

3. Configuring the root Enterprise CA.4. Deploying the database server.5. Deploying the federation server.6. Preparing the Internet-facing computer.7. Deploying the rights management server.

Deploying the base workloads in AzureTo deploy the base workloads in your Azure subscription, proceed with the following steps:

1. Download the script New-TestLabEnvironment.ps155 and unblock it so that it can comply with the above execution policy and executed in your environment.

Note The script New-TestLabEnvironment.ps1 is largely inspired by the sample script DEPLOY A DOMAIN CONTROLLER AND MEMBER USING WINDOWS AZURE VIRTUAL MACHINES 56 available on the Microsoft TechNet Script Center57.

Note The script Remove-TestLabEnvironment.ps158 enables you to later seamlessly remove the test lab environment from your Azure subscription. Its usage is not covered in this paper since its arguments are almost the same as the ones used by the above script.

2. Open an Azure PowerShell command prompt and navigate to the folder where the above script is located, for example C:\Scripts in our illustration.

3. Run the following command to connect to your subscription:

PS C:\Scripts> Add-AzureAccount

55 New-TestLabEnvironment.ps1: http://www.microsoft.com/en-us/download/details.aspx?id=3639156 DEPLOY A DOMAIN CONTROLLER AND MEMBER USING WINDOWS AZURE VIRTUAL MACHINES: http://gallery.technet.microsoft.com/scriptcenter/Deploy-a-domain-controller-2ab7d65857 Script resources for IT professionals: http://gallery.technet.microsoft.com/scriptcenter58 Remove-TestLabEnvironment.ps1: http://www.microsoft.com/en-us/download/details.aspx?id=36391


http://gallery.technet.microsoft.com/scriptcenter

http://gallery.technet.microsoft.com/scriptcenter

http://gallery.technet.microsoft.com/scriptcenter/Deploy-a-domain-controller-2ab7d658

http://gallery.technet.microsoft.com/scriptcenter/Deploy-a-domain-controller-2ab7d658

A Sign in to Windows Azure dialog brings up.

4. Enter your email address and click Continue. You’re redirected to a Sign In page.5. Type the password associated with your account for your Azure (trial) subscription

and click Sign in. You should now be connected to your default subscription.6. Run the following command to deploy the base workloads in your subscription:

PS C:\Scripts> .\New-TestLabEnvironment.ps1 -ServiceName "mfalab" -Location "North Europe"

7. The script New-TestLabEnvironment.ps1 proceeds with the setup and will prompt you to gather the administrator credentials to use when provisioning the aforementioned VMs. A Windows PowerShell credential required dialog brings up.

8. Provide the administrator credentials you want to use. We will use throughout this walkthrough “AzureAdmin” for the username and “pass@word1” for the password.


The script New-TestLabEnvironment.ps1 continues with the setup. It executes the following tasks for you:

DC1IP: 10.0.2.4

EDGE1IP: 10.0.1.4

ADFS1IP: 10.0.2.5

AD DSDNS

IISAD CS

IIS

Subnet1 (10.0.1.0/24): mfalabvnet-subnet1

VNET: mfalabvnet

Cloud Service: mfalabsvc

Subnet2 (10.0.2.0/24): mfalabvnet-subnet2

HttpsIn SQL1IP: 10.0.2.6

ADRMS1IP: 10.0.2.7

IISAD RMS

Create an affinity group to associate all the workloads to be deployed with. The name of the affinity group is based on the provided service name in the command line, for example “mfalab” in our configuration, with the added suffix "aff”, resulting for example in “mfalabaff” in our configuration.

Create a cloud service for these workloads. Like with the affinity group name, the name of the cloud service is based on the provided service name in the command line with the added suffix "svc”, for example “mfalabsvc” in our configuration.

Create an account storage to store the VHDs of the workloads as blobs. The name of the account storage is based on the provided service name in the command line with the added suffix "stor”, for example “mfalabstor” in our configuration.

Create a VNET for the workloads. The name of the VNET is based on the provided service name in the command line with the added suffix "vnet”, for example “mfalabvnet” in our configuration. The address space is 10.0.0.0/8.By default, the name of the above Subnet1 is “-subnet1” prefixed by the name of the VNET, for example “mfalabvnet-subnet1” in our configuration. The address space is 10.0.1.0/24 by default.Likewise, the name of the above Subnet2 is “-subnet2” prefixed by the name of the VNET, for example “mfalabvnet-subnet2” in our configuration. The address space is 10.0.2.0/24 by default.

Create a DC1 virtual machine of small size based on the latest available Windows Server 2012 R2 image, add a second disk for the AD DS role service, install the AD DS role service, and finally install Active Directory Domain Services (AD DS) to make the DC1 computer a domain controller in Windows Server 2012 R2. This action upgrades the AD DS schema as part of the domain controller creation.

Create a SQL1 virtual machine of medium size based on the latest available Windows Server 2012 R2 image. SQL Server 2012 will be installed later on this machine. This


machine will host an SQL Server instance that will be used for the AD RMS deployment on the ADRMS1 machine (see below).

Create a domain-joined ADFS1 virtual machine of small size based on the latest available Windows Server 2012 R2 image, and install the Active Directory Certificates Services (AD CS) role service and install an Enterprise Certification Authority (CA) along with Internet Information Services (IIS). The Active Directory Federation Services (AD FS) role service will be installed later on this machine and referred as to adfs.litware369.com.

Create a domain-joined ADRMS1 virtual machine of small size based on the latest available Windows Server 2012 R2 image, and install Internet Information Services (IIS). The Active Directory Rights Management Services (AD RMS) role service will be installed later on this machine and referred as to adrms.litware369.com.

Create an Internet-facing domain-joined EDGE1 virtual machine of small size based on the latest available Windows Server 2012 R2 image, and install Internet Information Services (IIS). The default web site on this machine will be later referred as to www.litware369.com. As already mentioned, a public endpoint for HTTPS (HttpsIn) is defined for that purpose as part of the script configuration.

The script leverages the remote Windows PowerShell capabilities along with the Windows Server automation with Windows PowerShell to setup the above virtual machines.

Note To learn about the Windows PowerShell command line and scripting environment, see the TechNet Script Center59.

Note For information about installing, learning, using, and customizing Windows PowerShell, see the Microsoft TechNet article Scripting with Windows PowerShell60.

Note For information about what scripts are and how to run them in Windows PowerShell, see the Microsoft TechNet article RUNNING SCRIPTS 61. This article includes basic information about creating scripts and configuring your computer to run scripts.

Note For information on Windows Server Automation with Windows PowerShell, see the eponym Microsoft TechNet article62. This article provides references to install and configure the various role services.

If needed to accommodate your own configuration, the script New-TestLabEnvironment.ps1 enables you to customize the VNET and VM details: PS C:\Scripts> .\New-TestLabEnvironment.ps1 -ServiceName "mfalab" -Location "North Europe" ` -DC1Name "dc1" -DCVMSize "Small" -FQDNDomainName "litware369.com" -NetBIOSDomainName "LITWARE369" ` -ADFS1Name "adfs1" –ADFS1VMSize "Small" ` -ADRMS1Name "adrms1" –ADRMS1VMSize "Small" ` -SQL1Name "sql1" –SQL1VMSize "Small" ` -EDGE1Name "edge1" EDGE1VMSize "ExtraSmall" ` -VNetAddressPrefix "10.0.0.0/8" -Subnet1AddressPrefix "10.0.1.0/24" -Subnet2AddressPrefix "10.0.2.0/24"

At the end of the script, you should have an up and running base configuration that we will leverage in the next steps. The next sections imply that you have in place such an environment.

59 TechNet Script Center: http://go.microsoft.com/fwlink/p/?linkid=320211&clcid=0x40960 SCRIPTING WITH WINDOWS POWERSHELL: http://go.microsoft.com/fwlink/p/?linkid=320210&clcid=0x40961 RUNNING SCRIPTS: http://go.microsoft.com/fwlink/p/?linkid=320627&clcid=0x40962 WINDOWS AND WINDOWS SERVER AUTOMATION WITH WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/dn249523.aspx


http://go.microsoft.com/fwlink/p/?linkid=320627&clcid=0x409



Furthermore, to externally resolve the adrms.litware369.com, adfs.litware369.com, and www.litware369.com FQDN names and point to the above cloud service in Azure, you will need to create the following CNAME records in your DNS zone (e.g. litware369.com in our configuration) of your domain registrar. The exact method depends on the chosen domain registrar.You will need to externally resolve these FQDN names for the Web Application Proxy (WAP).

Name Type Value TTL

adrms CNAME mfalabsvc.cloudapp.net 3 hoursadfs CNAME mfalabsvc.cloudapp.net 3 hourswww CNAME mfalabsvc.cloudapp.net 3 hours

Configuring the domain controllerTo configure the domain controller, proceed with the following steps:

1. Opening a remote desktop connection on the domain controller.2. Configuring public DNS forwarders.3. Creating DNS records.4. Creating a group Managed Service Account (gSMA).5. and groups.6. Allowing users accounts to log on locally.

The following subsections describe in the context of our test lab environment each of these steps.

Opening a remote desktop connection on the domain controllerTo open a remote desktop connection on the DC1 computer, 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 administrative credentials to your Azure subscription. 3. On the left pane of the Azure management portal, click VIRTUAL MACHINES.


https://manage.windowsazure.com/

4. On the virtual machine page, at the top, ensure VIRTUAL MACHINE INSTANCES is selected.

5. Select the dc1 machine and click CONNECT at the tray of the bottom.

6. Click Open. A Remote Desktop Connection dialog brings up.

7. Check Don’t ask me again for connections to this computer and click Connect.8. A Windows Security dialog brings up.9. Log on as LITWARE369\AzureAdmin with “pass@word1” as password.

10. Another Remote Desktop Connection dialog brings up.

11. Check Don’t ask me again for connections to this computer and click Yes.The connection is then established to the remote desktop.

Configuring public DNS forwardersThe Windows PowerShell script used to setup our test lab environment configures the DNS server on the DC1 computer for name resolution instead of the Azure-provided name resolution.We must ensure that our DNS server is configured to use the root hints if no forwarders are available so that we can correctly resolve name over the Internet in our test lab environment.


Note For more information on the root hints, see the eponym page ROOT SERVERS 63.

To configure the DNS server to use the root hints, proceed with the following steps:1. Open a Windows PowerShell command prompt, and run the following command to

start the DNS Manager console:

PS C:\Users\AzureAdmin> dnsmgmt.mscPS C:\Users\AzureAdmin>

The DNS Manager console brings up.

2. In the console tree, select DC1.3. On the Action menu, click Properties. The DC1 Properties dialog brings up.4. Select the Forwarders tab.

5. Ensure that Use rot hints if no forwarders are available is checked.6. Click OK and close the DNS Manager console.

63 ROOT SERVERS: http://www.iana.org/domains/root/servers


http://www.iana.org/domains/root/servers

7. From the above Windows PowerShell command prompt, type the following command to validate the resolution with the root hints:

PS C:\Users\AzureAdmin> dnscmd /ipvalidate /roothints 192.5.5.241

. completed successfully.Raw Flags ResultCode NoTcp RTT IP Address---------------------------------------------------------------------------00001000 0 Success 0 10 192.5.5.241Command completed successfully.

PS C:\Users\AzureAdmin>

You should see Success as the result code.

Creating DNS recordsTo create a DNS record for adfs, adrms, and www, proceed with the following steps:

1. Open a remote desktop session as per previous section.


2. Open an elevated Windows PowerShell command prompt and run the following command to add an A record for adfs:

PS C:\users\AzureAdmin> Add-DnsServerResourceRecord -ZoneName "litware369.com" -A -Name "adfs" -IPv4Address "10.0.2.5"PS C:\users\AzureAdmin>

Important note If the DNS resolution of the AD FS service endpoint is performed through CNAME record lookup instead of through an A record lookup, you will be repeatedly prompted for credentials later in this lab during sing-in.

Note For more information on the DNS cmdlets, see the Microsoft TechNet article DOMAIN NAME SYSTEM (DNS) SERVER CMDLETS IN WINDOWS POWERSHELL 64.

3. Run the following command to add a CNAME record for adrms:

PS C:\users\AzureAdmin> Add-DnsServerResourceRecord -CName -Name "adrms" -HostNameAlias "adrms1.litware369.com" -ZoneName "litware369.com"

PS C:\users\AzureAdmin>

4. Run the following command to add a CNAME record for www:

PS C:\users\AzureAdmin> Add-DnsServerResourceRecord -CName -Name "www" -HostNameAlias "edge1.litware369.com" -ZoneName "litware369.com"


Creating a group Managed Service Account (gSMA) A group Managed Service Account (gMSA) account will be required during the AD FS installation and configuration. The benefit of using a gMSA is its auto-negotiated password update feature.

Note For more information, see the blog post NEW FEATURES IN ACTIVE DIRECTORY DOMAIN SERVICES IN WINDOWS SERVER 2012, PART 8: GROUP MSAS (GMSAS) 65.

64 DOMAIN NAME SYSTEM (DNS) SERVER CMDLETS IN WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/jj649850.aspx65 NEW FEATURES IN ACTIVE DIRECTORY DOMAIN SERVICES IN WINDOWS SERVER 2012, PART 8: GROUP MSAS (GMSAS): http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2012/09/04/new-features-in-active-directory-domain-services-in-windows-server-2012-part-8-group-msas-gmsas.aspx


http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2012/09/04/new-features-in-active-directory-domain-services-in-windows-server-2012-part-8-group-msas-gmsas.aspx

http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2012/09/04/new-features-in-active-directory-domain-services-in-windows-server-2012-part-8-group-msas-gmsas.aspx

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

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

To create the gMSA account, proceed with the following steps:1. From the above elevated Windows PowerShell command prompt, run the following

command to verify whether the KDS Root Key has been created in your domain to enable gMSA in your domain:

PS C:\users\AzureAdmin> Get-KdsRootKey


2. If it has not been created (the output displays no information), run the following command to create the key:

PS C:\users\AzureAdmin> Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)

Guid----7d5decb2-6c35-2b0c-6286-8055e413f2a5


Note For more information, see the Microsoft TechNet article KEY DISTRIBUTION SERVICE (KDS) IN WINDOWS POWERSHELL 66.

3. Run the following command:

PS C:\users\AzureAdmin> New-ADServiceAccount FsGmsa -DNSHostName adfs.litware369.com -ServicePrincipalNames http/adfs.litware369.com


66 KEY DISTRIBUTION SERVICE (KDS) IN WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/jj852115.aspx


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


Creating additional user accounts and groupsWe will now create the following additional user accounts and groups in our domain litware369.com. The following table lists the user accounts that we need to create at this time:

Account Name

User Logon Name

Email Address Group

ADRMSSVC ADRMSSVCRobert Hatley RobertH [email protected]

omEmployees, Finance

Janet Schorr JanetS [email protected]

Employees, Marketing

Stuart Railson StuartR [email protected]

Employees, Engineering

These user accounts and groups are used to complete the walkthroughs later in this document.To create the above user accounts, open an elevated Windows PowerShell command prompt, and run the following command. All the user accounts will use the password: “pass@word1”: PS C:\users\AzureAdmin> Import-Module -Name ActiveDirectory

PS C:\users\AzureAdmin> New-ADUser -Name ADRMSSVC -GivenName ADRMSSVC -UserPrincipalName “[email protected]" -AccountPassword (ConvertTo-SecureString -AsPlainText "pass@word1" -Force) -ChangePasswordAtLogon $false -PasswordNeverExpires $true -Enabled $true

PS C:\users\AzureAdmin> New-ADUser –Name "Robert Hatley" -SamAccountName "roberth" -DisplayName "Robert Hatley" -AccountPassword (ConvertTo-SecureString “pass@word1” -AsPlainText –Force) -ChangePasswordAtLogon $false -PasswordNeverExpires $true -Enabled $true -UserPrincipalName “[email protected]" -EmailAddress “[email protected]" -GivenName "Hatley" -Surname "Robert"

PS C:\users\AzureAdmin> New-ADUser –Name "Janet Schorr" -SamAccountName "janets" -DisplayName "Janet Schorr" -AccountPassword (ConvertTo-SecureString “pass@word1” -AsPlainText –Force) -ChangePasswordAtLogon $false -PasswordNeverExpires $true -Enabled $true -UserPrincipalName “[email protected]" -EmailAddress “[email protected]" -GivenName "Schorr" -Surname "Janet"

PS C:\users\AzureAdmin> New-ADUser –Name "Stuart Schorr" -SamAccountName "stuartr" -DisplayName "Stuart Railson" -AccountPassword (ConvertTo-SecureString “pass@word1” -AsPlainText –Force) -ChangePasswordAtLogon $false -PasswordNeverExpires $true -Enabled $true -UserPrincipalName “[email protected]" -EmailAddress “[email protected]" -GivenName "Railson" -Surname "Stuart"


We now need to create some additional AD groups to assign users. The following table lists the groups that we need to create at this time.

Group Name Email Address

Finance [email protected] [email protected] [email protected] [email protected]


To create the above user groups, proceed with the following steps:1. From the previous elevated Windows PowerShell command prompt, run the following

command to create the various groups.

PS C:\users\AzureAdmin> New-ADGroup -Name Finance -SamAccountName Finance -GroupCategory Security -GroupScope Universal

PS C:\users\AzureAdmin> New-ADGroup -Name Marketing -SamAccountName Marketing -GroupCategory Security -GroupScope Universal

PS C:\users\AzureAdmin> New-ADGroup -Name Engineering -SamAccountName Engineering -GroupCategory Security -GroupScope Universal

PS C:\users\AzureAdmin> New-ADGroup -Name Employees -SamAccountName Employees -GroupCategory Security -GroupScope Universal


2. Run the following command to add email addresses to group objects:

PS C:\users\AzureAdmin> Set-ADGroup Finance -Add @{mail='[email protected]'}

PS C:\users\AzureAdmin> Set-ADGroup Marketing -Add @{mail='[email protected]'}

PS C:\users\AzureAdmin> Set-ADGroup Engineering -Add @{mail='[email protected]'}

PS C:\users\AzureAdmin> Set-ADGroup Employees -Add @{mail='[email protected]'}


3. Run the following command to add the user accounts to their appropriate groups:

PS C:\users\AzureAdmin> Add-ADGroupMember -Identity Employees -Members roberth,janets,stuartr

PS C:\users\AzureAdmin> Add-ADGroupMember -Identity Finance -Members roberth

PS C:\users\AzureAdmin> Add-ADGroupMember -Identity Marketing -Members janets

PS C:\users\AzureAdmin> Add-ADGroupMember -Identity Engineering -Members stuartr


Allowing users accounts to log on locallyBy default, a domain user is not allowed to log on locally on a member server like the EDGE1 computer. A configuration of group policy can be modified so that a domain user account can log on locally on a member sever. Though this is NOT at all recommended in production environment but for testing purpose or in lab setup like this one this configuration can be quite handy. This configuration helps where there are only few computers. To modify group policy settings to allow a domain user to log on locally a member server, proceed with following steps:

1. Open an elevated command prompt if none, and run the following command:

PS C:\users\AzureAdmin> gpmc.msc



A Group Policy Management windows brings up.

2. Double-click the name of the forest, double-click Domains, and double-click the name of the domain.

3. Right-click Default Domain Policy, and then click Edit. A Group Policy Management Editor window pops up.


4. In the console tree, expand Computer Configuration, Policies, Windows Settings, Security Settings, and Local Policies, and then click User Rights Assignment.

5. In the details pane, double-click Allow Logon Locally.

6. Check Define these policy settings, and then click Add User or Group. An Add User or Group dialog brings up.

7. Click Browse to locate the account with the Select Users, Computers, or Groups dialog.


8. Under Enter the object names to select, type “janets; roberth; administrators”, click Check Names, and then click OK.

9. Click OK in the Add User or Group dialog, and then click OK in the Allow log on locally Properties dialog box.

10. Close the Group Policy Management Editor window.11. Close the Group Policy Management window.

Configuring the root Enterprise CATo configure the root Enterprise CA, proceed with the following steps:

1. Opening a remote desktop connection on the target computer.2. Configuring an appropriate certificate template for SSL certificate (optional).

Opening a remote desktop connection on the target computerTo open a remote desktop connection on the ADFS1 computer, proceed as illustrated before with the DC1 computer but with the ADFS1 computer instead. As previously illustrated, log on as LITWARE369\AzureAdmin with “pass@word1” as password since ADFS1 is a domain-joined computer.


Configuring an appropriate certificate template for SSL certificate (optional)Services on both the ADFS1, ADRMS1, and EDGE1 computers will require secure sockets layer (SSL) / transport layer security (TLS) protection and corresponding certificates.The Web Server certificate template is the one usually used to request such a SSL certificate for a domain-joined computer. Its settings are perfectly appropriated when the certificate must be installed on the server that requests it. However, for a test lab environment, it could be convenient to be able to export both the certificate and private key. In such situation, these default settings are not suitable because they do not allow to export the private key.Consequently, we will configure a new certificate template that will duplicate this template, and thus present the same characteristics as the original template but with the possibility to export the private key.To configure a certificate template for SSL certificate, proceed with the following steps:

1. Open a remote desktop session as per previous section.2. From the Server Manager, click Tools and then Certification Authority. The

Certification Authority console brings up.


3. Expand the certification authority litware369-ADFS1-CA so that you can see Certificate Templates. The name of the certification authority may differ if you have chosen another NetBIOS domain name and another name for the ADFS1 computer.

4. Right-click Certificate Templates and then click Manage. The Certificate Templates Console brings up.

5. In the details pane of the Certificate Templates console, right-click the Web Server template and then click Duplicate Template. A Properties of New Template dialog brings up.

6. Select the Request Handling tab.


7. Leave unchecked Allow private key to be exported.8. Select the Security tab.

9. We must ensure the domain computer accounts will have the ability to enroll for the template. To do so, click Add. A Select Users, Computers, Services Accounts, or Groups dialog brings up.

a. In Select Users, Computers, Service Accounts, or Groups, type “Domain computers”. Click Check Names, and then click OK.


b. Ensure that the group is selected and then select the Allow checkbox that corresponds to the Enroll permission.

10. Select the General tab.

11. Under Template display name, type a name that you want to use for the template, for example, “SSL Certificates” in our configuration.

12. Click OK. 13. Close the Certificate Templates console and return to the Certificate Authority

console. 14. In the console tree of the Certification Authority console, right-click Certificate

Templates, click New, and then click Certificate Template to Issue. An Enable Certificate Templates dialog brings up.

15. In the Enable Certificate Templates dialog, select the new certificate template that you just configured (SSL Certificates) and then click OK.


Deploying the federation serverThis section walks you through the deployment of the federation server on the ADFS1 computer with the following steps:

1. Issuing a SSL/TLS certificate.2. Installing and configuring the AD FS role service.

Note For more information, see the Microsoft TechNet article WINDOWS SERVER 2012 R2 AD FS DEPLOYMENT GUIDE 67.

Important note You must have domain administrator permissions to deploy the AD FS role.

Issuing a SSL/TLS certificateThe AD FS role service will require a Secure Socket Layer (SSL) server certificate. The certificate should have the following attributes:

Subject Name (CN): adfs.litware369.com Subject Alternative Name (DNS): adfs.litware369.com

Note For more information about setting up SSL/TLS certificates, see the Microsoft TechNet Wiki article CONFIGURE SSL/TLS ON A WEB SITE IN THE DOMAIN WITH AN ENTERPRISE CA 68.

To issue the SSL certificate, proceed with the following steps:1. Open a remote desktop session if needed as LITWARE369\AzureAdmin.2. Open an elevated Windows PowerShell command prompt, and run the following

command:

PS C:\users\AzureAdmin.LITWARE369> Get-Certificate -Template SSLCertificates -SubjectName CN=adfs.litware369.com –DnsName adfs.litware369.com -CertStoreLocation cert:\LocalMachine\My

Status Certificate Request ------ ----------- ------- Issued [Subject]…

PS C:\users\AzureAdmin.LITWARE369>

67 WINDOWS SERVER 2012 R2 AD FS DEPLOYMENT GUIDE: http://technet.microsoft.com/en-us/library/dn486820.aspx68 CONFIGURE SSL/TLS ON A WEB SITE IN THE DOMAIN WITH AN ENTERPRISE CA: http://social.technet.microsoft.com/wiki/contents/articles/12485.configure-ssltls-on-a-web-site-in-the-domain-with-an-enterprise-ca.aspx


http://social.technet.microsoft.com/wiki/contents/articles/12485.configure-ssltls-on-a-web-site-in-the-domain-with-an-enterprise-ca.aspx



Note If you have not configured a new certificate template (e.g. the SSLCertificates in our configuration), you can use the WebServer certificate template in lieu of in the above command.

Note For more information, see the Microsoft TechNet article AD CS ADMINISTRATION CMDLETS IN WINDOWS POWERSHELL 69.

3. The SSL certificate should now be imported into the Local Computer\My Store on the ADFS1 computer. Verify whether the SSL certificate has been imported by running the following command:

PS C:\users\AzureAdmin.LITWARE369> dir Cert:\LocalMachine\My

Thumbprint Subject---------- -------F1DF749C3D84DFF8BE9DED211145C53F2F06D83D CN=mfalabsvc.cloudapp.netDD6F97EAF0CE4FDB039036199136752F62C8E027 CN=litware369-ADFS1-CA, DC=litware369, DC=com59D4CFDD539CB616B5608A555E115824BAF14E77 CN=WMSvc-ADFS1

044F380EE49583536012D77D940ACEBBCAC05B86 CN=adfs.litware369.com


The certificates are listed by their thumbprint in the Local Computer\My Store. We will be later interested in the thumbprint of the newly issued certificate, i.e. the one whose CN equals adfs.litware369.com, for example in our configuration: 044F380EE49583536012D77D940ACEBBCAC05B86.

Installing and configuring the AD FS role serviceTo install and configure the AD FS role service, proceed with the following steps:

1. Open an elevated Windows PowerShell command prompt if none, and run the following command:

PS C:\users\AzureAdmin.litware369> Install-windowsfeature adfs-federation –IncludeManagementTools

Success Restart Needed Exit Code Feature Result------- -------------- --------- --------------True No Success {Active Directory Federation Services}WARNING: To finish configuring this server for the federation server role using Windows PowerShell, seehttp://go.microsoft.com/fwlink/?LinkId=224868.

PS C:\Users\AzureAdmin.LITWARE369>

69 AD CS ADMINISTRATION CMDLETS IN WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/hh848365.aspx




2. Run the following commands to create a Windows Internal Database (WID) along with the required gMSA account:

PS C:\users\AzureAdmin.litware369> Import-Module ADFS

PS C:\users\AzureAdmin.litware369> $certificateThumbprint = (Get-ChildItem cert:\LocalMachine\MY -DnsName "*adfs*" | Select-Object -First 1).Thumbprint

PS C:\users\AzureAdmin.litware369> Install-AdfsFarm –CertificateThumbprint $certificateThumbprint -FederationServiceDisplayName "Litware369" -FederationServiceName "adfs.litware369.com" –GroupServiceAccountIdentifier "LITWARE369\FsGmsa$"

Message Context Status------- ------- ------The configuration completed successf... DeploymentSucceeded Success


Important note The ‘$’ at the end of the gMSA account is required.

Note If this is NOT the first time you run this command, add –OverwriteConfiguration.

Preparing the Internet-facing computerTo prepare the Internet facing computer, proceed with the following steps in order:

1. Opening a remote desktop connection on the target computer.2. Allowing the domain users to open a remote session.


3. Testing the federation server configuration.4. Issuing a SSL/TLS certificate.5. Configuring HTTPS on the default web site.6. Deploying the Web Application Proxy (WAP).

The following subsections describe each of these steps in the context of our test lab environment.

Opening a remote desktop connection on the target computerTo open a remote desktop connection on the EDGE1 computer, proceed as illustrated before with the DC1 computer but with the EDGE1 computer instead. As previously illustrated, log on as LITWARE369\AzureAdmin with “pass@word1” as password since EDGE1 is a domain-joined computer.

Allowing the domain users to open a remote sessionWe have previously modified group policy settings so that our test user accounts can log on locally on member servers. We now need to apply the modified group policies.To update the group policies, proceed with the following steps:

1. Open a remote desktop session as per previous section.2. Open an elevated Windows PowerShell command prompt.3. Run the following command:

PS C:\users\AzureAdmin.LITWARE369> gpupdate /forceUpdating policy...

Computer Policy update has completed successfully.User Policy update has completed successfully.


In addition, we need to add our test user accounts to the local group Remote Desktop Users so that they can open a remote desktop session on the virtual machine in Azure.


To add the test user accounts to the local group Remote Desktop Users, proceed with the following steps:

1. Open an elevated Windows PowerShell command prompt, and run the following command to add Janet Schorr to the local group:

PS C:\users\AzureAdmin.LITWARE369> net localgroup "Remote Desktop Users" /add "LITWARE369\janets"The command completed successfully.


2. Run the following command to add Robert Hatley to the local group:

PS C:\users\AzureAdmin.LITWARE369> net localgroup "Remote Desktop Users" /add "LITWARE369\Roberth"The command completed successfully.


Testing the federation server configurationBefore testing the configuration, you need to configure your browser settings to trust the federation server role by adding your federation service name (for example in our configuration, https://adfs.liteware369.com) to the browser’s local intranet zone.To configure the browser settings accordingly on the EDGE1 computer, proceed with the following steps:

1. Close the current remote desktop connection and open a new one on the EDGE1 computer as LITWARE369\JanetS with “pass@word1” as password.

2. Start Internet Explorer and select Internet Options on the Tools menu. An Internet Options dialog pops up.

3. Click the Security tab, select the Local intranet zone, and then click Sites. A Local intranet dialog appears.

4. Click Advanced. A Trusted sites dialog appears.


5. In Add this website to the zone, type “https://adfs.litware369.com”, and then click Add. You should replace litware369.com by your own domain as already mentioned.

6. Click Close, and then click OK.

7. Verify that the security level for the zone is set to the default setting of Medium-low which enables Windows integrated authentication for Intranet zones.

8. Click OK to close the Internet Options dialog.To verify that a federation server on ADFS1 is operational, proceed with the following steps:

1. Open a browsing session on ADFS1 and navigate to the federation service metadata endpoint, for example, in our configuration:

https://adfs.litware369.com/federationmetadata/2007-06/federationmetadata.xml If in your browser window you can see the federation server metadata without any SSL errors or warnings, your federation server is operational.


2. You can alternatively navigate to the metadata exchange endpoint, which offers an XML service description:

https://adfs.litware369.com/adfs/services/trust/mex

3. You can alternatively navigate to the AD FS sign-in page, for example in our configuration:

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


This displays the AD FS sign-in page where you can sign in with the domain credentials.

Click Sign in to verify that 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.


Issuing a SSL/TLS certificateThe default web site will require a SSL server certificate. The certificate MUST have the following attributes:

Subject Name (CN): www.litware369.com Subject Alternative Name (DNS): adfs.litware369.com Subject Alternative Name (DNS): adrms.litware369.com Subject Alternative Name (DNS): www.litware369.com

For demonstration purpose, you can issue such a SSL certificate with the test lab certification authority litware369-ADFS1-CA as illustrated hereafter. You can instead use a SSL certificate issued from a public certification authority is required. The exact method depends on the chosen public certification authority. Please refer to their instructions.With the exception of the SSL certificate import into the Local Computer\My Store on the EDGE1 computer, the rest of the suggested configuration doesn’t differ from the one illustrated in this document.To issue the SSL certificate with the test lab certification authority, proceed with the following steps:

1. Close the current remote desktop connection and open a new one on the EDGE1 computer as LITWARE369\AzureAdmin with “pass@word1” as password.

2. Open an elevated Windows PowerShell command prompt, and run the following command:

PS C:\users\AzureAdmin.LITWARE369> Get-Certificate -Template SSLCertificates -SubjectName CN=www.litware369.com –DnsName adfs.litware369.com, adrms.litware369.com, www.litware369.com -CertStoreLocation cert:\LocalMachine\My



Note If you haven’t previously configured a new certificate template (e.g. the SSL certificates in our configuration), you can use the WebServer certificate template in lieu of in the above command.

Configuring HTTPS on the default web siteTo configure HTTPS on the default web site, proceed with the following steps:

1. Open an elevated Windows PowerShell command prompt if none, and run the following command to add a SSL binding to the default web Site:

PS C:\users\AzureAdmin.LITWARE369> New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https



2. Run the following commands to associate the imported SSL certificate to the newly created SSL binding:

PS C:\users\AzureAdmin.LITWARE369> Get-ChildItem cert:\LocalMachine\MY | where { $_.Subject -match "CN\=www.litware369.com" } | select -First 1 | New-Item IIS:\SslBindings\0.0.0.0!443

IP Address Port Host Name Store Sites---------- ---- --------- ----- -----0.0.0.0 443 MY Default Web Site


3. Open a browsing session and navigate to the default web site at https://www.litware369.com:


https://www.litware369.com/

Deploying the Web Application Proxy (WAP)The Web Application Proxy (WAP) is the new proxy for AD FS in Windows Server 2012 R2.

Note For more information, see the Microsoft TechNet article WEB APPLICATION PROXY OVERVIEW 70 as well as the section DEPLOYING FEDERATION SERVER PROXIES 71 of the WINDOWS SERVER 2012 R2 AD FS DEPLOYMENT GUIDE also available on Microsoft TechNet.

To install and configure the Web Application Proxy role service, proceed with the following steps:

1. Open an elevated Windows PowerShell command prompt if none, and run the following command:

PS C:\Users\AzureAdmin.LITWARE369> Install-WindowsFeature Web-Application-Proxy –IncludeManagementTools

Success Restart Needed Exit Code Feature Result------- -------------- --------- --------------True No Success {RAS Connection Manager Administration Kit...WARNING: To finish configuring this server for the Web Application Proxy role service using Windows PowerShell, seehttp://go.microsoft.com/fwlink/?LinkId=294322.


2. Run the following command to collect the credential of the LITWARE369\AzureAdmin user:

PS C:\Users\AzureAdmin.LITWARE369> $credentials = Get-Credential

cmdlet Get-Credential at command pipeline position 1Supply values for the following parameters:CredentialPS C:\Users\AzureAdmin.LITWARE369>

70 WEB APPLICATION PROXY OVERVIEW: http://technet.microsoft.com/en-us/library/dn280944.aspx71 DEPLOYING A FEDERATION SERVER FARM: http://technet.microsoft.com/en-us/library/dn486775.aspx





When prompted, enter the following credential in the dialog below and click OK:Username: LITWARE369\AzureAdminPassword: pass@word1

3. Run the following commands to install and configure the Web Application Proxy (WAP):

PS C:\users\AzureAdmin.litware369> $certificateThumbprint = (Get-ChildItem cert:\LocalMachine\MY -DnsName "*adfs*" | Select-Object -First 1).Thumbprint

PS C:\users\AzureAdmin.litware369> Install-WebApplicationProxy -FederationServiceTrustCredential $credentials -CertificateThumbprint $certificateThumbprint -FederationServiceName "adfs.litware369.com"

Message Context Status------- ------- ------The configuration completed successf... DeploymentSucceeded Success


Note For more information, see the Microsoft TechNet article WEB APPLICATION PROXY CMDLETS IN WINDOWS POWERSHELL 72.

To verify that you can successfully authenticate against the federation server on the Internet, proceed with the following steps:

1. Open a browsing session on your local computer and navigate to the AD FS sign-in page, for example in our configuration:

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

Note If the SSL certificate used in the configuration has not been issued by a public certification authority, you will need to add the test lab certification authority Litware369-ADFS1-CA root certificate to the trusted root certification authorities of your user’s store.

As before, this displays the AD FS sign-in page where you can sign in with the domain credentials.

72 WEB APPLICATION PROXY CMDLETS IN WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/dn283404.aspx




2. Click Sign in to verify that you can successfully be authenticated.


3. Enter the following credential and the click Sign in:Username: LITWARE369\JanetSPassword: pass@word1

Deploying the database serverThe SQL1 computer provides a SQL Server installation on a member server within litware369.com domain that will later host the AD RMS configuration and logging databases.This section walks you through the deployment of SQL Server 2012 on the SQL1 computer with the following steps:

1. Opening a remote desktop connection on the target computer.2. Adding the LITWARE369\AzureAdmin user as a SQL login and assign it sysadmin

rights.3. Starting the SQL Server Browser service.4. Adding Windows Firewall exceptions for SQL Server ports.

The following subsections describe each of these steps in the context of our test lab environment.


Opening a remote desktop connection on the target computerTo open a remote desktop connection on the SQL1 computer, proceed as illustrated before with the DC1 computer but with the SQL1 computer instead. However, log on this time as SQL1\AzureAdmin with “pass@word1” as password. The local account SQL1\AzureAdmin sysadmin rights on the SQL Server instance.

Next, we will continue working on SQL1 using SQL Server Management Studio and other administrative tools to make some configuration changes to support SQL Server access before we install AD RMS later in this document. First, the LITWARE369\AzureAdmin account needs to be given sysadmin rights on the SQL Server instance in order to be able to create the AD RMS databases during AD RMS setup.

Adding the LITWARE369\AzureAdmin user as a SQL login and assign it sysadmin rightsTo add the LITWARE369\AzureAdmin user as a SQL login and assign it sysadmin rights, proceed with the following steps:

1. Open a remote desktop session as per previous section.2. Right-click the taskbar and select Task Manager.3. In Task Manager, from the File menu, select Run new task.

4. Type in the following command to open SQL Server Management Studio and then click OK:


"C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe"

5. SQL Server Management Studio launches. A Connect to Server dialog pops up.

6. Click Connect to connect to the SQL Server instance on SQL1.7. In the console tree, expand SQL1, then expand Security, and then click Logins.8. Right-click and select New Login. A Login – New dialog pops up.

9. For Login Name, click Search. A Select User or Group dialog pops up.

10. In Enter the object name to select, type “LITWARE369\AzureAdmin” and then click Check Names. A Windows Security dialog pops up.


11. Type “AzureAdmin” for the name of the account with “pass@word1” as password and click OK.

12. Click OK.13. Back in Login - New, in the navigation pane, select Server Roles.

14. In Server roles, check sysadmin.15. Click OK.


16. Close SQL Server Management Studio.

Starting the SQL Server Browser service To start the SQL Server Browser service, proceed with the following steps:

1. While still being logged on to the SQL1 computer with the previous remote desktop session, in Task Manager, from the File menu, select Run new task, type in the following to open the Services console and then click OK:

Services.msc

2. Scroll in the list of services and select SQL Server Browser.3. Right-click and select Properties. A SQL Server Browser Properties dialog pops

up.

4. In SQL Server Browser Properties, for Startup type, select Automatic and then click Apply.

5. Click Start to start the SQL Server Browser service.6. Click OK and then close the Services console.

Adding Windows Firewall exceptions for SQL Server portsTo add Windows Firewall exceptions for SQL Server ports, while still being logged on to the SQL1 computer with the previous remote desktop session, open an elevated Windows PowerShell command prompt if none, and run the following command:

PS C:\Users\AzureAdmin.LITWARE369> New-NetFirewallRule -DisplayName "SQL Server" -Direction Inbound –Protocol TCP –LocalPort 1433-1434,5022 -Action allow

Name : {82a6cf85-72ef-4322-aa0d-50481e278878}DisplayName : SQL ServerDescription :DisplayGroup :Group :Enabled : TrueProfile : AnyPlatform : {}Direction : InboundAction : Allow


EdgeTraversalPolicy : BlockLooseSourceMapping : FalseLocalOnlyMapping : FalseOwner :PrimaryStatus : OKStatus : The rule was parsed successfully from the store. (65536)EnforcementStatus : NotApplicablePolicyStoreSource : PersistentStorePolicyStoreSourceType : Local


The forthcoming configuration of the AD RMS cluster can use Microsoft SQL Server 2012.

Deploying the rights management server To deploy the AD RMS server, proceed with the following steps in order:

1. Opening a remote desktop connection on the target computer.2. Issuing a SSL/TLS certificate.3. Configuring HTTPS on the default web site.4. Configuring a new AD RMS root cluster.

Important note You must have domain administrator permissions to deploy the AD RMS role.

5. Testing the rights management server.The following subsections describe each of these steps in the context of our test lab environment. Unless noticed otherwise, all these steps are executed on the ADRMS1 computer.

Opening a remote desktop connection on the target computerTo open a remote desktop connection on the ADRMS1 computer, proceed as illustrated before with the DC1 computer but with the ADRMS1 computer instead. As previously


illustrated, log on as LITWARE369\AzureAdmin with “pass@word1” as password since ADRMS1 is a domain-joined computer.

Issuing a SSL/TLS certificateThe AD RMS role service will require a Secure Socket Layer (SSL) server certificate. The certificate MUST have the following attributes:

Subject Name (CN): adrms.litware369.com Subject Alternative Name (DNS): adrms.litware369.com

To issue the SSL certificate, proceed with the following steps:1. Open a remote desktop session if needed as LITWARE369\AzureAdmin.2. Open an elevated Windows PowerShell command prompt, and run the following

command:

PS C:\users\AzureAdmin.LITWARE369> Get-Certificate -Template SSLCertificates -SubjectName CN=adrms.litware369.com –DnsName adrms.litware369.com -CertStoreLocation cert:\LocalMachine\My



Note If you have not configured a new certificate template (e.g. the SSLCertificates in our configuration), you can use the WebServer certificate template in lieu of in the above command.


Configuring HTTPS on the default web siteTo configure HTTPS on the default web site, proceed with the following steps:

1. Open an elevated Windows PowerShell command prompt if none, and run the following command to add a SSL binding to the default web Site:

PS C:\users\AzureAdmin.LITWARE369> New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https


2. Run the following commands to associate the imported SSL certificate to the newly created SSL binding:

PS C:\users\AzureAdmin.LITWARE369> Get-ChildItem cert:\LocalMachine\MY | where { $_.Subject -match "CN\=adrms.litware369.com" } | select -First 1 | New-Item IIS:\SslBindings\0.0.0.0!443

IP Address Port Host Name Store Sites---------- ---- --------- ----- -----0.0.0.0 443 MY Default Web Site


3. Open a browsing session and navigate to the default web site at https://adrms.litware369.com.


https://adrms.litware369.com/

Configuring a new AD RMS root clusterIn Windows Server 2012 R2, adding the AD RMS role and deploying of a new AD RMS cluster are two separate processes. The role was added as part of the base configuration:

Install-WindowsFeature ADRMS -IncludeManagementTools

Install-WindowsFeature NET-Framework-Core

Additional configuration is now required to deploy the AD RMS server role. The AD RMS server role in Windows Server 2012 R2 is manageable by two sets of Windows PowerShell cmdlets. One set (AdRmsInstall) assists in deploying and configuring AD RMS, and the second set (AdRmsAdmin) can be later used to administer an AD RMS cluster.To run these two set of cmdlets, you need to import these modules:

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

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

After the modules are imported, you can manage and administer AD RMS installations and components through Windows PowerShell.

Note For additional information, you can refer to the Microsoft TechNet articles AD RMS CMDLETS IN WINDOWS POWERSHELL 73 and USING WINDOWS POWERSHELL TO DEPLOY AD RMS 74.

Deploying a new AD RMS root clusterTo deploy a new AD RMS root cluster, proceed with the following steps:

73 AD RMS CMDLETS IN WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/ee61727174 USING WINDOWS POWERSHELL TO DEPLOY AD RMS: http://go.microsoft.com/fwlink/?LinkId=136806



http://technet.microsoft.com/en-us/library/ee617271

http://technet.microsoft.com/en-us/library/ee617271

Note Additional details can be found in the Microsoft TechNet article INSTALLING AN AD RMS CLUSTER 75. To provide high availability for the cluster, you must install additional cluster members. For information on this installation, see the Microsoft TechNet article JOINING AN EXISTING CLUSTER 76.

1. Open an elevated Windows PowerShell command prompt if none, and run the following command to import the AdRmsInstall set of Windows PowerShell cmdlets:

PS C:\Users\AzureAdmin.LITWARE369> Import-Module AdRms


2. Run the following command to create a Windows PowerShell drive to represent the server we are provisioning:

PS C:\Users\AzureAdmin.LITWARE369> New-PSDrive -Name RC -PSProvider ADRMSInstall -Root RootCluster

Name Used (GB) Free (GB) Provider Root CurrentLocation---- --------- --------- -------- ---- ---------------RC ADRmsInstall RootCluster


At this stage, we can now set properties on objects in the drive namespace RC:\ that represent required configuration settings. Setting properties on objects in the drive namespace is similar to using a wizard to specify configuration settings when installing a server role.

3. Run the following command to configure the AD RMS server to use the SQL1 server and the default instance:

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty –Path RC:\ClusterDatabase -Name UseWindowsInternalDatabase -Value $false

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty –Path RC:\ClusterDatabase -Name ServerName -Value "SQL1"

WARNING: Verifying the specified database information. This may take a few minutes.


75 INSTALLING AN AD RMS CLUSTER: http://technet.microsoft.com/en-us/library/ee221041(v=ws.10).aspx76 JOINING AN EXISTING CLUSTER: h http://technet.microsoft.com/en-us/library/ee221028(v=ws.10).aspx


http://technet.microsoft.com/en-us/library/ee221028(v=ws.10).aspx



4. Run the following command to set the AD RMS service account:

PS C:\Users\AzureAdmin.LITWARE369> $svcacct = Get-Credential

cmdlet Get-Credential at command pipeline position 1Supply values for the following parameters:Credential

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty –Path RC:\ -Name ServiceAccount -Value $svcacct


When prompted, enter the following credential in the dialog below and click OK:Username: LITWARE369\ADRMSSVCPassword: pass@word1

5. Run the following command to securely store the cluster key password string in a variable and assign it to the AD RMS installation:

PS C:\Users\AzureAdmin.LITWARE369> $password = Read-Host -AsSecureString -Prompt "ClusterPassword:"

ClusterPassword:: **********

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path RC:\ClusterKey -Name UseCentrallyManaged -Value $true

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path RC:\ClusterKey -Name CentrallyManagedPassword -Value $password



When prompted, enter the following password: pass@word1

Note We choose to protect the AD RMS cluster key by using this option because it simplifies the configuration and does not require additional components. However, you should normally provide the best protection for this key through hardware Cryptographic Security Provider (CSP) for a HSM.

6. Run the following command to set the AD RMS cluster address:

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path RC:\ -Name ClusterURL -Value "https://adrms.litware369.com:443"


Note As a security best practice, the AD RMS cluster should be provisioned by using an SSL/TLS-encrypted connection. You should be using a certificate provided by a third-party public certification authority (CA) so that it can be automatically trusted by all parties. This certificate should already be installed on the server so that you can select it as you proceed through the installation.

7. Run the following command to set the SLC name for the AD RMS installation:

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path RC:\ -Name SLCName -Value "ADRMS"


8. Run the following command to register the SCP connection point:

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path RC:\ -Name RegisterSCP -Value $true


Note As noticed before, the service connection point (SCP) is an object in the Active Directory configuration partition that holds the Web address of the AD RMS cluster. As depicted at the beginning of this document, this object is not used by the Mobile Device Extension. The Mobile Device Extension rather relies on a DNS-based service discovery mechanism. However, since such an object is typically registered in AD RMS deployment, we will do the same here.Only one SCP can exist in your Active Directory forest. If you try to install an AD RMS cluster and an SCP already exists in your forest from a previous AD RMS installation (attempt) that was not properly de-provisioned, the new SCP will not install properly. It must be removed before you can establish the new SCP. You can remove an SCP by using the ADScpRegister.exe tool included in the Rights Management Services Administration Toolkit with SP2 available for download on the Microsoft Download Center77.

77 Rights Management Services Administration Toolkit with SP2: http://www.microsoft.com/downloads/details.aspx?familyid=BAE62CFC-D5A7-46D2-9063-0F6885C26B98&displaylang=en


http://www.microsoft.com/downloads/details.aspx?familyid=BAE62CFC-D5A7-46D2-9063-0F6885C26B98&displaylang=en

9. Run the following command to install the AD RMS root cluster using the settings provided in the Windows PowerShell drive:

PS C:\Users\AzureAdmin.LITWARE369> Install-ADRMS –Path RC:\This will install and configure AD RMS on this computer. Do you want to continue?[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): YWARNING: Before you can administer AD RMS on this server, you must log off and log on again.WARNING: Please configure SSL certificates on IIS before using AD RMS Server.


When prompted to confirm the installation and the configuration of AD RMS on the computer, type “Y” and press ENTER.In addition to installing the AD RMS server role and provisioning the server, this cmdlet also installs if necessary any other features required by AD RMS like Message Queuing to end the logs to the database server.


10. Restart the ADRMS1 computer.

Finalizing the configuration of the new AD RMS root clusterTo finalize the configuration of the newly installed AD RMS root cluster and fulfill the prerequisites of the Mobile Device Extension, proceed with the following steps:

Note Additional details can be found in the Microsoft TechNet articles USING WINDOWS POWERSHELL TO ADMINISTER AD RMS 78 and CONFIGURING AD RMS CLUSTER PROPERTIES 79.

1. Open a remote desktop session if needed as LITWARE369\AzureAdmin.2. Open an elevated Windows PowerShell command prompt, and run the following

command to import this time the AdRmsAdmin set of Windows PowerShell cmdlets:

PS C:\Users\AzureAdmin.LITWARE369> Import-Module AdRmsAdmin


3. Run the following command to create a Windows PowerShell drive that represents the newly installed cluster hosted by the local computer ADRMS1:

PS C:\Users\AzureAdmin.LITWARE369> New-PSDrive -Name AdrmsCluster -PsProvider AdRmsAdmin -Root https://localhost

Security AlertInformation you exchange with this site cannot be viewed or changed by others. However, there are the followingproblems with the site's security certificate:The name of the security certificate is not valid or does not match the name of the site. Do you want to continue?[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y

Name Used (GB) Free (GB) Provider Root CurrentLocation---- --------- --------- -------- ---- ---------------AdrmsCl... AdRmsAdmin AdrmsCluster:\


When prompted to confirm, type “Y” and press ENTER.At this stage, we can now set properties on objects in the drive namespace AdrmsCluster:\ that represent the configuration settings.

4. Run the following command to add an Extranet Cluster URL:

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path AdrmsCluster:\ -Name ExtranetLicensingURL -Value https://adrms.litware369.com:443/_wmcs/licensing

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path AdrmsCluster:\ -Name ExtranetCertificationURL -Value https://adrms.litware369.com:443/_wmcs/certification


78 USING WINDOWS POWERSHELL TO ADMINISTER AD RMS: http://technet.microsoft.com/en-us/library/ee221079(v=ws.10).aspx79 CONFIGURING AD RMS CLUSTER PROPERTIES: http://technet.microsoft.com/en-us/library/ee221079(v=ws.10).aspx





5. Close the Windows PowerShell command prompt.The AD RMS root cluster is now installed and configured.Once having completed logging in again, we can further manage AD RMS using the Active Directory Rights Management Services console.To open the Active Directory Rights Management Services console, in Server Manager, click Local Server in the console tree, then click Tools, and then click Active Directory Rights Management Services. The console opens up.

From the console, you can configure trust policies, configure exclusion policies, and create rights policy templates.The base configuration is now complete with all the dependencies in place for the Mobile Device Extension.To avoid spending your credit when you don’t work on the test lab, you can shut down the 5 VMs (DC1, ADFS1, SQL1, ADRMS1, 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 adrms1, adfs1, sql1, and then dc1.

4. Click YES. 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 computer, the SQL1 computer, the ADRMS1 computer, 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 in order with sql1, adrms1, and edge1.

You are now in a position to install and configure the Mobile Device Extension for AD RMS on your "on-premises" test lab environment.


Testing and evaluating the Mobile Device Extension for AD RMSThis walkthrough provides instructions for configuring the Mobile Device Extension for AD RMS in a Windows Server 2012 (R2) based environment. It is based on the “on-premises” test lab environment deployed in Azure as per previous sections. This environment satisfies all the prerequisites for the Mobile Device Extension.

Note For the purpose of this document, it leverages the Microsoft TechNet article ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES MOBILE DEVICE EXTENSION 80.

It consists in the following three steps that must be followed in order:1. Configuring AD FS for the Mobile Device Extension for AD RMS.2. Specifying the DNS SRV records for the Mobile Device Extension for AD RMS.3. Deploying the Mobile Device Extension for AD RMS.

The following subsections describe in the context of our test lab environment each of these steps.

Configuring AD FS for the Mobile Device Extension for AD RMSAutomatically configuring AD FS for the Mobile Device Extension The configuration of AD FS for the Mobile Device Extension for AD RMS consists in creating a relying party trust for the Mobile Device Extension along with:

1. An issuance transform rule that sources from AD DS and passes through the following claims for the authenticated user: Primary email address

(http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress) User principal name (UPN)

(http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn) Proxy email addresses if present

(http://schemas.xmlsoap.org/claims/ProxyAddresses)2. An authorization rule that permits the issuance of the above claims for all users.

To automatically configure AD FS in accordance, proceed with the following steps:1. Open a remote desktop connection on the ADFS1 computer as LITWARE369\

AzureAdmin with “pass@word1” as password.

80 ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES MOBILE DEVICE EXTENSION: http://technet.microsoft.com/en-us/library/dn673574(v=ws.10).aspx


http://technet.microsoft.com/en-us/library/dn673574(v=ws.10).aspx


2. Download on the Desktop the script Add-AdfsRelyingPartyTrust4TestLabEnvironment.ps181 and unblock it so that it can comply with the above execution policy and be executed in your environment.

Note The content of the script Add-AdfsRelyingPartyTrust4TestLabEnvironment.ps1 is the copy of the content provided in the Microsoft TechNet article ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES MOBILE DEVICE EXTENSION 82.

# This Script Configures the Microsoft Rights Management Mobile Device Extension and Claims used in the ADFS Server

# Check if Microsoft Rights Management Mobile Device Extension is configured on the Server $CheckifConfigured = Get-AdfsRelyingPartyTrust -Identifier "api.rms.rest.com"if ($CheckifConfigured){Write-Host "api.rms.rest.com Identifer used for Microsoft Rights Management Mobile Device Extension is already configured on this Server"Write-Host $CheckifConfigured }else{Write-Host "Configuring Microsoft Rights Management Mobile Device Extension "

# TransformaRules used by Microsoft Rights Management Mobile Device Extension# Claims: Email, UPN and ProxyAddresses$TransformRules = @"@RuleTemplate = "LdapClaims"@RuleName = "Jwt Token"c:[Type =="http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types =("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress","http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn","http://schemas.xmlsoap.org/claims/ProxyAddresses"), query =";mail,userPrincipalName,proxyAddresses;{0}", param = c.Value);

@RuleTemplate = "PassThroughClaims"@RuleName = "JWT pass through"c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] => issue(claim = c);

@RuleTemplate = "PassThroughClaims"@RuleName = "JWT pass through"c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(claim = c);

@RuleTemplate = "PassThroughClaims"@RuleName = "JWT pass through Proxy addresses"c:[Type == "http://schemas.xmlsoap.org/claims/ProxyAddresses"] => issue(claim = c);"@

# AuthorizationRules used by Microsoft Rights Management Mobile Device Extension# Allow All users$AuthorizationRules = @"@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit",Value = "true");"@

# Add a Relying Part Truest with Name -"Microsoft Rights Management Mobile Device Extension" Identifier "api.rms.rest.com"Add-ADFSRelyingPartyTrust -Name "Microsoft Rights Management Mobile Device Extension" -Identifier "api.rms.rest.com" -IssuanceTransformRules $TransformRules -IssuanceAuthorizationRules $AuthorizationRules

Write-Host "Microsoft Rights Management Mobile Device Extension Configured"

81 Add-AdfsRelyingPartyTrust4TestLabEnvironment.ps1: http://www.microsoft.com/en-us/download/details.aspx?id=3639182 ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES MOBILE DEVICE EXTENSION: http://technet.microsoft.com/en-us/library/dn673574(v=ws.10).aspx




}

3. Open a Windows PowerShell command prompt and run the following command to create the relying party trust named api.rms.rest.com:

PS C:\Users\AzureAdmin.LITWARE369> cd .\Desktop

PS C:\Users\AzureAdmin.LITWARE369\Desktop> .\Add-AdfsRelyingPartyTrust4TestLabEnvironment.ps1

Configuring Microsoft Rights Management Mobile Device Extension

Microsoft Rights Management Mobile Device Extension Configured

PS C:\Users\AzureAdmin.LITWARE369

Authorizing the RMS sharing app for your devicesTo authorizing the RMS sharing app for your devices, proceed with the following steps:

1. Open a remote desktop session if needed as LITWARE369\AzureAdmin.2. From the previous Windows PowerShell command prompt, run the following

command(s):For Android devices:

PS C:\users\AzureAdmin.litware369\Desktop> Add-AdfsClient -Name "RMS Sharing App for Android" -ClientId "ECAD3080-3AE9-4782-B763-2DF1B1373B3A" -RedirectUri @("com.microsoft.rms-sharing-for-android://authorize")

PS C:\users\AzureAdmin.litware369\Desktop>

For iPhone and iPad devices:

PS C:\users\AzureAdmin.litware369\Desktop> Add-AdfsClient -Name "RMS Sharing App for iOS" -ClientId "9D7590FB-9536-4D87-B5AA-FAA863DCC3AB" -RedirectUri @("com.microsoft.rms-sharing-for-ios://authorize")


For Mac devices:

PS C:\users\AzureAdmin.litware369\Desktop> Add-AdfsClient -Name "RMS Sharing App for OSX" -ClientId "96731E97-2204-4D74-BEA5-75DCA53566C3" -RedirectUri @("com.microsoft.rms-sharing-for-osx://authorize")



For Windows Phone devices:

PS C:\users\AzureAdmin.litware369\Desktop> Add-AdfsClient -Name "RMS Sharing App for WindowsPhone" -ClientId "6507DFAF-F19E-47C6-82C3-08AFEE79D74E" -RedirectUri @("com.microsoft.rms-sharing-for-wp://authorize")


For Windows RT devices:

PS C:\users\AzureAdmin.litware369\Desktop> Add-AdfsClient -Name "RMS Sharing App for Windows RT" -ClientId "D27EA168-C4FE-41E7-8876-B47FF6376003" -RedirectUri @("com.microsoft.rms-sharing-for-WinRT://authorize")


Note In order to allow access from OAuth 2.0 clients to REST resources secured by AD FS, the app have to be pre-registered with AD FS by using the cmdlet Add-AdfsClient83. AD FS will not allow access to a REST resource to clients that specify a client identifier or redirection URI that are not registered with AD FS. For additional information, see the Microsoft MDSN article DEVELOPING MODERN APPLICATIONS USING OAUTH AND ACTIVE DIRECTORY FEDERATION SERVICES 84.

Specifying the service discovery records for the Mobile Device Extension for AD RMSAs covered at the beginning of this document, we must create one or more DNS SRV records in the organization’s domain or domains:

One record for each email domain suffix that users will use, for example litware369.com in our configuration the test lab environment.

One record for every FQDN used by the AD RMS clusters in place to protect content.As far as the former is concerned, since our fictitious organization litware369.com has only users with the email addresses <user alias>@litware369.com, for example [email protected] and [email protected]) for the two users created before, only one DNS SRV record with the following value is required:

_rmsdisco._http._tcp.adrms.litware369.com 443 adrms.litware369.comThe following table can be used as a guide for the SRV record properties:

83 ADD-ADFSCLIENT: http://technet.microsoft.com/en-us/library/dn479319.aspx84 DEVELOPING MODERN APPLICATIONS USING OAUTH AND ACTIVE DIRECTORY FEDERATION SERVICES: http://msdn.microsoft.com/en-us/library/dn633593.aspx





Field Value

Domain _tcp.litware369.comService _rmsdiscoProtocol _httpPriority 0Weight 0Port number 443Host offering this service

adrms.litware369.com

As far as the latter is concerned, in the chosen test topology for our test lab, i.e. a single cluster in a single forest, only one DNS SRV record must be created for the AD RMS cluster adrms.litware369.com, pointing to the same cluster. This record has the following value:

_rmsdisco._http._tcp.adrms.litware369.com 443 adrms.litware369.comThe following table can be used as a guide for the SRV record properties:

Field Value

Domain _tcp.adrms.litware369.comService _rmsdiscoProtocol _httpPriority 0Weight 0Port number 443Host offering this service

adrms.litware369.com

Creating the service discovery records in the public registrarFor illustration purposes, we use the Go Daddy registrar in our Azure-based test lab environment.To add the above service discovery records, proceed with the following steps:

1. Open a browsing session with the browser of your choice from your local machine and navigate to http://www.godaddy.com/ and click Sign In. in the upper right corner. A Sign in dialog appears.


http://www.godaddy.com/

2. Enter your credentials and click Sign In. Once authenticated, The My Account page (https://mya.goddady.com) opens up.

3. On the Products tab, at the end of the DOMAINS row, click Launch.4. On the Domains page, find the domain name in which the service discovery records

should be added, in our case litware369.com.5. Click the domain name, in our case LITWARE369.COM. The Domain Details page

opens in a new tab in your browser.

6. Click DNS Zone File in the toolbar.


https://mya.goddady.com/

7. Click Add Record. An Add Zone Record dialog opens up.

8. Click the down arrow for the Record type: box and select SRV (Services). The Add DNS Record dialog displays the related fields.


9. To add the first service discovery record _rmsdisco._http._tcp.litware369.com 443 adrms.litware369.com:

a. For Name, type “_tcp.litware369.com” for the domain for which the record is valid.

b. For Target, type “adrms.litware369.com” for the host offering this service.c. For Protocol, type “_http”.d. For Service, type “_rmsdisco”.e. For Priority, type “0”.f. For Weight, type “0”.g. For Port, type “443”. h. For TTL:, leave the value set to 1 Hour.

10. Click Add Another.11. Repeat step 9 for the second discovery record

_rmsdisco._http._tcp.adrms.litware369.com 443 adrms.litware369.com.12. Click Finish.

13. Click Save Changes to save your two new SRV records14. Scroll down to the SRV (Service). You should see the two newly added SRV records.


15. Click OK.To check the above DNS for SRV entries for our domain, open a Windows PowerShell command prompt and run the following command:

PS C:\Users\AzureAdmin.LITWARE369> nslookup -type=SRV litware369.com 209.244.0.3Server: resolver1.level3.net

Address: 209.244.0.3

litware369.com primary name server = ns09.domaincontrol.com responsible mail addr = dns.jomax.net serial = 2014073101 refresh = 28800 (8 hours) retry = 7200 (2 hours) expire = 604800 (7 days) default TTL = 600 (10 mins)


Note You can specify one of the name server of your DNS zone instead of the external DNS server used above (209.244.0.3). In our illustration with GoDaddy.com, see the article FINDING YOUR HOSTING ACCOUNT'S NAME SERVERS 85 to determine the name servers. For our litware369.com zone, the name servers are ns09.domaincontrol.com (216.69.185.5) and ns10.domaincontrol.com (208.109.255.5).

If you see the SRV entry, you can continue with the deployment of the Mobile Device Extension. The Azure-based test lab environment uses a split brain DNS configuration. Thus, the above records enables a correct resolution whatever network the device is connected to.For organization that do not use such a DNS configuration, the optional next section illustrates how to locally declare these records.

Creating the service discovery records in the local DNSTo create the discovery record on the local DNS on the DC1 computer, proceed with the following steps:

1. Open a remote desktop session as LITWARE369\AzureAdmin on the DC1 computer if needed.

2. Open an elevated Windows PowerShell command prompt if none, and run the following command to add the first service discovery record _rmsdisco._http._tcp.litware369.com 443 adrms.litware369.com:

PS C:\users\AzureAdmin> Add-DnsServerResourceRecord -ZoneName "litware369.com" -Srv -Name "_rmsdisco._http._tcp" -DomainName "adrms.litware369.com" -Port 443 -Priority 0 -Weight 0


3. Run the following command to add the second service discovery record _rmsdisco._http._tcp.adrms.litware369.com 443 adrms.litware369.com:

PS C:\users\AzureAdmin> Add-DnsServerResourceRecord -ZoneName "litware369.com" -Srv -Name "_rmsdisco._http._tcp.adrms" -DomainName "adrms.litware369.com" -Port 443 -Priority 0 -Weight 0


85 FINDING YOUR HOSTING ACCOUNT'S NAME SERVERS: http://support.godaddy.com/help/article/6795


http://support.godaddy.com/help/article/6795

http://support.godaddy.com/help/article/6795

Deploying the Mobile Device Extension for AD RMSThe Mobile Device Extension for AD RMS have to be installed on all the nodes in an AD RMS cluster. In our test lab environment’s configuration, all the instructions below should be done on the ADRMS1 computer.

Disabling the IE Enhanced Security Configuration (ESC)The installation of the Mobile Device Extension implies to download a file from the Internet and should consequently be authorized.Since the ADRMS1 computer is intended to run on a test lab environment, the IE Enhanced Security Configuration could be disabled for the course of the installation operations. To disable the IE Enhanced Security Configuration (ESC), proceed with the following steps:

1. Open a remote desktop connection as LITWARE369\AzureAdmin on the ADRMS1 computer if needed.

2. Open an elevated Windows PowerShell command prompt if none, and run the following commands:

PS C:\Users\AzureAdmin.LITWARE369> $adminKey = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}"

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path $adminKey -Name "IsInstalled" -Value 0

PS C:\Users\AzureAdmin.LITWARE369> $userKey = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A8-37EF-4b3f-8CFC-4F3A74704073}"

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path $userKey -Name "IsInstalled" -Value 0

PS C:\Users\AzureAdmin.LITWARE369> Stop-Process -Name Explorer


Downloading the Mobile Device Extension for AD RMSTo download the Mobile Device Extension for AD RMS, proceed with the following steps:

1. From the previous remote desktop connection, open a browsing session and navigate to http://www.microsoft.com/en-us/download/details.aspx?id=43738.

2. Click Download.

3. Click Save.



4. Close the browsing session.

Installing the Mobile Device Extension for AD RMSTo install the Mobile Device Extension for AD RMS, proceed with the following steps:

1. From the previous remote desktop connection, open a command prompt, navigate to the location of the .exe file, and run the following command to start the setup:

PS C:\Users\AzureAdmin.LITWARE369> cd Downloads

PS C:\Users\AzureAdmin.LITWARE369\Downloads> .\ADRMS.MobileDeviceExtension.exe

The Active Directory Rights Management Services Mobile Device Extension Setup Wizard pops up.

2. Click Next.

3. Check I accept the terms in the License Agreement and click Next.


4. Type the URL of the AD FS server that you configured previously, for example “https://adfs.litware369.com” in our illustration, and then click Next.

5. Click Install.

6. Click Finish to complete the wizard.

Publishing the Mobile Device Extension endpoints over the InternetTo publish the Mobile Device Extension endpoints over the Internet, proceed with the following steps:


1. Open a remote desktop connection as LITWARE369\AzureAdmin on the EDGE1 computer if needed.

2. Open an elevated Windows PowerShell command prompt if none, and run the following commands:

PS C:\Users\AzureAdmin.LITWARE369> $certificateThumbprint = (Get-ChildItem cert:\LocalMachine\MY -DnsName "*adrms*" | Select-Object -First 1).Thumbprint

PS C:\Users\AzureAdmin.LITWARE369> Add-WebApplicationProxyApplication -Name "Microsoft Rights Management Mobile Device Extension" -BackendServerUrl https://adrms.litware369.com/_wmcs/ -ExternalPreauthentication "PassThrough" -ExternalUrl https://adrms.litware369.com/_wmcs/ -ExternalCertificateThumbprint $certificateThumbprint

PS C:\Users\AzureAdmin.LITWARE369> Add-WebApplicationProxyApplication -Name "Microsoft Rights Management Mobile Device Extension" -BackendServerUrl https://adrms.litware369.com/my/ -ExternalPreauthentication "PassThrough" -ExternalUrl https://adrms.litware369.com/my/ -ExternalCertificateThumbprint $certificateThumbprint

Since the AD RMS server is published through WAP, in addition to publishing the /_wmcs folder to the Internet, you need to also publish the /my folder, i.e. https:// adrms.litware369.com /my .

As this point, the semi-automated guided construction of the Azure-based test lab environment is complete. You may wish to test some content protection scenarios to ensure that the Mobile Device Extension for AD RMS along w/ all the pre-requisites are correctly configured and worked as expected.

Testing the Mobile Device ExtensionThe Azure-based test lab environment enables to easily test the Mobile Device Extension endpoints from any supported devices connected on the Internet thanks to the above publication of the related endpoints over the Internet.For that purpose, you can use the release of the RMS Sharing application for Android available at https://portal.aadrm.com that is specially designed to work with the Mobile Device Extension. If you don’t have any Android device in your possession to do the testing, section § SIMULATING AN ANDROID

DEVICE in the Appendix provides a procedure to create a virtual machine running on Hyper-V on your local Windows machine to fully emulate such an Android device with an Internet connection.

Troubleshooting the Mobile Device Extension The section provides troubleshooting information for the Mobile Device Extension if needed your own (Azure-based) test lab environment.

Turning on loggingIf you run into some specifics issues when testing of the Mobile Device Extension, you can turn on logging and then check the mobile device logs in the AD RMS database.


To turn on logging of the rights management server ADRMS1, proceed with the following steps:

1. Open a remote desktop connection on the ADRMS1 computer as LITWARE369\AzureAdmin with “pass@word1” as password.

2. Open an elevated Windows PowerShell command prompt, and run the following command to import this time the AdRmsAdmin set of Windows PowerShell cmdlets:

PS C:\Users\AzureAdmin.LITWARE369> Import-Module AdRmsAdmin


3. Run the following command to create a Windows PowerShell drive that represents the cluster hosted by the local computer:

PS C:\Users\AzureAdmin.LITWARE369> New-PSDrive -Name AdrmsCluster -PsProvider AdRmsAdmin -Root https://localhost


At this stage, we can now set properties on objects in the drive namespace AdrmsCluster:\ that represent the configuration settings.

4. Run the following command to turn on logging:

PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path AdrmsCluster:\ -Name IsLoggingEnabled -Value $true


Note To turn off logging, you simply need to rerun the above command with a value of $false.

5. Close the Windows PowerShell command prompt.At this stage, any call to the Mobile Device Extension are logged in the Mobile Device Extension logs to help you in troubleshooting the issue if any, and resolve it. If you are still stumped, please join the user group AskIPTeam on Yammer at http://www.yammer.com/AskIPTeam and search/request for troubleshooting information pertaining to the same issue you face with.

Analyzing the Mobile Device Extension logs The Mobile Device Extension provides the following two tables to help investigate and troubleshoot client issues:

1. The Client Debug Log (ClientDebugLog) table.2. The Client Performance Log (Client Performance Log) table.

The next two sections provide a description of these tables.

Understanding the Client Debug Log tableThe Client Debug Log (ClientDebugLog) table in the AD RMS database contains as its name indicates the debug logs in order to investigate client issues.


http://www.yammer.com/AskIPTeam

The following table provides the field definitions.Field name Data

typeDescription Example value

Id uniqueidentifier

GUID of the trace entry. This helps in troubleshooting client issues.

201724F-270D-430E-AFD2-0BB26F896C05

UserId nvarchar User who made the request. Their user email address is used to identify the user.

[email protected]

ClientTimeStamp datetime UTC Date and Time in 24H format the trace entry was written.

2014-07-08 23:19:45.000

Message nvarchar Free form text that contains the message for the trace entry.

getAuthInfo: authInfo:{mAuthServerUrl:https://adfs.litware369.com/adfs/oauth2/authorize}{mResource:api.rms.rest.com}{mScope:null}

ThreadId int Identifier that can tie the set of operations that are happening the same thread.

5021

TraceLevel nchar Type of the message of the trace entry. Supported types are

Error Warning Info Verbose

Info

ClientCorrelationId uniqueidentifier

GUID that is common between the RMS client and the server for a given request. This helps in troubleshooting client issues. If the trace entry is not a call to the server, this is empty.

00000000-0000-0000-0000-000000000000

ClientScenarioId uniqueidentifier

GUID that identifies the client scenario the trace entry was written under. A client scenario cover zero or more call to the server.

6BD8AF07-AE25-41D9-AAA2-6641BFF2A1A2

CreateTime datetime UTC Date and Time in 24H format when the call was served. The source is the local clock on the server that served the call.

2014-07-08 23:19:48.803

FullClientInformation

nvarchar Client side information including the device environment (platform OS and model), the RMS SDK version, the RMS-enlightened application

DevicePlatform=Android;DeviceModel=Samsung ABC;SDKVersion=4.0;AppName=SampleApp.exe;AppPublisherId=123

Understanding the Client Performance Log tableThe Client Performance Log table in the AD RMS database contains as its name indicates the performance logs in order to help understand the experience that the end users are having when using their mobile device(s) with RMS-enlightened applications.


The following table provides the field definitions.Field name Data

typeDescription Example value

Id uniqueidentifier

GUID of the trace entry. This helps in troubleshooting client issues.

19A56FFA-7386-4C87-BEAA-2765627E2EDD

UserId nvarchar User who made the request. Their user email address is used to identify the user.

[email protected]

ClientTimeStamp datetime UTC date and time in 24H format the trace entry was written.

2014-06-27 07:11:28.000

OperationName nvarchar Name of the operation. Operations serve two purposes. Operations can represent client scenarios, which cover zero or more calls to the server (like Consume or Protect), and they can represent a specific call to the server. In the case it represents a specific call to the server, the ClientCorrelationId field is set. In the case it represents a client scenario, the ClientCorrelationId is empty (See below). In both cases, the ClientScenarioId field is set.

GetServiceDiscoveryURLs

Latency bigint Time it took to complete the operation in milliseconds.

142

ClientCorrelationId uniqueidentifier

GUID that is common between RMS client and server for a given call. This helps in troubleshooting client issues. If the trace entry is not a call to the server, this is empty.

B079C03D-FD9A-4CE3-BA16-4C8745491854

ClientScenarioId uniqueidentifier

GUID that identifies the client scenario the trace entry was written under. A client scenario cover zero or more call to the server.

6BD8AF07-AE25-41D9-AAA2-6641BFF2A1A2

FullClientInformation

nvarchar Client side information including the device environment (platform OS and model), the RMS SDK version, the RMS-enlightened application

DevicePlatform=Android;DeviceModel=Samsung ABC;SDKVersion=4.0;AppName=SampleApp.exe;AppPublisherId=123

NetworkType nvarchar Placeholder for future network information for the RMS client. This is empty.

CreateTime Datetime UTC Date and Time in 24H format when the call was served. The source is the local clock on the server that served the call.

2014-06-27 07:11:18.280

This concludes the guided tour of the Mobile Device Extension for AD RMS.


AppendixThis appendix describes how to change the default User Account Control (UAC) behavior.

Setting UAC behavior of the elevation prompt for administratorsBy default, UAC is enabled in Windows Server 2012 R2. This service will prompt for permission to continue during several of the configuration tasks described in this guide. In all cases, you can click Continue in the UAC dialog box to grant this permission, or you can use the following procedure to change the UAC behavior of the elevation prompt for administrators.To set UAC behavior of the elevation prompt for administrators, proceed with the following steps:

1. From the Start screen, type “secpol.msc”, and press ENTER.2. In the console tree, open Local Policies, and then click Security Options.3. In the contents pane, double-click User Account Control: Behavior of the

elevation prompt for administrators in Admin Approval Mode.4. Select Elevate without prompting in the list, and then click OK.5. Close the Local Security Policy window

Simulating an Android deviceTo simulate an Android device, you can create a Linux virtual machine running on Hyper-V on your local machine to fully emulate an Android device thanks to the open source Android x86 project 86 .

Note For additional information, see the blog posts CREATING AN ANDROID X86 VIRTUAL MACHINE FOR TESTING WINDOWS INTUNE AND EMS CAPABILITIES 87 and INSTALLING ANDROID-X86 ON HYPER-V WITH WINDOWS 8.1 IN UNDER 5 MINUTES 88.

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.

86 Android-x86 Project – Run Android on Your PC: http://www.android-x86.org/87 CREATING AN ANDROID X86 VIRTUAL MACHINE FOR TESTING WINDOWS INTUNE AND EMS CAPABILITIES: http://www.theenterprisemobilityguy.com/2014/07/creating-an-android-x86-virtual-machine-for-testing-windows-intune-and-ems-capabilities-3/88 INSTALLING ANDROID-X86 ON HYPER-V WITH WINDOWS 8.1 IN UNDER 5 MINUTES: http://www.servethehome.com/installing-android-x86-hyper-v-windows-8-1/


http://www.servethehome.com/installing-android-x86-hyper-v-windows-8-1

http://www.servethehome.com/installing-android-x86-hyper-v-windows-8-1

http://www.theenterprisemobilityguy.com/2014/07/creating-an-android-x86-virtual-machine-for-testing-windows-intune-and-ems-capabilities-3/

http://www.theenterprisemobilityguy.com/2014/07/creating-an-android-x86-virtual-machine-for-testing-windows-intune-and-ems-capabilities-3/

http://www.android-x86.org/

http://www.android-x86.org/

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.© 2016 Microsoft Corporation. All rights reserved.The example companies, organizations, products, domain names, email addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, email 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.


Documents

Leverage the Mobile Device Extension for AD RMS Web view20 Leverage the Mobile Device Extension for ... the Mobile Device Extension for AD RMS enables to expose rights management service