Active Directory Rights Management Services Mobile Device Extension
Applies To: Windows Server 2012 R2, Windows Server 2012
You can download the Active Directory Rights Management Services (AD RMS) mobile device extension from the Microsoft Download Center and install this extension on top of an existing AD RMS deployment. This lets users who have mobile devices and Mac computers protect and consume sensitive data when their device supports the latest RMS client and uses RMS-enlightened apps. For example, users on these device can do the following:
Use the Azure Information Protection app or the RMS sharing app to consume protected text files in different formats (including .txt, .csv, and .xml).
Use the Azure Information Protection app or the RMS sharing app to consume protected image files (including .jpg, .gif, and .tif).
Use the RMS sharing app to open any file that has been generically protected (.pfile format).
Use the Azure Information Protection app or the RMS sharing app to open an Office file (Word, Excel, PowerPoint) that is a PDF copy (.ppdf format).
Use the Azure Information Protection app to open protected email messages (.rpmsg) and protected PDF files on SharePoint Online.
Use an RMS-enlightened PDF viewer for mobile devices to open PDF files that were protected with the RMS sharing application 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 RMS SDK.
Note
The RMS sharing app for iOS and Android is now replaced by the Azure Information Protection app.
You can download the Azure Information Protection app for iOS and Android and download the RMS sharing app for Windows Phone and Mac computers from the Microsoft Rights Management page on the Microsoft website. For information about other apps that are supported with the mobile device extension, see the table in the Applications page from the Azure Rights Management documentation.
For more information about the different file types that RMS supports, see the Supported file types and file name extensions section from the Rights Management sharing application administrator guide.
You don’t need the mobile device extension to consume or author protected email on devices if they use mail applications that support Exchange ActiveSync IRM. This native support for RMS and mobile devices was introduced with Exchange 2010 Service Pack 1.
For Mac computers and Office 2016 for Mac:
- If you have already installed the mobile device extension, check that it supports this latest Office version. Look for Active Directory Rights Management Services Mobile Device Extension listed in Programs and Features and confirm that the version is at least 1.0.0112.0630. If it is not, follow the deploying instructions in this article to install the latest version from the Download Center. There's no need to manually uninstall the old version first; the Setup wizard can upgrade an existing version.
Use the following sections to deploy the Active Directory Rights Management Services (AD RMS) mobile device extension:
Important
Be sure to read and configure the prerequisites before you install the mobile device extension.
For additional information, download the “Leverage the Mobile Device Extension for AD RMS” white paper and accompanying scripts from the Microsoft Download Center.
Prerequisites for the AD RMS mobile device extension
Before you install the AD RMS mobile device extension, make sure that these dependencies are in place.
| Requirement | More information |
|---|---|
| An existing AD RMS deployment on Windows Server 2016, Windows Server 2012 R2, or Windows Server 2012, that includes the following: - Your AD RMS cluster must be accessible from the Internet. - AD RMS must be using 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. - The account that you will use to install the mobile device extension must have sysadmin rights for the SQL Server instance that you’re using for AD RMS. - The AD RMS servers must be configured to use SSL/TLS with a valid x.509 certificate that is trusted by the mobile device clients. - If the AD RMS servers are behind a firewall or published by using a reverse proxy, in addition to publishing the /_wmcs folder to the Internet, you must also publish the /my folder (for example: https://RMSserver.contoso.com/my). |
For documentation about AD RMS prerequisites and deployment information, see Active Directory Rights Management Services in the Windows Server library. |
| AD FS deployed on Windows Server 2012 R2: - Your AD FS server farm must be accessible from the Internet (you have deployed federation server proxies). - Forms-based authentication is not supported; you must use Windows Integrated Authentication Important: AD FS must be running a different computer from the computer running AD RMS and the mobile device extension. |
For documentation about AD FS, see Windows Server 2012 R2 AD FS Deployment Guide in the Windows Server library. AD FS must be configured for the mobile device extension. For instructions, see the Configuring AD FS for the AD RMS mobile device extension section in this topic. |
| Mobile devices must trust the PKI certificates on the RMS server (or servers) | When you purchase your server certificates from a public CA, such as VeriSign or Comodo, it’s likely that mobile devices will already trust the root CA for these certificates, so that these devices will trust the server certificates without addition configuration. However, if you use your own internal CA to deploy the server certificates for RMS, you must take additional steps to install the root CA certificate on the mobile devices. If don’t do this, mobile devices will not be able to establish a successful connection with the RMS server. |
| SRV records in DNS | Create one or more SRV records in your company domain or domains: 1: Create a record for each email domain suffix that users will use 2: Create a record for every FQDN used by your RMS clusters to protect content, not including the cluster name These records must be resolvable from any network that the connecting mobile devices use, which includes the intranet if your mobile devices connect via the intranet. When users supply their email address from their mobile device, the domain suffix is used to identify whether they should use an AD RMS infrastructure or Azure RMS. When the SRV record is found, clients are redirected to the AD RMS server that responds to that URL. When users consume protected content with a mobile device, the client application looks in DNS for a record that matches the FQDN in the URL of the cluster that protected the content (without the cluster name). The device is then directed to the AD RMS cluster specified in the DNS record and acquires a license to open the content. In most cases, the RMS cluster will be the same RMS cluster that protected the content. For information about how to specify the SRV records, see the Specifying the DNS SRV records for the AD RMS mobile device extension section in this topic. |
| Supported clients using applications that are developed by using the RMS SDK for this platform (such as the latest RMS sharing app): - macOS: Minimum version of macOS 10.8 (Mountain Lion) - Windows Phone: Windows 10 Mobile and Windows Phone 8.1 - Android phones and tablets: Minimum version of Android 5.0.1 - iPhone and iPad: Minimum version of iOS 7.0 Exception: The Azure Information Protection app for iOS has a minimum version of iOS 8. |
Download the supported apps for the devices that you use by using the links on the Microsoft Azure Information Protection download page. |
Configuring AD FS for the AD RMS mobile device extension
You must first configure AD FS, and then authorize the RMS sharing app for the devices that you want to use.
Step 1: To configure AD FS
You can either run a Windows PowerShell script to automatically configure AD FS to support the AD RMS mobile device extension, or you can manually specify the configuration options and values:
To automatically configure AD FS for the AD RMS mobile device extension, copy and paste the following into a Windows PowerShell script file, and then run it:
# 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: E-mail, UPN and ProxyAddresses $TransformRules = @" @RuleTemplate = "LdapClaims" @RuleName = "Jwt Token" c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "https://schemas.xmlsoap.org/claims/ProxyAddresses"), query = ";mail,userPrincipalName,proxyAddresses;{0}", param = c.Value); @RuleTemplate = "PassThroughClaims" @RuleName = "JWT pass through" c:[Type == "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "JWT pass through" c:[Type == "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(claim = c); @RuleTemplate = "PassThroughClaims" @RuleName = "JWT pass through Proxy addresses" c:[Type == "https://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 = "https://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" }To manually configure AD FS for the AD RMS mobile device extension, use these settings:
Configuration Value Relying Party Trust api.rms.rest.com Claim rule Attribute store: Active Directory
E-mail addresses: E-mail-address
User-Principal-Name: UPN
Proxy-Address: https://schemas.xmlsoap.org/claims/ProxyAddressesTip
For step-by-step instructions for an example deployment of AD RMS with AD FS, see Deploying Active Directory Rights Management Services with Active Directory Federation Services.
Step 2: Authorize apps for your devices
Run the following Windows PowerShell commands to add support for the Azure Information Protection app or RMS sharing app on your devices:
For Mac devices (using the RMS sharing app):
Add-AdfsClient -Name "RMS Sharing App for macOS" -ClientId "96731E97-2204-4D74-BEA5-75DCA53566C3" -RedirectUri @("com.microsoft.rms-sharing-for-osx://authorize")For iOS devices (using the Azure Information Protection app):
Add-AdfsClient -Name "Azure Information Protection app for iOS" -ClientId "9D7590FB-9536-4D87-B5AA-FAA863DCC3AB" -RedirectUri @("com.microsoft.rms-sharing-for-ios://authorize")For Windows Phone devices (using the RMS sharing app):
Add-AdfsClient -Name "RMS Sharing App for WindowsPhone" -ClientId "6507DFAF-F19E-47C6-82C3-08AFEE79D74E" -RedirectUri @("com.microsoft.rms-sharing-for-wp://authorize")For Android devices (using the Azure Information Protection app):
Add-AdfsClient -Name "Azure Information Protection app for Android" -ClientId "ECAD3080-3AE9-4782-B763-2DF1B1373B3A" -RedirectUri @("com.microsoft.rms-sharing-for-android://authorize")For Windows RT devices (using the RMS sharing app):
Add-AdfsClient -Name "RMS Sharing App for Windows RT" -ClientId "D27EA168-C4FE-41E7-8876-B47FF6376003" -RedirectUri @("com.microsoft.rms-sharing-for-WinRT://authorize")
Run the following Windows PowerShell commands to add support for Microsoft Office apps on your devices:
For Mac, iOS, Android, and Windows Phone devices (run both commands in the order shown):
-
Add-AdfsClient –Name "Office for Mac and Office Mobile" –ClientId "d3590ed6-52b3-4102-aeff-aad2292ab01c" –RedirectUri @("urn:ietf:wg:oauth:2.0:oob") -
Set-AdfsClient -TargetClientId d3590ed6-52b3-4102-aeff-aad2292ab01c -RedirectUri "urn:ietf:wg:oauth:2.0:oob","launch-word://com.microsoft.Office.Word","launch-excel://com.microsoft.Office.Excel","launch-ppt://com.microsoft.Office.Powerpoint"
-
Specifying the DNS SRV records for the AD RMS mobile device extension
You must create DNS SRV records for each email domain that your users use. If all your users use child domains from a single parent domain, and all users from this contiguous namespace use the same RMS cluster, you can use just one SRV record in the parent domain, and RMS will find the appropriate DNS records.
The SRV records have the following format: _rmsdisco._http._tcp. <emailsuffix><portnumber><RMSClusterFQDN>
Note
Specify 443 for the <portnumber>. Although can you specify a different port number in DNS, devices using the mobile device extension will always use 443.
For example, if your organization has users with the following email addresses:
user@contoso.com
user@sales.contoso.com
user@fabrikam.com
- and there are no other child domains for contoso.com that use a different RMS cluster than the one named rmsserver.contoso.com, create two DNS SRV records that have these values:
_rmsdisco._http._tcp.contoso.com 443 rmsserver.contoso.com
_rmsdisco._http._tcp.fabrikam.com 443 rmsserver.contoso.com
If you use the DNS Server role on Windows Server, use the following tables as a guide for the SRV record properties in the DNS Manager console:
| Field | Value |
|---|---|
| Domain | _tcp.contoso.com |
| Service | _rmsdisco |
| Protocol | _http |
| Priority | 0 |
| Weight | 0 |
| Port number | 443 |
| Host offering this service | rmsserver.contoso.com |
| Field | Value |
|---|---|
| Domain | _tcp.fabrikam.com |
| Service | _rmsdisco |
| Protocol | _http |
| Priority | 0 |
| Weight | 0 |
| Port number | 443 |
| Host offering this service | rmsserver.contoso.com |
In addition to these DNS SRV records for your email domain, you must create another DNS SRV record in the RMS cluster domain. This record must specify the FQDNs of your RMS cluster that protects content. Every file that is protected by RMS includes a URL to the cluster that protected that file. Mobile devices use the DNS SRV record and the URL FQDN specified in the record to find the corresponding RMS cluster that can support mobile devices.
For example, if your RMS cluster is rmsserver.contoso.com, create a DNS SRV record that has the following values: _rmsdisco._http._tcp.contoso.com 443 rmsserver.contoso.com
If you use the DNS Server role on Windows Server, use the following table as a guide for the SRV record properties in the DNS Manager console:
| Field | Value |
|---|---|
| Domain | _tcp.contoso.com |
| Service | _rmsdisco |
| Protocol | _http |
| Priority | 0 |
| Weight | 0 |
| Port number | 443 |
| Host offering this service | rmsserver.contoso.com |
Deploying the AD RMS mobile device extension
Before you install the AD RMS mobile device extension, make sure that the prerequisites from the preceding section are first in place, and that you know the URL of your AD FS server. Then do the following:
Download the AD RMS mobile device extension (ADRMS.MobileDeviceExtension.exe) from the Microsoft Download Center.
Run ADRMS.MobileDeviceExtension.exe to start the Active Directory Rights Management Services Mobile Device Extension Setup Wizard.
When prompted, enter the URL of the AD FS server that you configured previously.
Complete the wizard.
Run this wizard on all the nodes in your RMS cluster.
If you have a proxy server between the AD RMS cluster and the AD FS servers, by default, your AD RMS cluster will not be able to contact the federated service. When this happens, AD RMS will be unable to verify the token that is received from the mobile client and will reject the request. If you have proxy server that blocks this communication, you must update the web.config file from the AD RMS mobile device extension website, so that AD RMS can bypass the proxy server when it needs to contact the AD FS servers.
Updating proxy settings for the AD RMS mobile device extension
Open the web.config file that is located in \Program Files\Active Directory Rights Management Services Mobile Device Extension\Web Service.
Add the following node to the file:
<system.net> <defaultProxy> <proxy proxyaddress="https://<proxy server>:<port>" bypassonlocal="true" /> <bypasslist> <add address="<AD FS URL>" /> </bypasslist> </defaultProxy> <system.net>Make the following changes, and then save the file:
Replace <proxy-server> with the name or address of your proxy server.
Replace <port> with the port number that the proxy server is configured to use.
Replace <AD FS URL> with the URL of the federation service. Do not include the HTTP prefix.
Note
To learn more about overriding the proxy settings, see Proxy Configuration in the Developer Network documentation.Reset IIS, for example, by running iisreset as an administrator from a command prompt.
Repeat this procedure on all the nodes in your RMS cluster.