Active Directory Rights Management Services Mobile Device Extension
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 protect and consume sensitive data when their device supports the latest API-enlightened apps. For example, users can do the following on their mobile devices:
- Use the Azure Information Protection app to consume protected text files in different formats (including .txt, .csv, and .xml).
- Use the Azure Information Protection app to consume protected image files (including .jpg, .gif, and .tif).
- Use the Azure Information Protection app to open any file that has been generically protected (.pfile format).
- Use the Azure Information Protection app to open an Office file (Word, Excel, PowerPoint) that is a PDF copy (.pdf and .ppdf format).
- Use the Azure Information Protection app to open protected email messages (.rpmsg) and protected PDF files on Microsoft SharePoint.
- Use an AIP-enlightened PDF viewer for cross-platform viewing or to open PDF files that were protected with any AIP-enlightened application.
- Use your internally developed AIP-enlightened apps that were written by using the MIP SDK.
Note
You can download the Azure Information Protection app from the Microsoft Rights Management page of the Microsoft website. For information about other apps that are supported with the mobile device extension, see the table in the Applications page from this 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.
Important
Be sure to read and configure the prerequisites before you install the mobile device extension.
For additional information, download the "Microsoft Azure Information Protection" white paper and accompanying scripts from the Microsoft Download Center.
Prerequisites for AD RMS mobile device extension
Before you install the AD RMS mobile device extension, make sure the following dependencies are in place.
| Requirement | More information |
|---|---|
| An existing AD RMS deployment on Windows Server 2019, 2016, 2012 R2, or 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 details about AD RMS prerequisites and deployment information, see the prerequisites section of this article. |
| AD FS deployed on your Windows Server: - 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 the Windows Server 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 AIP. 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 MIP SDK for this platform. | 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 AIP 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 ==
"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"
}
- 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/ProxyAddresses |
Tip
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 command after replacing the variables to add support for the Azure Information Protection app. Make sure to run both commands in the order shown:
Add-AdfsClient -Name "R<your application name> " -ClientId "<YOUR CLIENT ID >" -RedirectUri @("<YOUR REDIRECT URI >")
Grant-AdfsApplicationPermission -ClientRoleIdentifier '<YOUR CLIENT ID>' -ServerRoleIdentifier api.rms.rest.com -ScopeNames "openid"
Powershell Example
Add-AdfsClient -Name "Fabrikam application for MIP" -ClientId "96731E97-2204-4D74-BEA5-75DCA53566C3" -RedirectUri @("com.fabrikam.MIPAPP://authorize")
Grant-AdfsApplicationPermission -ClientRoleIdentifier '96731E97-2204-4D74-BEA5-75DCA53566C3' -ServerRoleIdentifier api.rms.rest.com -ScopeNames "openid"
- For the Azure Information Protection unified labeling client, run the following Windows PowerShell command to add support for the Azure Information Protection client on your devices:
Add-AdfsClient -Name "Azure Information Protection Client" -ClientId "c00e9d32-3c8d-4a7d-832b-029040e7db99" -RedirectUri @("com.microsoft.azip://authorize")
Grant-AdfsApplicationPermission -ClientRoleIdentifier "c00e9d32-3c8d-4a7d-832b-029040e7db99" -ServerRoleIdentifier api.rms.rest.com -ScopeName "openid"
- To support ADFS on Windows 2016 and 2019 and ADRMS MDE for third party products, run the following Windows PowerShell command:
Add-AdfsClient -Name "YOUR APP" -ClientId 'YOUR CLIENT ID' -RedirectUri @("YOUR REDIRECT")
Grant-AdfsApplicationPermission -ClientRoleIdentifier 'YOUR CLIENT ID' -ServerRoleIdentifier api.rms.rest.com -ScopeNames "openid"
To configure the AIP client on Windows, Mac, mobile and Office Mobile for consuming HYOK or AD RMS protected content with AD FS on Windows Server 2012 R2 and newer, use the following:
- For Mac devices (using the RMS sharing app), make sure to run both commands in the order shown:
Add-AdfsClient -Name "RMS Sharing App for macOS" -ClientId "96731E97-2204-4D74-BEA5-75DCA53566C3" -RedirectUri @("com.microsoft.rms-sharing-for-osx://authorize")
Grant-AdfsApplicationPermission -ClientRoleIdentifier '96731E97-2204-4D74-BEA5-75DCA53566C3' -ServerRoleIdentifier api.rms.rest.com -ScopeNames "openid"
- For iOS devices (using the Azure Information Protection app), make sure to run both commands in the order shown:
Add-AdfsClient -Name "Azure Information Protection app for iOS" -ClientId "9D7590FB-9536-4D87-B5AA-FAA863DCC3AB" -RedirectUri @("com.microsoft.rms-sharing-for-ios://authorize")
Grant-AdfsApplicationPermission -ClientRoleIdentifier '9D7590FB-9536-4D87-B5AA-FAA863DCC3AB' -ServerRoleIdentifier api.rms.rest.com -ScopeNames "openid"
- For Android devices (using the Azure Information Protection app), make sure to run both commands in the order shown:
Add-AdfsClient -Name "Azure Information Protection app for Android" -ClientId "ECAD3080-3AE9-4782-B763-2DF1B1373B3A" -RedirectUri @("com.microsoft.rms-sharing-for-android://authorize")
Grant-AdfsApplicationPermission -ClientRoleIdentifier 'ECAD3080-3AE9-4782-B763-2DF1B1373B3A' -ServerRoleIdentifier api.rms.rest.com -ScopeNames "openid"
Run the following PowerShell commands to add support for Microsoft Office apps on your devices:
- For Mac, iOS, Android devices (make sure to 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"
Grant-AdfsApplicationPermission -ClientRoleIdentifier d3590ed6-52b3-4102-aeff-aad2292ab01c -ServerRoleIdentifier api.rms.rest.com -ScopeNames "openid"
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 If 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 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="http://<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 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.
See Also
Find out more about Azure Information Protection, make contact with other AIP customers, and with AIP product managers using the API yammer group.