What's New in Active Directory Rights Management Services (AD RMS)

Applies To: Windows Server 2012

This document provides details of new deployment enhancements for Active Directory Rights Management Services (AD RMS) in Windows Server® 2012. These changes should enable IT professionals working with AD RMS to meet the needs of their business in a secure, reliable, and flexible way.

What’s new in AD RMS in Windows Server 2012

AD RMS is the server role that provides you with management and development tools that work with industry security technologies—including encryption, certificates, and authentication—to help organizations create reliable information protection solutions. For more information, see Active Directory Rights Management Services Overview.

New AD RMS features covered in this topic include:

• Changes to AD RMS and Microsoft SQL Server requirements.

• Changes in deployment of AD RMS when using Server Manager and Windows PowerShell

Changes in AD RMS and SQL Server requirements

For Windows Server 2012, requirements for configuring Microsoft SQL Server to support AD RMS have been revised or changed in response to customer feedback.

What value does this change add?

The following changes to AD RMS Setup have been made to enable better support for remote deployment of AD RMS and SQL servers and to address customer feedback that requested more flexible deployment options.

What works differently?

In previous releases, AD RMS setup required that the account used to install AD RMS must have local administrator privilege on any computers hosting a SQL Server installation that was to be used to support the storage of AD RMS-related data. This was because AD RMS Setup required the ability to read SQL database settings from the Windows Registry. Because of customer feedback, this has been changed for this release.

For Windows Server 2012, AD RMS now has the following requirements for access to SQL Server.

• The AD RMS installer account must have sysadmin permissions in the SQL Server installation.

• The SQL Server Browser service must be running to locate available SQL instances.

• Firewall exceptions should be enabled on the SQL server computer for ports that will be used by AD RMS setup. The TCP port for the SQL instance that will host the AD RMS databases should be enabled. The UDP port for the SQL Server Browser service should also be enabled. For example, the default ports are usually TCP port 1433 for the SQL Server instance and UDP port 1434 for the SQL Server Browser service.

In addition to the previous access requirements, for Windows Server 2012 the following versions of Microsoft SQL Server have been tested and are supported for use with AD RMS deployment.

• SQL Server 2005 Service Pack 3

• SQL Server 2008 Service Pack 3

• SQL Server 2008 R2 Service Pack 1

• SQL Server 2012

For more information on applicable SQL Server requirements for AD RMS, see AD RMS SQL Server Requirements.

Changes in deployment of AD RMS for Server Manager and Windows PowerShell

In previous releases, AD RMS Setup supported only deployment at the same server computer where AD RMS was to be installed. Based on customer feedback, this has been changed. For Windows Server 2012, AD RMS now supports remote deployment at targeted server computers.

What value does this change add?

The following changes to AD RMS Setup have been made to enable better integration with the newly revised Server Manager in Windows Server 2012 which better supports secure and flexible remote server deployment for AD RMS and other Active Directory technologies.

What works differently?

As a result of this change, when deploying AD RMS on remote servers to ensure the security of your deployment, you will be prompted for user credentials. Deployment now also requires an additional step that can be completed using either Server Manager or Windows PowerShell.

Using Server Manager to deploy AD RMS

For Windows Server 2012, Server Manager has been redesigned to provide support for remote deployment of AD RMS as part of a two-step process that can be summarized as follows:

1. Launch the Add Roles and Features Wizard in Server Manager to add the AD RMS role. This will add and install the files necessary for AD RMS.

2. After adding the AD RMS role, launch the AD RMS Configuration wizard to select deployment options and configure the AD RMS cluster.

When the AD RMS configuration wizard first launches, if you are installing AD RMS on a remote server you will be prompted for the credentials needed to complete AD RMS configuration.

The requirements for selecting the credentials that you enter here are as follows:

• The account used to deploy AD RMS must have membership in the local Administrators group on the server computer where you are installing and configuring AD RMS.

• The account used must also have sysadmin permissions on the server that hosts the configuration database for the AD RMS cluster.

  Note

  
  Prompting for credentials only occurs in Server Manager if you are installing AD RMS to a remote server; however, the credentials requirements are the same for installing locally.

Additionally, if you wish to register the AD RMS service connection point (SCP) with Active Directory during configuration, the account also needs to be a member of the Enterprise Admins group for the forest. Because this requires additional privilege, you might choose to complete this task later after you have completed the basic server configuration. To do so, you must use the AD RMS console. For more information, see Register a Service Connection Point.

Using Windows PowerShell to deploy AD RMS

For Windows Server 2012, you can now optionally complete the two-part AD RMS deployment process as described in the previous section using Windows PowerShell commands. In Windows Server 2008 R2, the ADRMS module was provided as part of the base operating system but this has changed to enable more flexibility and modularity in installing the product. For this release, you need to use commands provided within the new ServerManager module for Windows PowerShell.

For example, to complete the first part of the deployment process (copy and install all required files for AD RMS) you would use the following Server Manager cmdlet examples at a Windows PowerShell prompt.

You can then install AD RMS by using the Install-ADRMS cmdlet which is provided as part of the AD RMS deployment module for Windows PowerShell. When using this cmdlet, use the new Credentials parameter as shown below. This parameter is required to support remote deployments and is recommended that you include it for all PowerShell-based deployments.

Install-ADRMS –Path adrmsDrive:\ -Credential

By adding the -Credential parameter you will be prompted to enter the required credentials to deploy AD RMS. If the installation is targeted for a remote computer, credentials must be passed through and validated at the remote computer before installation of AD RMS will proceed.

Using Windows PowerShell to uninstall AD RMS

For Windows Server 2012, uninstalling AD RMS can also be accomplished using Windows PowerShell as a two-step process comparable to a reversal of the process described in the previous section for AD RMS deployment. This process can be summarized as follows:

1. Uninstall the AD RMS role.

   This can be performed separately by using Windows PowerShell and running the Uninstall-ADRMS cmdlet in the ADRMS module.

2. Remove the AD RMS files and registry settings that were previously added to support AD RMS.

   If you are using Windows PowerShell, use the Remove-WindowsFeature ADRMS cmdlet in the ServerManager module to perform this step as a separate action.

Added support for Mac computers and mobile devices

AD RMS now supports mobile devices and Mac computers when you install and configure Active Directory Rights Management Services Mobile Device Extension.

What value does this change add?

The mobile device extension runs on top of an existing Windows Server 2012 or Windows Server 2012 R2 AD RMS deployment. This lets users who have mobile devices (Windows Phone, Android, iOS, and Windows RT), protect and consume sensitive data when their device supports the latest RMS client and uses RMS-enlightened apps. This also enables Mac users to use Office 2016 for Mac and the RMS sharing app to protect and consume content by using AD RMS.

What works differently?

In previous releases, support for mobile devices was limited to email if the mobile devices used mail applications that support Exchange ActiveSync IRM. This native support for RMS and mobile devices was introduced with Exchange 2010 Service Pack 1.

When you install the mobile device extension on an existing AD RMS deployment, users who have a Mac computer or mobile device can now 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 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 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.

For more information about the different file types that RMS supports, see the Supported file types and file name extensions section in the Rights Management sharing application administrator guide.

Changes to Windows PowerShell for deploying AD RMS

In addition to new changes to Windows PowerShell that affect deployment of the AD RMS role and its services and components, new properties have been added for Windows Server 2012 that can be used when deploying AD RMS installations. The following table provides details and comments on where these new properties can be used to support new changes such as support for strong cryptography.

AD RMS fails to install if multiple installations are active simultaneously in Server Manager

In previous releases of AD RMS included with Windows Server® 2008 and Windows Server® 2008 R2 it was not possible to launch more than a single instance of the AD RMS Configuration wizard to install or update multiple AD RMS deployments from the same server computer. Because of design changes to Server Manager for Windows Server 2012, multiple instances of the Add Roles and Features Wizard can now be run simultaneously, making it possible to launch two or more instances of the AD RMS Configuration wizard.

What value does this change add?

The changes to Server Manager in Windows Server 2012 enable server roles and technologies across Windows Server 2012 to be more open, efficient and flexible when you are choosing role deployment options.

What works differently?

As a result of changes to Server Manager to enable multiple instances to be deployed and configured simultaneously in Windows Server 2012 and because this change is at odds with how AD RMS is best designed to be deployed, AD RMS setup is not able to prevent multiple AD RMS configuration wizards from being launched to create new clusters or for joining an existing cluster. Therefore, the AD RMS Configuration wizard applies the following logic and process detection to determine how to manage the occurrence of multiple instances of AD RMS setup occurring at the same time.

• If multiple instances are launched and are used to join an already existing AD RMS cluster, AD RMS setup should succeed for all active instances.

• If multiple instances are launched and are being used to try to create the same new AD RMS cluster, AD RMS setup fails for all active instances.

Deployment considerations for virtualized AD RMS servers

This section describes issues to consider when you deploy AD RMS on virtual machines. In general, AD RMS is well suited to virtualization especially for testing and evaluation purposes. There are, however, a few practices that you should observe when you are working with virtualized AD RMS servers. The following section describes these considerations.

What value does this change add?

Using virtualization platforms, such as Hyper-V to deploy AD RMS for evaluation purposes offers a number of convenience features that can make testing easier. For example, virtualization enables you to easily establish a full private virtual networked configuration separate from your production networked environment in which you can freely test and evaluate AD RMS deployment to your satisfaction before attempting a deployment of it in your production environment.

What works differently?

When working with virtualized AD RMS servers, the following are some deployment practices and features that need to be observed or followed for best results.

• To ensure consistent performance between virtualized AD RMS servers operating in test conditions to how a comparable physical AD RMS server might perform in a subsequent production deployment of AD RMS, follow the recommended guidance requirements as you create your virtual machines and then use those as well for installing AD RMS on a physical server computer. In particular, select the recommended amount of RAM for virtual AD RMS servers to the higher recommended amount. If you follow recommended hardware guidelines, there should be no perceptible difference in performance between virtualized test server deployments of AD RMS and any comparable physical server installations you might later deploy into production as a result of your virtual lab test results.

• When you install AD RMS on a virtual server you will not be able to use an internal hardware security module (HSM) for AD RMS key storage. You can, however, use all other forms of key storage: network HSM key storage, AD RMS centrally managed key storage and software CSP key storage.

• If you have previously installed AD RMS on a virtual hard drive (VHD) and then take that VHD offline to uninstall AD RMS, the AD RMS role will not be completely removed. To ensure full and proper removal of AD RMS, you should remove the AD RMS server role first before shutting down any VHD associated with the original installation of AD RMS on your virtual machine.

Server Core Support for AD RMS

For Windows Server 2012, AD RMS now joins the list of server roles such as Active Directory Domain Services (AD DS) and Active Directory Certificate Services (AD CS) that are supported for Server Core deployment. Server Core is an installation option that enables you to perform a minimal installation of the Windows Server operating system which can be useful for reducing total cost of ownership (TCO) in deploying and managing servers.

What value does this change add?

Using Server Core to deploy AD RMS can provide you with simplified management, reduced maintenance, reduced memory and disk requirements and a reduced attack surface. Servers that run under Server Core can be simpler and less costly to manage and more stable and secure in production deployments. For more information, see What is Server Core? and Why is Server Core Useful?

What works differently?

In Windows Server 2012, the Server Core installation option is no longer an irrevocable selection that is made during setup. In Windows Server 2008 R2 and Windows Server 2008, if your requirements changed, there was no way to convert between a full installation and Server Core installation without completely reinstalling the operating system. You can now administratively convert between a full Windows Server installation and running on Server Core as needed. For more information, see Windows Server Installation Options.

On Server Core installations, the optional Identity Federation Support role service for the AD RMS server role is not supported. This is because Identity Federation Support relies on a role service of the AD FS Server role, the Claims-aware Agent, which is disabled on Server Core installations.

If you attempt to add Identity Federation Support for AD RMS, the following error will occur.

The request to add or remove features on the specified server failed.
Installation of one or more roles, role services, or features failed. - The source files could not be downloaded. Use the /source option to specify the location of the files that are required to restore the feature. The file location should either be the root directory of a mounted image or a component store that has the Windows Side-by-Side directory as an immediate subfolder.

The instructions to work around the issue by downloading the source files do not apply for this case. Identity Federation Support cannot be installed because the Claims-aware Agent is disabled on Server Core.

Recent feature updates for AD RMS

Windows Server 2012 also includes the following feature updates, which have been added recently as updates for the AD RMS role in Windows Server 2008 R2.

• Simple delegation

• Strong cryptography

Because these features are still relatively new to most customers, they are discussed more here to help increase awareness for them and provide additional context for those who are unfamiliar with their appearance in the AD RMS feature set.

Simple Delegation for AD RMS

Simple delegation for AD RMS enables you to have the same access rights to protected content that are assigned to one person delegated to other individuals within their organization.

What value does this change add?

Simple delegation provides the ability to have content rights assigned to executives and managers be easily and effectively delegated to their assistants. This enables the assistants to have the same level of access permission to Information Rights Management (IRM)-protected content as the executive. By extending the Active Directory schema to support two new attributes, delegation of rights can be easily turned on or off as needed to accomplish the appropriate level of privilege or restriction for those who support the leadership and management of your organization.

What works differently?

The requirements for enabling the use of AD RMS simple delegation in Windows Server 2012 are similar to the requirements for using it in Windows Server 2008 R2. Two attributes, msRMSDelegator and msRMSDelegatorBL must be added to the Active Directory schema. This can be done using update files executed using the Ldifde.exe tool. These extension attributes must be applied to all forests where AD RMS licensing occurs. Also, you might also need to set additional permissions for AD RMS to read these attributes and update your SQL installation that supports AD RMS as part of preparing your deployment to support the use of simple delegation as well.

The only other change in requirements for simple delegation in Windows Server 2012 that differs from how it was enabled in Windows Server 2008 R2 is a new AD RMS PowerShell property that can be used to enable and disable it. By default, the feature is disabled, however, to enable simple delegation use the following command line at an elevated Windows PowerShell prompt at an AD RMS provided PowerShell drive:

PS w:\SecurityPolicy\Delegation> Set-ItemProperty -path . –Name IsEnabled –Value $true

For more information, see An update is available to enable simple delegation in AD RMS on Windows Server 2008 R2-based computers.

Strong cryptography for AD RMS

Strong cryptography for AD RMS enables you to increase the cryptographic strength of your AD RMS deployment by running in an advanced mode known as cryptographic mode 2.

What value does this change add?

Running AD RMS in strong cryptographic provides an updated and enhanced cryptographic implementation to support much stronger encryption as well as stronger cryptographic keys. For example, in mode 2 operation, RSA encryption is enhanced from 1024 bit encryption to 2048 bit encryption. Also, cryptographic keys used for hashing are longer (changed from 160-bit keys to 256-bit keys) and now use SHA-2 hashing algorithm (SHA-2/SHA-256) standards.

The value of strong cryptography in AD RMS is that it can be part of enabling your organization to satisfy regulatory compliance with current security standards that are set by the National Institute of Standards and Technology (NIST). Starting January 1, 2011, NIST issued Special Publication 800-57 which recommends the use of 2048-bit RSA keys. United States Federal agencies are required to comply with NIST recommendations and many private enterprises and other countries may choose to implement this recommendation. To learn more, see NIST Special Publications.

What works differently?

To enable the use of strong cryptography in your AD RMS deployment, all computers that host either AD RMS server or client software must be patched and updated.

To update AD RMS servers to cryptographic mode 2, you can use the AD RMS management console or the AD RMS cmdlets for Windows PowerShell.

Using the AD RMS management console, you can choose to update existing AD RMS servers from cryptographic mode 1 to cryptographic mode 2 by doing the following:

1. In the navigation pane, select the AD RMS server you want to upgrade.

2. From the Action menu (or in the Actions pane), select the Update to Cryptographic Mode 2 option.

If you are using Windows PowerShell, you can also choose to update an existing AD RMS server from cryptographic mode 1 to cryptographic mode 2 using the ADRMS module.

To update to Cryptographic Mode 2 using Windows PowerShell, use the following syntax:

Update-ADRMS –UpdateCryptographicModeOnly –ServiceAccount <PSCredential> -force –NewCSPName <”Mode2 Supported CSP”> -Regen

The following items apply to the parameters specified as part of the above syntax:

• UpdateCryptographicModeOnly is the parameter that indicates that cryptographic mode 2 should be enabled. This is a one-way operation. Once complete, you cannot return the AD RMS server to cryptographic mode 1.

• The Force parameter is an optional switch that can be used to override prompting for user confirmation.

• The NewCSPName parameter indicates the cryptographic providers that you want to use for encryption. This is an optional setting depending on your current cryptographic key settings. By default it is the Microsoft Enhanced RSA and AES Cryptographic Service Provider, but could also be another cryptographic mode 2 provider, such as one from a Hardware Security Module (HSM) that supports at least 2048 bit encryption.

  Note

  
  The CSP name cannot be specified for centrally managed keys. If an AD RMS cluster is using a centrally managed key for cryptographic mode 1, it must update to a centrally managed key for cryptographic mode 2. It cannot update to a CSP key.

As an example, if the AD RMS service account is named ADRMSSvc, you would open a Windows PowerShell prompt and run the following command to update the AD RMS server to cryptographic mode 2:

Update-ADRMS –UpdateCryptographicModeOnly –ServiceAccount ADRMSSvc –NewCSPName "Microsoft Enhanced RSA and AES Cryptographic Provider"

For more information, see Active Directory Rights Management Service Cryptographic Modes.

See also

• Active Directory Rights Management Services Overview

• AD RMS Blog

• RMS Forum

• Active Directory Domain Services Overview

• Hyper-V overview

• Remote Desktop Services Overview

• Azure Rights Management